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

With no annotations provided, the description carries the full behavioral burden and does a good job disclosing the critical mutation gate: by default it is DRY-RUN and only returns the payload without creating anything, and confirm=true is required to actually send. It also notes that the saved identity is used unless overridden. It still omits auth requirements, rate limits, and error behavior, keeping it from a 5.

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 short sentences front-load the core purpose and then immediately emphasize the critical dry-run caveat. Every sentence earns its place with no redundancy or filler.

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 9 parameters, a nested identity object, no annotations, and no output schema, the description adequately covers the dry-run default and identity handling. However, it does not explain what a successful real creation returns, error behavior, or how the many required fields relate to sibling listing tools, leaving meaningful gaps for the agent.

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 all parameters are already fully documented in the input schema. The description repeats the confirm and identity semantics but adds no new syntax, format, or edge-case meaning beyond what the schema already provides, making the baseline 3 appropriate.

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 ('Crea un aviso') so an agent immediately understands it creates a notice report. It does not explicitly differentiate from the sibling create_aviso_from_photo, which is a clear alternative for creating a report from a photo, so it falls short of a 5.

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 gives invocation guidance by explaining the dry-run default and that confirm=true is needed to actually create, which implies usage context. However, it never says when to choose this tool over alternatives like create_aviso_from_photo, leaving tool selection to inference.

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 exist, so the description carries the full burden and does so well: it discloses the preview-then-send gating, that nothing is sent without all three flags, that the photo travels as base64 in the send call, and the need for human confirmation. This is exactly the kind of behavioral context annotations would otherwise supply.

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?

Dense and telegraphic but front-loaded with the workflow phases and free of filler; each clause carries routing or gating information. The compressed style costs some readability but wastes nothing.

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-parameter, nested-object tool with no annotations and no output schema, the description covers the operationally critical path (upload, preview, confirmed send) thoroughly. Minor gaps remain on peripheral params (lat/lon override, identity override, category_hint), which the schema partially covers.

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 57%, and the description adds real meaning: it explains file_id's preferred-remote role, image_path's stdio-only constraint, the send-gating semantics of confirm/human_confirmed/preview_token, and that image_base64 travels in the send. It does not explain lat/lon/address/identity/category_hint, which remain schema-documented only.

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 ('Aviso desde una FOTO') and immediately distinguishes itself from the sibling create_aviso by scoping to photo-based creation. The phased nature of the operation is named up front.

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 explicit routing: preferred upload path (PUT /upload + file_id) vs stdio (image_path local), what happens without service_id/category_id (suggests, need_category), what happens with everything (preview, no send), and the exact conditions to actually send (confirm + human_confirmed + preview_token after human 'yes'). This is unusually complete when-to-use 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?

With no annotations and no output schema, the description carries the disclosure burden and does describe the return shape (identity fields or null), which is genuinely useful. It does not cover sensitivity/permissions of returning personal data or any other behavioral traits.

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 with no waste; it delivers the resource, the returned fields, and the null case in one pass.

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 annotations or output schema, the description is nearly sufficient: it names the returned fields and the empty state. It would be stronger if it clarified what the null-prone state means for downstream calls.

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 sensibly explains the returned data instead of inventing parameter guidance.

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 guardada') plus the exact fields returned (email, teléfono, uuid). The read semantics clearly separate it from the sibling set_identity, though that sibling is not named 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?

Usage is only implied: the verb 'Devuelve' signals a read operation contrasted with set_identity, and the mention of 'null si aún no se preguntó' hints at the not-yet-collected state. There is no explicit when-to-use statement or named alternative.

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, yet it discloses nothing about read-only nature, pagination, ordering, or auth requirements. For a list operation these traits matter, and only the vague noun phrase is offered.

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 phrase, front-loaded with the resource and with no filler. It is efficient, though so terse that it borders on under-specification rather than tight conciseness.

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 one-parameter list tool with no annotations and no output schema, the description covers the resource and roughly the return fields. It still omits usage context and any behavioral traits, leaving meaningful gaps for an agent choosing among the seven siblings.

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 compensate. "De un servicio" does map implicitly to the service_id parameter (the service whose categories are returned), and "id + título" hints at the returned fields, but no format, type, or syntax detail is given.

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 the resource ("Categorías de un servicio") and even the return shape ("id + título"), so the agent knows it retrieves categories belonging to a service. However, the verb is only implied by the list_ prefix, and the description never distinguishes it from the sibling suggest_categories, which an agent could easily confuse it with.

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?

There is no when-to-use guidance, no prerequisites, and no mention of the closely related suggest_categories alternative. The agent must infer the context entirely from the name.

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, yet it discloses nothing about side effects, authentication, pagination, or ordering. The read-only nature is only weakly implied by the naming convention shared with sibling tools.

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?

