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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds useful context about the richness of the payload, but says nothing about error behavior for an unknown code, rate limits, or auth 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?

A single, front-loaded sentence that lists the returned content categories with no filler. Effective and appropriately sized, though the long enumerations are dense.

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 carries the burden of describing returns and does list the main content fields. However, it omits the undocumented max_caracteres_extracto parameter and gives no structural sense of the response, leaving gaps for a detail endpoint.

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 only 50%: the 'codigo' parameter is documented in the schema, but 'max_caracteres_extracto' (500–30000) has no description anywhere. The description alludes to the 'extracto oficial' but never explains the character-limit parameter or its effect, so it fails to 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 states a specific resource (a BDNS 'convocatoria') and enumerates exactly what the fact sheet contains — estado, plazo, presupuesto, beneficiarios, bases reguladoras, extracto, documentos. This clearly distinguishes a detail-retrieval tool from the search-oriented siblings, though the differentiation is implicit rather than stated against ayudas_buscar.

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 implied: fetch the full record for one convocatoria by its code. The link to ayudas_buscar appears only in the schema parameter description ('lo devuelve ayudas_buscar'), not in the tool description, so there is no explicit when-to-use / when-not or named alternative here.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds value beyond that by disclosing the upstream data source (BDNS) and naming the returned fields (plazo, presupuesto, beneficiarios, estado) — useful since no output schema exists. It does not describe ordering, pagination or result-volume behavior, 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 purpose, followed by returns, a worked example, and the alternative tool — a logical order with no filler sentences. It is slightly dense but every sentence carries information an agent needs.

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 12-parameter search tool with no output schema and full schema coverage, the description supplies the missing pieces: data source, return fields, an example, and sibling routing, while annotations carry the safety profile. Minor gaps remain around pagination/default limit behavior, but nothing critical 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%, so the baseline would be 3. The description exceeds that by giving a concrete parameter-combination example that clarifies how texto, comunidad and beneficiario are meant to be used together, adding meaning beyond the individual field descriptions.

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 (busca) and resource (convocatorias de ayudas y subvenciones), and defines the scope precisely: any Spanish administration, sourced from the Base de Datos Nacional de Subvenciones. It also names the sibling ayudas_recuento for the counting/comparison case, so an agent can distinguish it without opening a 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 routes the counting/comparison case to ayudas_recuento and supplies a concrete worked example mapping a real request to parameters (texto 'digital*', comunidad 'galicia', beneficiario 'autonomo-o-pyme'). It does not cover when NOT to use this tool (e.g. retrieving a single grant, which ayuda_detalle presumably handles), so it is strong but not exhaustive.

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 cover readOnly/idempotent/openWorld/non-destructive, so the safety profile is settled. The description adds genuinely useful domain context the annotations cannot: it is a statistical forecast with inherent error, not an official announcement, which sets correct expectations for the agent and the user. Confidence/error behavior is also surfaced in the incluir_baja_confianza param.

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-loads the purpose, then the use case, then the critical caveat, then a concrete example. No filler; every sentence adds selection or interpretation value.

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 11-parameter, all-optional, no-output-schema tool, the description supplies scope, intent, caveat and example, while annotations carry the safety profile and the schema carries parameter detail. Nothing needed to select or invoke it correctly 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%, so all 11 parameters are already documented with defaults, enums and semantics. The example supplies a light mapping from intent to parameters (dias 60, beneficiario, comunidad), but adds little beyond what the schema already states. 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 resource (ayudas/grants) and a distinctive scope: grants that recur annually and, per BDNS history since 2021, are due soon or are delayed. Cleverly distinguishes itself from a plain search tool by framing the output as a forecast calendar rather than a listing.

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 a clear use case ('preparar la documentación antes de que se abra el plazo') and a worked example mapping a natural-language query to specific parameters (comunidad, beneficiario, dias). It does not explicitly name a sibling like ayudas_buscar as the alternative for already-open grants, relying on the 'previsión, no anuncio oficial' framing instead.

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 read-only, non-destructive, idempotent, open-world behavior. The description adds useful operational context: grouping by comunidad or finalidad triggers one BDNS query per group, taking about 20 seconds initially and being immediate on repeat.

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 front-loaded with purpose, then examples, then performance. Every sentence carries useful information and there is 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?

