Burofácil

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

Annotations only say readOnlyHint=false and openWorldHint=false. The description adds substantial behavioral context: it returns a link where the sender reviews, completes, signs and pays; it does not charge or send until payment happens on the web; it handles missing data with [DATO PENDIENTE] placeholders; and it explains sharing behavior. No contradiction with annotations.

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 core action and return link, and every sentence carries operational meaning (pricing, placeholder handling, sharing, no-charge guarantee). It is somewhat dense and long, but not redundant for a tool with this much conditional behavior.

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 tool with no output schema and minimal annotations, the description covers the key behavioral contract: what it prepares, what link it returns, that payment happens externally, and how to handle missing data. Minor gaps remain around link expiry or error behavior, but an agent has enough to invoke 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 100%, so the baseline is 3. The description mostly restates schema-level semantics (borrador_token, texto, compartir) without adding format or constraint details beyond what the schema already documents. It clarifies usage flow but not parameter syntax.

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 ('Deja un burofax listo para enviarse en papel con acuse de recibo') and distinguishes itself by naming the sibling redactar_burofax as the source of borrador_token. An agent can tell this prepares a certified mailing and returns a payment/signing link, separate from tools like estado_envio or listar_casos.

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 conditions: use with a borrador_token from redactar_burofax or with own texto, and pass compartir:true when another person will sign and pay. It does not explicitly state when not to use this tool or compare it to estado_envio/listar_casos, but the context is unambiguous.

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, covering the safety profile. The description goes beyond them by disclosing what the response carries: the set of possible states, the dates of the 15th and 30th, and links to the evidence and dossier. This is useful output-content disclosure not present in structured fields.

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 dense sentence that front-loads the core purpose ('Estado de un expediente por su token') before the state enumeration and return details. Efficient, though the semicolon-chained clauses make it slightly packed.

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 tool with one param and no output schema, the description compensates by enumerating the possible states and the returned artifacts. The mention of 'fechas del día 15 y 30' is somewhat ambiguous, but overall it supplies enough for correct invocation.

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?

There is a single parameter with 100% schema description coverage, so the schema already documents 'token'. The description only restates 'por su token' and adds the 'expediente' context, not format or syntax. Baseline 3 is appropriate when the schema does the heavy lifting.

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: retrieve the status ('Estado') of an expediente identified by its token. It also enumerates the possible states (borrador, pagado, enviado, entregado, intento documentado), which pins down the domain. It does not explicitly differentiate from siblings like listar_casos, 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?

The description implies the tool is looked up by token but never states when to use it versus alternatives such as listar_casos or enviar_burofax, nor any prerequisites or exclusions. The token-based framing hints at usage, but there is no explicit 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?

readOnlyHint=true and openWorldHint=false already cover the safety profile, so the description is free to add value elsewhere — and it does, by disclosing the shape of each returned item (slug, name, when-to-use, required inputs). Since there is no output schema, that return-content disclosure is genuinely useful context beyond the annotations.

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 sentence, front-loaded with the action and resource, with the parenthetical efficiently packing the returned fields. Nothing redundant or padded.

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-param, read-only catalog with no output schema, the description supplies exactly what is needed: what comes back and what each entry means. It stops just short of stating that the result set is static/complete or how to use a slug downstream, which would make it fully self-sufficient.

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, which is the baseline-4 case; there is no input to misinterpret. The description correctly implies a no-argument, full-catalog call rather than a filtered lookup.

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: it lists the burofax types that can be written, and enumerates the fields each entry carries (slug, nombre, cuándo usarlo, datos requeridos). An agent can tell it is the catalog/discovery tool rather than the sibling send/status tools, though no sibling is 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: listing types is naturally the step before redactar_burofax/enviar_burofax, but the description never says when to call it, when not to, or that redactar_burofax is the follow-up consumer of the slugs. Adequate but leaves 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?

Annotations only provide readOnlyHint=false and openWorldHint=false, leaving room for the description to add value, which it does: it discloses the three return artifacts (text, requirements semaphore, draft token) and explicitly states no sending or billing occurs. It does not cover permission needs or token lifetime, 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?

Three short, front-loaded sentences: what it does, what it returns, and what it does not do. Every clause earns its place with no 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?

With no output schema, the description compensates by enumerating the return values, and all three required params are schema-documented. It is nearly complete; only finer behavioral details (e.g. what the 'semáforo' grades or token expiry) are 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?

Schema description coverage is 100%, so the schema already documents caso, datos (with date/amount formats) and email. The description only adds 'a partir de los datos', which is a restatement rather than new semantic detail; the 3 baseline 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 (Redacta/draft) and resource (el burofax de un caso) plus the source of data. It immediately distinguishes itself from the sibling enviar_burofax by declaring 'No envía ni cobra', so an agent can tell drafting from sending without opening either 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?

Routes the agent to listar_casos for the case slug and names enviar_burofax as the consumer of the returned draft token, giving clear context for the workflow. It lacks an explicit when-not statement, but the send/charge exclusion covers the main misuse case.

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 the safety profile is covered. The description adds genuinely new behavioral context: 'Gratis' (no cost) and 'no guarda nada' (no persistence), plus the shape of the result ('un semáforo por requisito con qué falta'). This meaningfully supplements the annotations.

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 tight sentences with zero filler: purpose and scope first, then return format, then cost/persistence caveat. Every sentence earns its place and the most important information is front-loaded.

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 single-parameter, no-output-schema, read-only validation tool, the description covers purpose, the return concept ('semáforo por requisito'), and the no-persistence/free behavior. It doesn't address edge cases such as what happens with text below the 80-character minimum, but nothing essential for calling it 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?

Schema description coverage is 100% (the single 'texto' parameter is documented as 'Texto íntegro del burofax' with min/max length constraints), so the baseline is 3. The description reinforces that the input is a full, already-written text but adds no syntax or format detail 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?

States a specific verb (evalúa/valida) and resource (un burofax ya escrito) against a concrete standard (los cinco requisitos del intento de negociación de la Ley 1/2025), even enumerating the five criteria. The phrase 'ya escrito' implicitly distinguishes it from the sibling redactar_burofax and enviar_burofax, so an agent can route correctly 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?

Clearly frames the usage context: it operates on an already-written burofax, telling the agent this runs as a pre-send check rather than a drafting or sending step. It stops short of explicit exclusions or naming which sibling to use instead, so it's clear context without full when/when-not guidance.

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