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

With no annotations, the description carries full burden and does so well: it discloses the 10-40s latency without a cuadernillo filter, cross-page duplicate results, internal deduplication, caching via `cacheado`, and a structured no-results path (`sin_resultados_motivo` + `nota`). It omits auth/rate-limit context, but the operational behavior is unusually well 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?

Front-loaded purpose followed by clearly headed Args and Devuelve blocks, so an agent can scan to the relevant field. It is long, but for an 8-parameter tool with zero schema documentation every section earns its place; only marginal tightening is possible.

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 no annotations exist, so the description must carry everything, and it does: it enumerates return fields (coincidencias_texto vs dispositivos_unicos, data, cuadernillos_con_coincidencias, siguiente_start, cacheado, sin_resultados_motivo), explains the compact-cuadernillo case, and covers pagination and latency. Nothing needed to call 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 coverage is 0%, so the description must compensate for all 8 parameters and it does: `consulta` explains quoting for exact phrases and non-strict AND, `cuadernillo` lists valid siglas and points to listar_tipos_publicacion, `sector` clarifies substring post-filtering scope, `start` gives the page-to-offset formula, and `paginas` explains batching and dedup. This is exemplary coverage of otherwise undocumented parameters.

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 ("Busca dispositivos y cuadernillos en El Peruano"), immediately telling the agent what corpus is searched. It references one sibling (listar_tipos_publicacion) as a lookup aid, but never disambiguates itself from buscar_por_op or the obtener_* tools, so routing is only partially enabled.

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 concrete in-tool guidance (use `paginas` instead of manual `start` due to duplicate devices, `sector` is only a post-filter on the current page), which is genuinely useful. However, it never states when to choose this tool over buscar_por_op or when the obtener_* tools are the right follow-up, so alternative selection 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 are provided, so the description carries the full behavioral burden. 'Búsqueda puntual' weakly implies a read-only exact lookup, but it says nothing about error/not-found behavior, permissions, or the response shape — significant gaps 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 lines, front-loaded with the purpose before the arg detail, with no wasted prose. The 'Args:' block is slightly awkward but not bloated.

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 and no annotations, the description should hint at what a successful lookup yields and what happens when the OP is not found. It covers the input format adequately but leaves the return value and failure mode 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?

Schema description coverage is 0%, and the parameter is nothing but 'type: string, title: Op'. The description compensates well by specifying the required format 'NNNNNNN-N' and giving a concrete example ('2558398-1'), which is exactly the information an agent needs and that the 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?

The description names a specific verb+resource: an exact ('puntual') lookup by publication order number (OP). However, it never says what the search returns (a device? a publication record?) or how it relates to the sibling tools like buscar_dispositivos and obtener_dispositivo, so the agent cannot fully tell it apart from its neighbors.

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 word 'puntual' implies an exact-match lookup rather than a bulk listing, but there is no explicit when-to-use guidance, no prerequisites, and no mention of when to prefer buscar_dispositivos or the obtener_* siblings 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?

With no annotations, the description carries the burden and discloses meaningful behavior: the MCP does not download or store anything, it only returns a public URL, and it additionally returns url_viewer. It also warns about the page-suffix naming quirk. Auth/permission and error behavior are not covered.

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 behavior, then args in a clean order. Most sentences earn their place, though the detailed note about the page-suffix filename is somewhat tangential to the core call.

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, the description covers purpose, return values (URL plus url_viewer), and the non-download semantics adequately. Minor gaps remain around error cases and whether the returned URL requires any authorization.

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%, so the description must define the single parameter, and it does: codigo is TIPO+FECHA with concrete examples ('NL20230923', 'PC20260927'). The format and examples go well beyond the bare 'string' schema, compensating for the zero coverage.

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 (URL de descarga del PDF completo de un cuadernillo) and clarifies the actual verb is 'resolver/return URL', not download, correcting the misleading name 'descargar'. It distinguishes its domain by noting it is the only text route for cuadernillos SIN dispositivo individual, though it does not name the specific sibling to use otherwise.

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 context: it is the only text path for cuadernillos that lack an individual device (PC/DJ/JU/CA/IN/TU), which implicitly excludes them from the device-based tools. It stops short of explicitly naming the alternative sibling (e.g. obtener_dispositivo_texto) for those cases.

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 delivers the single most important trait: the MCP never stores files and only returns a public URL on busquedas.elperuano.pe. This directly clarifies that despite the name 'descargar_pdf', no file is downloaded. It omits auth or rate-limit context, 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 compact, front-loaded sentences: purpose first, then the key caveat, then arg definitions. No filler; the only slight redundancy is the title restating URL resolution.

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 tool with no annotations and no output schema, the description covers purpose, the critical non-storage behavior, and both parameters. An agent can call it correctly without further inference, though sibling routing remains 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 0%, so the description must compensate, and it does: it explains 'cuadernillo' as a publication code with a pointer to listar_tipos_publicacion and 'op' as an order number with the concrete example '2558398-1'. Both required params gain meaning beyond the bare string types.

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 action and resource: it returns the download URL of the PDF for an individual 'dispositivo'. The phrase 'de un dispositivo individual' implicitly contrasts with the sibling descargar_cuadernillo (bulk publications), helping disambiguation, 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?