Given 12 parameters and no output schema, the description does well by explaining that it returns exact counts/rankings grouped by dimension. It could be slightly more explicit about the returned structure or grouping limits, but it is sufficient 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?

Schema coverage is high at 92%, so most parameter meaning is already documented. The description still adds value by giving example parameter combinations and clarifying the grouping behavior that drives latency.

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: exact counts and rankings of grant calls, grouped by named dimensions. It clearly distinguishes aggregate counting from sibling search/detail tools, and the examples make the intended output obvious.

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?

Provides explicit example questions and maps them to concrete parameters, giving clear context for when to use the tool. It does not name alternatives such as ayudas_buscar or give when-not-to-use guidance, so it falls short of a 5.

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 readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond them: sections are located by rule-based title matching, NOT AI, and the user is told to 'comprueba siempre la página citada' — a caveat about extraction reliability that structured fields cannot convey.

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 sentences, front-loaded with purpose then usage condition then a reliability caveat. Dense but each sentence carries distinct information; slightly long with the enumerated apartados list duplicating what the schema already enumerates.

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?

No output schema exists, so the description must describe the return shape — it does ('texto LITERAL de sus apartados... con el número de página') and notes that documento ids come from this same tool's output. Combined with the schema covering the 4-page and 30000-char limits, an agent has enough to call it correctly; only the exact return format details are left implicit.

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 every parameter (temas, buscar, codigo, paginas, documento, max_caracteres) is already documented in the schema. The description only echoes the default sections and the words/pages mode in prose, adding little beyond the schema's own descriptions. 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 (lee/devuelve) on a specific resource (el PDF de las bases o convocatoria) and specifies the scope: el texto LITERAL de sus apartados con el número de página. It explicitly carves out the niche versus structured data ('el texto completo que la BDNS no resume'), so an agent can distinguish it from ayuda_detalle 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?

Gives an explicit trigger condition ('Úsala cuando haga falta la cuantía por beneficiario, los requisitos o la documentación, que no constan en los datos estructurados'), clearly signaling when this tool beats the structured-data siblings. It does not name the specific alternative tool (e.g. ayuda_detalle), so routing is clear but not fully enumerated.

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, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds genuine non-obvious behavior: the hard 31-day maximum range and the fact that all words must match (AND, not OR) across title/department/epígrafe — both are error-preventing details absent from the 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?

Two sentences, front-loaded with the core action and constraint (date range, max 31 days) before the qualifiers. The second sentence delivers concrete examples with no filler; 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?

Given 4 params, no output schema, and rich annotations, the description covers the key constraints an agent needs (range cap, AND semantics, optional sections). The one gap is that it never says what is returned (list of publications, ordering/pagination), which matters since there is no output 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 coverage is 75%, but the description still adds meaning beyond it: matching is conjunctive ('todas las palabras'), which fields are searched, and that sections are optional. The example 'enfermer*' reveals wildcard/partial matching that the schema does not document.

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 ('Busca') and resource ('publicaciones del BOE') and describes the search scope (title, department, epígrafe) plus the AND semantics of the keywords. The purpose is unambiguous, but it never explicitly differentiates itself from siblings like boe_sumario_dia or boe_documento, which the 5-level requires.

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 worked examples ('oposiciones de enfermería', 'licitaciones de software') imply intended scenarios, but they primarily illustrate parameter patterns rather than routing. There is no explicit statement of when to prefer this tool over boe_sumario_dia or boe_documento, so guidance remains implied.

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, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds that it returns plain text, which is useful, but does not mention rate limits, truncation behavior, or what happens for large documents.

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 efficient sentence that front-loads the verb and resource. It is appropriately sized and wastes no words.

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 tool that can return large documents (max 50,000 characters) with no output schema, the description should explain return format, truncation, or size limits. Combined with incomplete parameter documentation, it leaves the agent guessing about the output.

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 50%. The description explains the 'id' parameter format with an example, but gives no information about 'max_caracteres' — its purpose, default, or truncation behavior — leaving a significant 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?

