Datos PE MCP

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

No annotations exist, so the description carries the full behavioral burden, and it delivers very little. It does not say whether this is a read-only operation, whether auth or API keys are required, whether missing OCIDs error or return empty, or what 'detalle' actually 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?

The one-line purpose is front-loaded and the Args block is compact, contributing a useful example rather than padding. Slight redundancy between the prose and the Args line keeps it from 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?

With no output schema, the description is the only place an agent could learn the shape of the returned 'detalle', but it says nothing about return fields, structure, or errors. For a lookup tool this leaves a real gap.

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: it defines ocid as an OCDS identifier and supplies a concrete example format (`ocds-dgv273-seacev3-999999`), which is meaningfully more than the schema's bare 'string'.

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 detalle de un proceso por su OCID'. An agent can distinguish this retrieve-by-identifier tool from the sibling contrataciones_buscar, though the description never names that sibling 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: use it when you already hold an OCID and need full detail. There is no explicit statement of when to prefer this over contrataciones_buscar or contrataciones_ultimas, nor any prerequisite or exclusion.

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 well: it discloses that the OECE API does not filter server-side, that filtering happens locally, that each page returns 20 records, and that paginas is capped at 1–10. This is exactly the cost/latency context an agent needs before requesting many pages. It stops short of describing response fields or total-count behavior.

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 operation, then the key behavioral caveat, then compact Args. Nothing is padded; the only minor dead weight is the formulaic Args formatting for just two parameters.

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, so the description must do more than it does. It covers inputs and the 20-record page granularity, but never says what a returned record looks like or whether results include anything beyond matches, leaving the agent to discover the return shape empirically.

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: consulta is explained as matching comprador, título, descripción or OCID, and paginas is bounded to 1–10. It omits the schema's default of 5 pages, which would be useful for callers deciding whether to pass the argument at all.

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 (procesos de contratación) plus the search surface (comprador, título, descripción u OCID). It is distinguishable from contrataciones_ultimas (latest listings) and contratacion_detalle (single record), though it never names those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the agent infers this is the tool for text queries when it doesn't already know an OCID or want the latest listings. There is no explicit when-to-use vs. when-not, and no mention of the sibling tools that cover detail lookup and recent listings.

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. 'Devuelve' implies a read operation and it discloses a fixed return of 20 items and 1-indexed pagination, but omits auth requirements, rate limits, ordering, and pagination limits.

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?

Very short and front-loaded, stating the return before the argument. The Args formatting is slightly raw but contains 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?

For a simple, 1-parameter list tool with no annotations or output schema, the description covers purpose and the only parameter. It does not describe the returned item structure or any constraints, leaving some gaps for fully informed 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 description coverage is 0%, so the description must compensate. It documents the single parameter as a page number starting at 1, adding the 1-indexed base beyond the schema's title/default, but gives no valid range or page-size detail.

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: returns the latest 20 published contracting processes. This distinguishes it from contrataciones_buscar (search) and contratacion_detalle (detail) by scope, though it does not explicitly name the sibling alternatives.

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 when-to-use guidance or alternatives are mentioned; the description only states the return. It does not indicate when to prefer this over contrataciones_buscar or contratacion_detalle.

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 of behavioral disclosure, yet it says nothing about whether this is a read-only health check, what conditions produce failures, auth needs, or rate limits. It states only the surface purpose.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

A single short sentence with no waste, front-loaded with the verb. It is appropriately sized for a no-argument tool, though it is too terse to carry much information.

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 parameters, no annotations, and no output schema, the description is minimally adequate: an agent can invoke it, but it does not explain what the returned status comprises (service up/down, latency, dataset freshness) or how to interpret it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool takes zero parameters, so per the rubric the baseline is 4. There is no parameter syntax the description needs to clarify.

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 (returns the status of the Peru data service), so the agent can infer this is a health-check style tool. However, 'estado del servicio de datos del Perú' is broad and the description does not differentiate this from the sibling data-fetching tools (contrataciones_*, norma_*, tipo_cambio), which all serve the same Peru dataset.

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 gives no indication of when to call this tool versus the siblings, nor any prerequisite or trigger condition. The agent must guess that this is a status/health probe rather than a data retrieval call.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses the date-range filter and offset-based pagination ('0 es la primera página'), but says nothing about result volume per page, ordering, permissions, or rate limits.

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 and the parameter list is compact with no filler. Structure is appropriate for a search tool, though the Args block is the only place meaning lives.

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 search tool with no output schema and no annotations, key calling details are missing: page size, maximum results, ordering, and the shape of returned norms. What is present (query bounds, date filter, offset) is accurate but not sufficient on its own.

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 documents all four parameters with constraints and formats (2–100 characters, YYYY-MM-DD, start as result offset). Only the exact semantics of 'start' (items vs pages) remains slightly ambiguous.

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: searching ('Busca') norms in the Diario Oficial El Peruano. This clearly separates it from norma_detalle (detail lookup) and from the contrataciones siblings, though it never names an 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?