It tells the agent to use listar_tipos_publicacion for the 'cuadernillo' code and clarifies the user must perform the actual download, but it never states when to prefer this tool over siblings like obtener_dispositivo, buscar_por_op, or descargar_cuadernillo.

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 present, the description carries the full burden and does disclose valuable traits: results include pdf_url, an empty fecha defaults to the latest publications, and the range is capped at 7 days inclusive per call. It omits permissions/auth, pagination, and the full return shape, so it adds context but not a complete behavioral picture.

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 purpose is front-loaded in one sentence, followed by a compact Args block. Every line carries useful information with no filler; only minor stylistic roughness prevents a 5.

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, and the description names the key returned field (pdf_url) and the important 7-day range constraint. Given the absence of annotations, this is a fairly complete picture for a list tool, though pagination and result ordering are left 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 0%, so the description must compensate, and it largely does: it enumerates accepted date formats (YYYYMMDD, AAAA-MM-DD, DD/MM/AAAA), explains the empty-value default, clarifies fecha_fin's optional rango semantics and 7-day limit, and gives an example sigla for tipo. This meaningfully exceeds what the bare schema 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 (cuadernillos publicados) plus the scope (published in a date or range, with pdf_url). An agent distinguishes it from the singular obtener_*/descargar_* siblings. It does not explicitly differentiate itself from the other listar_* tool (listar_tipos_publicacion), keeping 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?

Usage is implied by the fecha/fecha_fin mechanics and the note that an empty fecha returns the latest published items, which tells the agent how to get 'most recent'. However, there is no explicit when-to-use guidance versus descargar_cuadernillo, obtener_cuadernillo_texto, or the buscar_* siblings, so the routing decision is inferred 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?

No annotations exist, so the description carries the full burden. It discloses one meaningful behavioral trait: some publication types lack an individual dispositivo and their integral text is only in the PDF. It does not describe the shape of the returned listing or any ordering/completeness guarantees, leaving a gap for a no-annotation 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?

Two short sentences/paragraphs with no filler; the core listing purpose is front-loaded before the caveat. The second sentence is slightly tangential in that it describes behavior of other tools, but it earns its place as cross-tool routing 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?

With no output schema and no annotations, the description is the only source of truth. It conveys what is returned at a high level and one important caveat, but it never describes the structure of the listing or how the siglas map to the sibling search/retrieval tools, so an agent must infer the rest.

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 there is no parameter semantics to explain; the baseline of 4 applies. The description does not introduce spurious parameter-like concepts.

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 the resource and its output content clearly: it returns the abbreviations (siglas) of cuadernillos, identified as tipoPublicacion, together with their titles. That is enough to distinguish it from the lookup/retrieval siblings like buscar_dispositivos or descargar_cuadernillo, though it never explicitly says it enumerates all valid type codes.

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 adds useful downstream context — that PC/DJ/JU/CA/IN/TU have no individual dispositivo and that their full text only lives in the booklet PDF — effectively pointing to descargar_cuadernillo. However, it never states when to call this tool itself (e.g. to discover valid tipoPublicacion values before searching), so the usage 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?

With no annotations, the description carries the full behavioral burden and does well: the PDF is downloaded into memory, processed page by page, never persisted to disk, with a hard cap of 10 pages per call and case-insensitive matching across all pages. It omits permission/auth requirements, error behavior for invalid codigo, and what the returned page text looks like.

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 core capability and scope before the Args block; each sentence adds distinct information (search vs range mode, memory-only processing, page cap, query behavior) with no filler or repetition.

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 4-parameter tool with 0% schema description coverage and no annotations or output schema, the description covers access mode, limits, parameter semantics, and roughly what query returns (pages plus context extracts). Return shape for the page-range mode and failure modes for a bad codigo are the remaining 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?

