Skip to main content
Glama

suggest_categories

Suggests service codes for Bilbao incident reports from a text hint. For example, 'stacked cardboard on sidewalk' returns relevant categories.

Instructions

Sugiere serviceCodes por palabras (p.ej. 'cartones apilados en acera').

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
hintNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

B3.2/5.0
Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries the full behavioral burden. It does not say whether results are ranked/scored, whether it is a read-only suggestion vs. an assignment, whether auth is required, or how many codes come back — real gaps for a tool whose whole output is a suggestion set.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

One tight sentence with the purpose front-loaded and the example appended, no filler. It is slightly under-specified rather than over-long, so length itself is not the problem.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema and no annotations, the description conveys the core idea (free text in, serviceCodes out) but omits the shape of the response and the exact nature of the hint, leaving the agent to guess at call details.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% and the single 'hint' parameter has no schema description, so the description must compensate. It partially does by stating the input is free-text words and giving an example, but it does not clarify language, length, or whether keywords or full sentences are expected.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb (sugiere/suggests) and resource (serviceCodes) along with the input modality (por palabras). It clearly describes a lookup-by-free-text purpose, though it never differentiates itself from the related list_categories/get_category siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The concrete example ('cartones apilados en acera') implies when the tool is useful — when the agent has a descriptive free-text hint rather than a known code — but there is no explicit when-to-use statement or routing against list_categories or search_street.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.