It is a single compact fragment with no wasted words, but it is under-specified rather than truly concise, and it does not front-load an action verb.

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?

The tool is simple (no params, no output schema), so the description must describe the return value; it hints at id + title but omits that a list of services is returned and gives no behavioral context at all.

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 the baseline for this dimension is 4; there is no parameter semantics to clarify or omit.

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 fragment 'Servicios de LPGC Avisa (id + título)' merely restates the tool name's resource and adds the returned fields, with no verb to confirm it enumerates rather than creates or modifies services. It does not distinguish it from siblings like list_categories, which follow the same naming pattern.

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?

There is no statement of when to call this versus alternatives such as list_categories, my_avisos, or get_identity. Usage can only be inferred from the name.

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 discloses almost nothing. It does not state that the operation is read-only, that skip/take control pagination, what the result set looks like, or any auth requirements. Only the implicit 'fetch notices' framing suggests a safe read.

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 single sentence is front-loaded and free of padding, which is good. But its brevity is under-specification rather than economy: the scope qualifier is present while the operation, pagination, and return shape are all absent. Efficient, but too thin to be called well-structured for a 3-parameter 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?

With zero annotations, 0% schema coverage, no output schema, and three undocumented parameters, the description should be doing the heavy lifting and instead does almost none. An agent cannot determine the operation type, paging behavior, or result format from this definition alone.

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% across three parameters. The description adds meaning only for 'email' (optional override of the saved account) and says nothing about 'skip' or 'take', whose pagination semantics are left entirely undefined. Two of three parameters remain opaque to the agent.

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 conveys that the tool returns 'avisos' (notices) scoped to the saved email account or an explicitly supplied one, which is more than a bare restatement of the name. However, it uses a noun phrase with no verb, so an agent must infer that this is a retrieval/list operation rather than a creation or mutation. Sibling 'create_aviso' implies this is the read counterpart, but the description never says so.

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?

There is no statement of when to use this tool versus alternatives such as create_aviso or create_aviso_from_photo. The parenthetical '(o el indicado)' hints that an email can be supplied instead of the default account, but that is parameter behavior, not usage guidance. An agent gets no routing signal.

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 behavioral burden. It does disclose two non-obvious traits: the UUID is auto-generated (so the agent must not supply one) and the values are persisted for reuse. But it omits overwrite/update semantics on repeat calls, validation failures, and persistence side effects.

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 core action front-loaded and the caveats parenthesized. Nothing is wasteful, though the dense parenthetical slightly compromises scannability.

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 2-parameter write tool with no annotations and no output schema, the description covers what is stored and the once-only rule, which is the essential minimum. It still leaves ordering relative to create_aviso and repeat-call behavior unstated.

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 both parameters are already documented as 'email' and 'teléfono español'. The description adds only the reuse-once framing, which is not parameter-level syntax or format detail, 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 in Spanish: stores the communicant's email and phone. The implied save/read contrast with the sibling get_identity is reasonably inferable, though it is not named explicitly, so sibling differentiation is soft rather than 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 parenthetical 'se preguntan UNA vez y se reutilizan' implies this should be set once and reused across the session, which is useful usage context. However it never says when to call it relative to siblings like create_aviso, nor what happens if called again, so guidance is implied rather than explicit.

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 doesn't state that this is a non-mutating lookup, how many suggestions are returned, whether they are ranked or confidence-scored, or what happens when no match exists — all significant gaps for a suggestion/ambiguity-resolution 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?

A single short sentence with zero filler; the action, output, and input modality are all front-loaded. Nothing could be trimmed without losing meaning.

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 annotations, no output schema, and no schema descriptions, the description is the only documentation and it omits the return shape entirely — one suggestion or many, and in what structure. An agent cannot tell what it will receive back or how to consume it, so the definition is incomplete for this tool's role.

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 'hint' parameter has no schema description, so the description must compensate. It does partially: 'por palabras' clarifies the parameter is free text and the example 'contenedor desbordado' shows the expected granularity, but it doesn't say whether the hint is required or what language/format is 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 (suggests) and the exact resources returned (service_id + category_id) plus the input modality (words), with a concrete example. It clearly distinguishes itself from list_services/list_categories, which enumerate rather than infer IDs from free text, though it never names those siblings 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 phrase 'por palabras (p.ej. ...)' implies the tool is for turning a free-text hint into IDs, which is an adequate contextual signal. However, it never says when to prefer this over list_categories, nor whether it should be called before create_aviso, so the routing decision is left to inference.

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