Guía Nordelta

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

The annotations already declare readOnlyHint=true and openWorldHint=false, and the description adds that results are neighbor-recommended providers in a specific local area. It also enumerates returned fields (name, rubro, phone, WhatsApp, description, profile link), though it does not discuss result ordering or pagination.

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

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

The description is two front-loaded sentences with no filler. The first defines the scope and query style, and the second lists the return fields.

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

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

For a simple read-only search tool with three fully documented optional parameters and no output schema, the description supplies purpose, query style, and return fields. The main remaining gap is that it does not explicitly relate this tool to the sibling tools listar_rubros and ver_proveedor.

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

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

Schema description coverage is 100%, so rubro, limite, and consulta are already fully documented in the schema. The description's examples add some flavor to the consulta parameter but do not add new semantics beyond the schema.

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

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

The description states a specific verb and resource: it searches for recommended service providers in Nordelta (Tigre, Buenos Aires). It is clear, but it does not explicitly distinguish itself from the sibling tools listar_rubros and ver_proveedor.

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

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

The description gives clear usage context by saying it accepts natural person-style queries such as 'plomero' or 'clases de inglés'. It does not provide explicit when-not guidance or name alternatives, but the intended query style is clear.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety and scope are covered structurally. The description usefully adds the return contents (provider counts and slugs), but says nothing about ordering, pagination, or whether the rubro set is fixed.

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

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

One front-loaded sentence with zero waste; the resource is named first and the payload described immediately after.

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

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

With no parameters, no output schema, and annotations covering safety, the description carries the return shape (rubros with counts and slugs) adequately. Only minor gaps remain, such as ordering or size of the fixed rubro set.

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

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

The tool takes zero parameters, so there is nothing for the description to disambiguate; baseline 4 applies. The single sentence correctly signals that the call is unfiltered and returns the full set.

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

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

States a specific verb (lista) and resource (rubros de la Guía Nordelta) and adds what comes back (provider count per rubro and its slug). It is clearly distinguishable from the sibling tools, which all operate on proveedores rather than on the rubro taxonomy, though it never names them.

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

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

Usage is only implied: an agent can infer this is the entry point for obtaining rubro slugs that the sibling tools likely consume, but the description never says when to call it or how it relates to buscar_proveedores and ver_proveedor.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered, and the description usefully adds that reviews are bundled into the response. It says nothing about what happens with an invalid or ambiguous slug, or whether the review list is truncated or paginated.

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

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

Two sentences, zero filler: the resource and returned content come first, then the input format with a concrete example. Nothing is repeated from the title and nothing could be cut without losing information.

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

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

With one required parameter, no nested objects and no output schema, the description covers what the agent most needs: how to supply the identifier and what comes back (detail plus neighbor reviews). Only failure modes and review volume are left unaddressed, which is minor for a read-only lookup.

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

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

Schema coverage is 100% and the schema itself already says 'Slug o URL', so the description's explanation of what a slug is plus the worked example ('miguel-carpintero') adds only modest value over the structured field. Baseline 3 applies when the schema carries the parameter definitions.

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

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

States a specific verb and resource ('Detalle de un proveedor de la Guía Nordelta') and adds the returned payload ('con las reseñas de vecinos'), which no sibling would return. It does not name buscar_proveedores or listar_rubros, so the boundary with siblings is implied by the domain noun rather than made explicit.

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

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

The accepted input forms (slug or full URL) are spelled out, which implicitly tells the agent this is a post-lookup detail call, but the description never says 'use after buscar_proveedores' or when NOT to use it. For a detail endpoint paired with a search sibling, the routing sentence is the one piece missing.

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