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

With no annotations, the description carries the full burden and handles the most consequential fact: the default call creates NOTHING and only echoes the fields that would be sent, while confirm=true actually submits. It also discloses that the stored email is used unless 'identity' overrides it. It omits permissions/error behavior and whether the published aviso is publicly visible, keeping it short of 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?

Front-loaded with the highest-risk fact (the dry-run default) before any other detail, and every sentence carries information. Slightly repetitive in restating confirm=false twice across the text, but no real waste.

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 an 8-parameter mutation tool with no annotations and no output schema, the description supplies the missing behavioral contract: what a default call returns and how to actually create. It does not touch image_path or the tipo code list, but those are covered by the schema.

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 baseline is 3; the schema already documents confirm, identity, tipo, address, lat/lon, and image_path. The description reinforces the confirm and identity semantics but adds no syntax or format detail beyond what the schema states.

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?

Opens with a specific verb+resource ('Crea un aviso'), so the agent immediately knows this is the notice-creation tool. It does not explicitly differentiate itself from the sibling create_aviso_from_photo, so sibling disambiguation is left to inference.

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 when/when-not guidance: default is dry-run (confirm=false) and real creation requires confirm=true. What it lacks is routing guidance versus the alternative sibling create_aviso_from_photo for photo-based notices.

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 that preview does not send, that sending requires confirm + human_confirmed + preview_token, that missing tipo creates nothing, and that the photo travels as a data URL. These are critical behavioral traits for a mutation tool that would otherwise be invisible.

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 appropriately sized for a 13-parameter, multi-phase tool; the workflow phases and send gate are front-loaded. It is information-rich rather than padded, though the compressed phrasing costs some readability.

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 complex mutation tool with no annotations and no output schema, the description covers the phased workflow, the send gate, and the upload alternatives thoroughly. Minor gaps remain on some parameters and nothing is said about the preview response shape beyond preview_token.

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 69%, and the description adds genuine meaning beyond it: file_id as the preferred remote route, image_path restricted to stdio/CLI, confirm requiring the token pair, and the consequence of omitting tipo. A few params (lat/lon/address/identity) are only covered by the schema, keeping it from a 5.

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 en fases') and immediately frames the two-phase workflow (preview vs send). It does not explicitly name the sibling create_aviso to differentiate the photo-based variant from it, so it falls just 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?

Explicitly names the preferred upload route (PUT /upload + file_id) versus the stdio-only alternative (image_path), and spells out the two phases: 'Sin tipo → sugiere', 'Con todo → preview + preview_token SIN enviar'. The send requirements are enumerated with the three mandatory fields. Nothing about when to use it versus alternatives 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.

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

No annotations provided, so the description carries the full behavioral burden. It doesn't state whether the tool returns null/error for unknown codes, the shape of the response (name in which language?), or any side effects. For a lookup tool this leaves important behavioral gaps.

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 short sentence, front-loaded. However, it is arguably too terse for a tool with two parameters and no schema descriptions, bordering on under-specification rather than pure 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 lookup tool with no annotations, no output schema, and 0% schema coverage, the description is incomplete. It omits input parameter meanings, language handling, and error behavior — all of which an agent needs to call it correctly.

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%, yet the description only mentions 'código y nombre' (code and name) as outputs, not inputs. It doesn't explain that 'code' is the required input, nor that 'lang' selects the language (constrained enum). With zero schema coverage, the description should compensate but doesn't.

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 it returns details of a 'tipo' (type), which partially aligns with 'category' in the tool name but introduces a different term. Does not distinguish itself from sibling 'list_categories', leaving ambiguity about whether this is retrieval of a single category vs enumeration.

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 guidance on when to use this tool versus list_categories or suggest_categories. Condition for use (retrieving a single category by code) is only implied by the required parameter, not 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 and no output schema, the description carries the full burden and does disclose the key behavioral fact: the return payload (email, language) and the null case when identity was never captured. It omits any note on persistence or whether the value is cached, but for a trivial parameterless read this is solid coverage.

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 short sentence, front-loaded with the action and resource, with the null case appended as a useful qualifier. No waste.

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 with no output schema, the description supplies the one thing an agent cannot get from structured fields: what comes back and when it is null. Only a hint about how the identity should be used downstream is missing.

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?

