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

With no annotations provided, the description carries the full burden. It does disclose two meaningful traits: the operation is read-only ('lectura abierta') and requires no registration ('sin registro'). It stops short of describing return shape, pagination, or filtering behavior.

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?

A single compact sentence with the resource front-loaded, examples parenthesized, and access mode appended. No wasted words, though the omission of any verb is a content gap rather than a conciseness win.

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 one-optional-parameter tool with no output schema, the description covers what the resource is and its access model, which is close to sufficient. It still omits the operation type and any note on the lang parameter, leaving minor gaps.

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 single parameter 'lang' is undocumented in both schema (0% coverage) and description. The enum values es/va are self-explanatory as Spanish/Valencian, but the description adds nothing about the parameter, leaving the low-coverage gap unaddressed.

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?

Names the resource ('actuaciones en vía pública') and clarifies it with examples ('obras, podas'), which distinguishes it from sibling tools like avisos or categories. However, it never states a verb – there is no indication whether the tool lists, retrieves, or searches these public-works entries, leaving the agent to infer the operation.

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?

'Lectura abierta, sin registro' communicates a precondition (no authentication needed) but gives no guidance on when to use this tool versus alternatives, nor any filtering or scenario context. The agent gets an access hint, not a usage rule.

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?

With no annotations, the description carries the full burden and does well: it surfaces the non-obvious dry-run default, what is returned without confirm, the deviceId precondition, and identity override behavior. It omits permanence/visibility of the created aviso and any rate or permission limits.

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?

Three dense sentences, zero filler, and the most important gotcha (dry-run default) is flagged up front with 'IMPORTANTE'. Every clause conveys actionable 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?

For a 9-parameter mutation tool with a nested identity object and no output schema, the description covers the critical call-correctly concerns (dry-run, confirm, deviceId, identity). It could say more about what a successful real submission returns or does.

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%, so all nine parameters including confirm, identity, and image_paths are already documented in the schema. The description reinforces confirm/identity semantics but adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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+resource ('Crea un aviso') and makes the write-vs-dry-run semantics explicit. It does not differentiate itself from the sibling create_aviso_from_photo, leaving the agent to infer which creation path applies.

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?

Gives clear operational conditions: default is dry-run, confirm=true is required to actually submit, and a registered deviceId is a precondition. It never states when to prefer this tool over create_aviso_from_photo, so alternatives remain unaddressed.

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?

With no annotations, the description carries the full burden and does so well: it discloses the phased preview-first behavior, that preview does NOT send, and that sending requires the triple of confirm:true + human_confirmed:true + preview_token after a human 'sí'. This safety-critical gate is exactly the behavioral context an agent needs.

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?

Extremely dense but front-loaded: purpose first, then preferred path, then each state transition, ending on the send gate. Every clause carries a distinct operational rule with no filler, appropriate for a two-phase tool.

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 14-param, nested-object, two-phase tool with no output schema, the description covers the decision flow and return states (need_category, error, preview+token) well. Minor gap: a few parameters are left entirely to the schema, and the identity override is only documented there.

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 64%, and the description adds real meaning beyond it: file_id vs image_path selection logic, categoria's fallback to suggestions, and the coupling of confirm with preview_token/human_confirmed. It does not explain lat/lon/fuente/identity/image_base64, leaving those to 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?

States a specific verb+resource+scope: creates an aviso from a FOTO, and notes it works in phases. The 'desde una FOTO' framing implicitly separates it from the sibling create_aviso, but it never names that sibling to make the distinction 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?

Explicitly routes between the preferred remote path (PUT /upload then file_id) and the stdio path (local image_path), and gives the conditional branches for missing categoria, missing address/coords (route to geocode), and the ready-to-preview case. The when-to-use logic is fully spelled out.

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?