Usage is only implied by the verb 'Busca' versus the sibling 'norma_detalle'; there is no explicit when-to-use, when-not-to-use, or alternative routing. An agent can infer search-vs-detail, but nothing in the text confirms it.

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 the qualitative return value (the norm's text), but says nothing about failure behavior for an invalid route, whether the text is plain/HTML, or whether content is truncated.

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?

Short and front-loaded with the purpose, followed by a single argument note. The 'Args:' block is slightly ceremonial for one parameter, but the example it carries 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?

For a one-parameter read tool with no output schema and no annotations, the essentials (what it returns, how to identify the norm) are present. Missing is routing to norma_buscar for obtaining the route and any hint about response size or error cases.

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. It does: it explains id_o_url semantics and gives a concrete example format (`NL/2565770-1`) plus the accepted alternative of a full device URL, which the schema alone would not convey.

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 returns the text of a norm retrievable by route or URL. That cleanly distinguishes it from search-oriented siblings, but it never names norma_buscar, which is the tool that presumably produces the id_o_url this tool consumes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Usage is only implied: the name 'detalle' plus the requirement of a route/URL suggests fetching a single known norm after searching. There is no explicit statement of when to use this versus norma_buscar, nor any prerequisite that the id must come from a prior search.

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 usefully discloses the default date window ('hace 30 días' to 'hoy') and the read-only nature implied by 'Consulta', but says nothing about authentication, rate limits, error behavior for unknown codes, or the data frequency returned.

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 front-loaded purpose sentence followed by a tight per-argument list. Every line adds information the schema does not carry, 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 three-parameter tool with no annotations and no output schema, the parameter side is well covered but the description never indicates what a call returns (observations, units, frequency) or the failure modes. Adequate but with clear gaps given the absence of both annotations and an 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 description coverage is 0%, yet the description documents all three parameters: a concrete example series code (`PD04640PD`), the YYYY-MM-DD date format for both date bounds, and their defaults. It compensates well for the empty schema, though it omits what happens when codigo is invalid or when desde is after hasta.

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 ('Consulta cualquier serie del BCRP por su código'), and the scope word 'cualquier' signals it covers arbitrary series rather than one fixed indicator. It does not explicitly name or contrast with the sibling tipo_cambio, which is the nearest alternative, so it stops 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?

Usage is implied by the scope statement plus the documented defaults (last 30 days through today), so an agent can infer the general-purpose query case. There is no explicit when-to-use/when-not-to-use guidance and no mention of tipo_cambio as the alternative for the exchange-rate series.

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; 'Consulta' implies a read-only lookup, but read-only status, auth needs, and rate limits are never stated. It does add genuinely useful behavioral context the schema lacks: the real defaults (last 30 days / today) and the date format, since the schema only shows empty-string defaults.

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 purpose sentence followed by a compact Args block; nothing is padded. The Args block is slightly redundant with the schema but justified given the schema's empty defaults.

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-param read-only date-range lookup with no output schema, the definition supplies everything needed to invoke it correctly: resource, units (soles per dollar), format, and defaults. Return-shape details are a minor gap that does not block 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 description coverage is 0% and both params have useless empty-string defaults in the schema, so the description must compensate — and it does, giving the YYYY-MM-DD format and the effective default for each of desde and hasta. It stops short of saying whether the range is inclusive or how wide a range is allowed.

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: queries the SBS 'venta' exchange rate (soles per dollar) from the BCRP, which clearly separates it from the contrataciones and norma_* siblings. However, it never distinguishes itself from serie_bcrp, the other BCRP-data sibling, so an agent cannot tell which one to reach for.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not guidance, no mention of alternatives, and no prerequisites or rate-limit notes. The only implied usage is 'call it to get an exchange rate for a date window', which the agent must infer from the description alone.

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