Schema coverage is 0%, so the description must compensate and it does fully: codigo is specified as TIPO+FECHA with a concrete example ('PC20260927'), pagina_desde/pagina_hasta are 1-indexed and inclusive with a 10-page maximum, and query is optional, case-insensitive over all pages, and overrides the range. Every parameter gains meaning beyond the bare 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 ('Busca texto DENTRO del PDF de un cuadernillo' / reads its text by pages) and immediately scopes itself within the tool family by declaring it is the only integral-text read path for cuadernillos without an individual page (PC/DJ/JU/CA/IN/TU), which separates it from siblings like obtener_dispositivo_texto.

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 conditional guidance: use query to search across an entire PDF (recommended for PDFs of hundreds of pages), otherwise read controlled page ranges, and explicitly states query ignores pagina_desde/pagina_hasta. It implies the alternative (per-page tools) by defining its audience as cuadernillos WITHOUT an individual page, but never names that sibling or states a hard 'do not use when' condition.

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 discloses a meaningful behavioral trait (the integral text can be very long) and documents default behavior (cuadernillo auto-resolved from OP; empty desde/hasta returns full text). It omits auth/permission or error behavior, but for a read-only retrieval tool the disclosure is solid.

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 return contents, then a usage note, then a structured Args block. Every sentence carries information and nothing is padded, though the Args block is somewhat verbose in restating each parameter.

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 or annotations, the description fills the gap by describing the returned fields, the parameter semantics, and the alternative tool. It is complete for calling the tool correctly, with only incidental gaps around error or edge-case behavior.

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, and it does thoroughly: cuadernillo is a publication sigla that is optional and auto-resolved from OP; op is a numero de orden with a format example ('2558398-1'); desde/hasta are optional 1-indexed inclusive paragraph ranges where empty means full text. This adds real meaning well beyond the bare schema titles.

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 el dispositivo completo') and enumerates the returned fields (sumilla, tipo, numero, sector, fechas, texto integral, pdf_url, thumbnail). It distinguishes itself from obtener_dispositivo_texto, though it does not clearly set itself apart from buscar_por_op or buscar_dispositivos.

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 agent: for long documents use obtener_dispositivo_texto with paragraph ranges, or constrain this call with desde/hasta. It also points to listar_tipos_publicacion for the cuadernillo argument. Both the alternative and the condition selecting it are named.

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 useful behavior: paragraphs are 1-indexed inclusive, ranges are the paging mechanism, returned content includes metadata (sumilla, tipo, numero, sector, fecha), and there is no paragraph cap. It omits error behavior (invalid op/cuadernillo), what auto-resolution means on failure, and any auth or rate considerations, leaving meaningful gaps for a read 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?

Front-loaded with the core purpose, then return contents, then a per-argument list – a sensible ordering with little waste. There is minor tension between 'dosis controladas' and 'Sin tope de parrafos: usa rangos razonables', which slightly muddies an otherwise tight description.

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 and no annotations, the description does cover what a caller needs: purpose, the paragraph-paging model, return content (text + metadata), and all four arguments. What is missing is guidance on how to obtain 'op'/cuadernillo correctly (the sibling lookup tools) and any error or edge behavior, which keeps it short of full completeness.

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 carry the parameters, and it largely does: cuadernillo is optional and auto-resolved from OP, op is the orden de publicación, and desde/hasta are an inclusive 1-indexed paragraph range. The added semantics (optionality, indexing convention, auto-resolution) are not in the schema; only 'op' remains thinly described as just 'numero de orden'.

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: retrieve the text of a dispositivos (device/legal item) paragraph by paragraph, plus its metadata. The 'texto' scope implicitly distinguishes it from obtener_dispositivo (metadata only) and obtener_cuadernillo_texto (whole-quadernillo text), but no sibling is named explicitly, so the differentiation 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 a contextual cue for use – 'dosis controladas (para documentos largos sin saturar el contexto)' and 'Sin tope de parrafos: usa rangos razonables' – which hints at pagination strategy. However, it never says when to prefer this over obtener_dispositivo or obtener_cuadernillo_texto, and gives no prerequisites or exclusions.

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