With no annotations, the description carries the full burden. It does disclose the output coordinate system (WGS84) and the data source (municipal street map), which is genuinely useful, but says nothing about failure behavior for unmatched addresses, match granularity, or limits. Decent but incomplete disclosure for a lookup tool.

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 compact sentence with the input-to-output mapping front-loaded and the example parenthesized. Nothing is wasted and no reading is required past the first clause.

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 one-parameter lookup with no output schema, the description supplies the critical missing pieces: accepted input format, example, output CRS, and data source. Only edge-case behavior (no match, multiple matches) is absent, which is a minor gap at this complexity level.

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 0% and the single 'query' parameter has no schema description, so the description must compensate. It does so by defining the expected composition ('Calle + número') and giving a full example including city, which is exactly the format detail the bare schema lacks.

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 precise transformation: street + number becomes WGS84 coordinates using the municipal street map, with a concrete example ('Calle Colón 1, Valencia'). No sibling tool does anything comparable, so no differentiation is needed and the agent can identify this tool immediately.

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 example implicitly shows when the tool applies (address-style input) and hints at the expected format, but there is no explicit statement of when to use it, when not to, or what to do with ambiguous/unmatched addresses. Usage is inferable rather than stated.

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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It does not state whether the operation is read-only, how missing codes are handled, or whether lang affects the result. It only lists returned fields, leaving key behavioral traits undocumented.

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 a single, front-loaded sentence with no wasted words. It efficiently communicates the core return content. For a simple lookup tool, this is appropriately sized.

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?

Given no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It does not explain the lang parameter, error behavior, or read-only nature. For a two-parameter lookup tool the definition leaves too much to inference.

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 0%, so the description must explain both parameters. It hints that 'code' is a TCOM-xxx identifier, but provides no format details, and completely omits the 'lang' parameter and its es/va enum. One of two parameters remains entirely unexplained.

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 clearly states that the tool returns detail for a TCOM-xxx code, including group, code and name. It identifies the resource and the returned fields, but does not differentiate from siblings like list_categories or suggest_categories. A clear purpose without sibling routing earns a 4.

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 only defines what the tool returns; it gives no guidance on when to use it versus alternatives such as list_categories or suggest_categories. No prerequisites, exclusions, or conditions are mentioned. This is a purpose statement, not usage guidance.

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?

No annotations are provided, so the description carries the full burden. It does disclose the return shape and the null-when-unset behavior, which is genuinely useful. It says nothing about permissions, whether the identity can be stale, or any side effects, though the read-only nature is strongly implied by 'Devuelve'.

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?

A single sentence that front-loads the action and resource and appends the important edge case (null). No filler, no redundancy.

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 zero-parameter read tool with no output schema and no annotations, the description supplies the essential missing piece: what fields come back and when null is returned. It is close to complete, missing only the relationship to set_identity as the writer of this value.

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 per the rubric the baseline is 4. The description correctly implies a no-argument, single-value retrieval, and no parameter documentation is needed.

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 ('Devuelve') and resource ('la identidad del comunicante'), and even enumerates the returned fields (contacto, idioma, dispositivo). It reads as the clear getter counterpart to the sibling set_identity, though it never names that counterpart explicitly.

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 'null si aún no se preguntó' clause hints at the state in which the call is meaningful, which implies usage. However, there is no explicit when-to-use guidance, no mention of set_identity as the alternative that populates this value, and no sequencing advice.

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?

No annotations are provided, so the description carries the full behavioral burden. It discloses that returned items include TCOM-xxx codes, which is useful output context, but says nothing about permissions, read-only nature, pagination, or ordering. For a listing tool with no annotation coverage, this leaves important behavioral traits unspecified.

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?

A single compact sentence with no filler, front-loading the resource being listed. It is appropriately sized for a simple list tool. The parenthetical is dense but earns its place by explaining an important output detail.

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?

Given the high simplicity (one optional param, no output schema, no annotations), the description is minimally adequate. It covers the resource and the TCOM code output, but omits the lang parameter, return structure, and usage relative to siblings. Enough to call the tool, but not complete.

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 only parameter is lang (enum es/va) with 0% schema description coverage, and the description never mentions language selection or what the parameter controls. The enum values are somewhat self-explanatory, but the description adds no semantic meaning beyond the schema. It does not compensate for the coverage gap.

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 names the exact resource (categorías y subcategorías de avisos) and notes that each item includes a TCOM-xxx code for creation. It distinguishes itself from get_category by being plural and from create_aviso by emphasizing the code needed to create. It is clear but does not explicitly state that it returns a list, though the tool name and context make that unambiguous.

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: the parenthetical 'para crear' signals it should be called before creating an aviso, but there is no explicit when-to-use or when-not-to-use guidance. It does not name alternatives such as get_category or suggest_categories. An agent can infer the purpose but receives no routing instructions.

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?

No annotations are provided, so the description carries the full burden. It does disclose the dependency on register_device, which is genuinely useful behavioral context, but it says nothing about whether this is a read-only operation, what the response contains, or ordering/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?