States a specific verb (Devuelve) and resource (texto plano de una publicación del BOE) and identifies the input type. It explicitly names boe_sumario_dia and boe_buscar as the sources of the identifier, distinguishing it from those siblings.

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 usage context by telling the agent where the required identifier comes from (boe_sumario_dia or boe_buscar), which routes the agent correctly. However, it does not state when not to use this tool or what happens with invalid identifiers.

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, idempotentHint and non-destructive behavior, and the description is consistent with them. It adds context beyond the annotations: the today default and the Sunday non-publication rule, both operationally relevant for shaping a query.

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 tightly written sentences with zero waste, front-loading the core action and following with the filters and the Sunday caveat. Every clause carries information the agent needs.

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?

Adequate for a read-only list tool whose safety profile is covered by annotations, but with no output schema the description never indicates what a returned 'publicación' contains or how results relate to boe_documento for follow-up. This is a modest gap for a summarization tool.

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 67% and the schema itself richly documents the parameters, including the YYYY-MM-DD pattern, the '*' prefix semantics, and the full section enum. The description only restates the filters at a high level and confirms the today default, adding little beyond what the schema already provides.

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

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

States a specific verb ('Lista') and resource ('publicaciones del BOE') scoped to a single day, with optional keyword and section filters. It is clearly distinct from siblings like boe_buscar (search) and boe_documento (document lookup), though it doesn't name those alternatives 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?

Gives a useful default ('por defecto, hoy') and a real usage constraint ('El BOE no se publica los domingos'), which tells the agent when a day query is futile. However, it offers no explicit guidance on when to prefer this over boe_buscar for the same retrieval task.

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, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered structurally. The description adds real context beyond that by disclosing that it performs live queries against external sources (BDNS, BOE) and reports on a temporary cache and a planned calendar. It does not say anything about latency, external-source availability, or failure behavior, so it does not reach a 4.

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 filler, opening with the core question ('De dónde salen los datos') and then listing the three components. Efficient and easy to scan; it could arguably break the three status areas out slightly more for faster parsing.

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?

There is no output schema, so the description has to convey what comes back, and it does so by naming the three reported areas: live source query status, cache state, and the planned calendar. For a zero-parameter status tool this is close to complete; only the response shape (e.g., per-source flags versus free text) remains 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 baseline there is nothing for the description to disambiguate. Schema description coverage is 100% and the empty object schema is unambiguous. No parameter information is missing.

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 concrete resource (data provenance/state) and enumerates the three things inspected: live BDNS and BOE queries, temporary cache state, and the planned calendar. That is enough for an agent to tell it apart from the sibling retrieval tools (boe_*, ayudas_*), which fetch content rather than report system status. It stops short of 5 because the verb is nominal ('estado') rather than an explicit action.

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 implied: this is plainly a diagnostic/freshness-check tool, and a reader can infer it is called to verify where data stands before relying on other tools. However, no explicit when-to-use condition, prerequisite, or alternative is stated, and none of the siblings is named as a contrasting option. Implied-but-not-stated guidance lands at 3.

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 readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful behavioral context beyond that: only non-closed ayudas and only items within the recent day window. It does not say how results are ordered or whether there are caps on returned items.

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, front-loaded with what is returned and the scope constraint (open ayudas, recent days). The closing audience list (autónomo, pyme, gestoría, asociación) is somewhat expendable but cheaply sets the context.

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?

No output schema, and with five all-optional parameters the description never states the default behavior when nothing is supplied (e.g. does an empty 'palabras' return all topics for the last 7 days?). It is adequate for the aggregation concept but leaves the zero-argument invocation ambiguous.

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% and three parameters carry enums with documented meanings, so the schema does the heavy lifting. The description reinforces that 'palabras' means the profile's topics and that results cover both sources, but adds no format or default-behavior 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 combined resource: a digest of newly published ayudas (only those still open) plus BOE items matching a profile's topics. This is clearly distinguishable from siblings like ayudas_buscar or boe_sumario_dia, which are single-source lookup tools. It stops short of explicitly naming those siblings as the alternative, so it is clear but not maximally differentiated.

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?

'Pensado como boletín semanal' implies a recurring digest use case, which is useful context. However, it gives no explicit when-not guidance nor points to ayudas_buscar/boe_buscar for targeted single-source queries, leaving the agent to infer the boundary.

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