Zero parameters, so the baseline of 4 applies. The description correctly implies no input is required.

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 ('Devuelve la identidad guardada') and even enumerates the returned fields (email, idioma). It contrasts implicitly with the sibling set_identity via the get/set pairing, but never names the alternative 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 clause 'o null si aún no se preguntó' implies the usage flow (call set_identity when this returns null), but no explicit when-to-use or alternative routing is stated. Guidance is inferable rather than 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 behavioral burden, and it does disclose one real trait: no authentication is required. However, it says nothing about read-only scope, response shape, or caching, so the disclosure is partial for a tool with zero annotation coverage.

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 short fragments with the concrete category codes front-loaded and zero filler. It is efficient, though the telegraphic style borders on under-specification rather than deliberate brevity.

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, no-required-parameter read tool with no output schema, the description is mostly sufficient by revealing the category code set, but the omission of the 'lang' parameter and any statement of what is actually returned leaves gaps. It is adequate rather than 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?

Schema description coverage is 0% and the description never mentions the single 'lang' parameter or its enum values (es, ast), which controls the language of the returned labels. The description fails to compensate for the coverage gap, leaving the parameter's meaning to be inferred.

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 ('Tipos de incidencia') and lists the concrete category codes (ALU, VIA, SEM, SEN, VER), making the tool's output domain clear despite the terse phrasing. It does not differentiate itself from siblings like get_category or suggest_categories, which keeps it from 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?

'Sin auth' tells the agent no authentication is needed, which is a genuine precondition, but there is no guidance on when to call this versus get_category or suggest_categories. The agent must infer the distinction from names alone.

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 discloses a meaningful behavioral trait — the email is stored once and reused, serving as the notice's identity — but says nothing about overwrite semantics if called again, side effects, or auth requirements for a mutation 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 front-loaded sentence with no waste; the verb and resource lead, and the parenthetical clarifies reuse semantics rather than padding. Slightly terse for the tool's complexity but structurally sound.

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 two-parameter setter with no output schema, the description covers purpose and reuse behavior, but omits the lang parameter's role and return/side-effect expectations. Adequate minimum viable coverage with clear 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?

Schema description coverage is 100%, with both required parameters documented ("email del comunicante", lang enum), so the schema already does the heavy lifting. The description adds no format or constraint detail beyond what the schema provides; baseline 3 is 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?

States a specific verb ("Guarda") and resource ("el email del comunicante"), and adds that this email is the identity of the aviso, which sets it apart conceptually from get_identity. It does not explicitly name the sibling it complements, but the save-versus-get distinction is inferable from the verb.

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?

"se pregunta UNA vez y se reutiliza" implies a usage pattern — call it once and the value persists — which is useful context. However it never says when to call this versus get_identity, nor any preconditions or exclusions, leaving the routing 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 are provided, so the description carries the full behavioral burden. It discloses only that categories are suggested; it says nothing about read-only safety, whether results are ranked, rate limits, or what the response contains.

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, followed immediately by a useful example. No padding or 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 simple one-parameter suggestion tool with no output schema, the description is minimally adequate but incomplete: it omits what the returned suggestions look like, whether the hint is optional, and any usage context relative to the sibling category tools.

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 optional "hint" parameter has 0% schema description coverage, so the description must carry the burden. It partially compensates by providing an example value ("farola apagada") that illustrates the expected free-text format, but gives no constraints on length, language, or whether the parameter is optional/required.

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 a verb ("Sugiere") and a resource ("tipos") with a concrete example ("farola apagada"), so the general purpose is inferable. However, "tipos" is vague versus the sibling tools' "categories" terminology (list_categories, get_category), and the description never distinguishes this suggestion behavior from those lookup tools.

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 explicit when-to-use or when-not-to-use guidance. The example implies it is meant for free-text hints, but there is no statement about when an agent should call this instead of list_categories or get_category.

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