A single short sentence with the resource front-loaded and the prerequisite parenthetically attached. Nothing is wasted, though it is terse to the point of underspecification.

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 zero-parameter read tool with no output schema, the description should at least hint at what an 'aviso' is or what is returned. It covers the precondition but leaves the payload shape entirely unspecified.

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 per the rubric the baseline is 4. There is nothing parameter-wise the description could add.

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 names the resource (avisos) and scopes it to the registered device, which distinguishes it from the create_aviso siblings. However, it uses a bare noun phrase with no verb, so the agent must infer that this retrieves/lists avisos rather than mutating 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?

It states a precondition ('requiere register_device previo'), which is real usage guidance and tells the agent the tool will fail or be meaningless before registration. It gives no when-not guidance and does not point to any alternative sibling for listing or creating avisos.

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?

With no annotations, the description carries the full burden and does well: it discloses that this WRITES to the server (mutation), requires explicit human approval, and persists the returned idDispositivo as local state. It stops short of covering idempotency, behavior on re-registration, or failure modes.

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?

Single dense sentence that front-loads the action and endpoint before the constraints. Every clause earns its place, though the run-on structure packs three ideas into one sentence.

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 zero-parameter, no-output-schema mutation tool, the description supplies the missing behavioral context: write semantics, approval requirement, and the ordering constraint relative to avisos. Minor gaps remain around error handling and whether the operation is idempotent.

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 and 100% of the (empty) schema is covered, so per the rubric the baseline is 4. There is nothing parameter-related the description could usefully add.

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 (registrar), the target resource (dispositivo en el Ayuntamiento), the concrete endpoint (POST /dispositivos), and the side effect (guarda el idDispositivo). It also ties the tool to its downstream purpose ('necesario antes de crear o consultar avisos'), which clearly separates it from sibling tools like create_aviso or get_identity.

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?

Gives an explicit prerequisite ('Necesario antes de crear o consultar avisos') and an explicit gating condition ('usar solo con OK humano explícito'). That is both when-to-use and when-not-to-use-without-approval guidance, which is rare and valuable.

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?

No annotations are provided, so the description must carry the full behavioral burden. It discloses the validation rule (at least one of phone or email) and that the identity is persisted after a one-time prompt, but omits key mutation traits such as authentication requirements, overwrite behavior, error responses, and return values.

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 with zero waste: the purpose is front-loaded, followed by the usage note and validation rule. Every clause earns its place.

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 mutation tool with no annotations and no output schema, the description covers purpose, usage, and validation but leaves behavioral gaps (auth, side effects, return behavior). The schema handles parameters well, but the description should do more to compensate for the lack of annotations.

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 the schema already documents each parameter. The description restates the cross-field constraint ('al menos uno'), which is also implied by the individual schema descriptions, adding only marginal clarification beyond the structured data.

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 ('Guarda') and resource ('identidad del comunicante'), clearly distinguishing it from sibling get_identity. An agent can tell it is a write operation that persists identity without opening the schema.

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?

Explicitly says it is asked ONCE after installation and then reused, giving a clear when-to-call condition. Does not mention an alternative tool or when to avoid calling, but the main usage context is provided.

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?

No annotations are provided, so the description carries the full behavioral burden, and it does not say whether results are ranked by confidence, how many codes are returned, or what happens when the optional 'hint' is omitted. Only the operation itself is disclosed.

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?

A single front-loaded sentence carrying verb, resource, and an illustrative example with zero filler. Nothing could be removed 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?

For a one-parameter, no-output-schema tool this is close to sufficient, but the description omits the return shape (list of codes? ranked matches?) and the meaning of an absent hint, both of which an agent would need before invoking.

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?

One parameter ('hint') with 0% schema description coverage, so the description must compensate. The parenthetical example does convey that 'hint' is free-text keyword input, but nothing is said about length, format, or whether multiple words/phrases are accepted.

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 ('sugiere') and a specific resource ('códigos TCOM-xxx'), plus an input example. An agent can tell this is a fuzzy code-suggestion tool rather than a plain lookup, though it never explicitly distinguishes itself from list_categories or get_category.

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?

No when-to-use, no when-not-to-use, and no mention of the obvious alternatives list_categories / get_category. The example hint ('contenedor desbordado') implies the input form but gives no guidance on which tool to pick.

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