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

With no annotations provided, the description carries the full burden of behavioral disclosure. It communicates that the operation is lightweight ('without fetching all data points'), read-only in nature, and that it returns series names, frequency, decimal precision, and available date range. This is meaningful behavioral context, though it does not cover error behavior 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 description is three sentences with no filler. The core purpose is front-loaded, the return fields are listed compactly, and the usage guidance names the sibling tool explicitly. Every sentence 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 low-complexity tool with two parameters and no output schema, the description provides sufficient context: what it does, what it returns, when to use it, and how it differs from the related fetching tool. An agent can correctly decide to call it and knows what kind of result to expect.

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 input schema already provides 100% coverage of both parameters, including min/max items for series_codes and the language options. The description does not add parameter-level detail beyond what the schema states, so it meets the baseline without exceeding it.

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 opens with a specific verb and resource: 'Get metadata about 1–10 BCRP series without fetching all data points.' It clearly distinguishes this tool from bcrp_get_series by emphasizing the metadata-only scope and the batch limit, so an agent can tell what it is 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?

It explicitly states when to use this tool: 'Use this to verify series codes exist and understand what they measure before fetching large date ranges with bcrp_get_series.' This names the alternative tool and the exact condition that should trigger this one.

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 disclosure burden, and it does disclose the two non-obvious behaviors: automatic date-range selection (fetches without specifying a date range) and truncation to the last n_periods values. It does not cover error behavior such as mixed frequencies or insufficient history, but the operational meaning of 'latest' is clearly explained.

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: core purpose first, then wrapper mechanism, usage context, and example codes. The example section is scoped and earns its place given the cryptic domain codes, though it is the longest section and could be tighter.

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?

The tool has three well-documented parameters but no output schema or annotations, so the description must cover return and edge-case behavior. It states that it returns only the last n_periods values but does not describe the response shape, error cases (different frequencies, insufficient history), or rate limits. Adequate but with clear gaps.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds genuinely useful example codes for series_codes (PD04637PD, PN00196MM, PN03503MQ), which is real value for a parameter whose values are otherwise opaque numeric strings. It also reinforces the n_periods truncation semantics, pushing it above baseline.

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 first sentence states a specific verb (Get), a precise resource (most recent data points for 1-10 BCRP series), and a constraint (same frequency). It further identifies itself as a convenience wrapper around bcrp_get_series, which cleanly distinguishes it from sibling tools without requiring the reader to inspect other schemas.

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 line 'Use this for quick snapshots of current economic conditions' provides explicit when-to-use context. The wrapper explanation ('fetches latest data without specifying a date range') implies that bcrp_get_series is the alternative when a date range is needed, though it stops short of an explicit when-not-to-use statement.

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 burden. It clearly indicates a read-only fetch operation ('Fetch'), and discloses what data is returned (daily vs. monthly, specific indicators, time spans). It doesn't discuss rate limits or output format, but for a simple read-only snapshot tool, the behavioral context is largely 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?

The description is well-organized with a leading purpose sentence, clear bulleted breakdown of daily and monthly indicators, and a final one-line routing hint. Every sentence earns its place, and the structure makes the content scannable.

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?

The tool has one optional parameter, no output schema, and no annotations. The description compensates well by enumerating the returned indicator groups and values, specifying the monthly lookback period, and naming the sibling for extended use cases. Nothing essential for calling this tool 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?

The only parameter, language, is fully documented in the schema with its allowed values ('esp'/'ing') and default. The description adds nothing beyond the schema, but with 100% schema description coverage the baseline of 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?

The description opens with a specific verb and resource: 'Fetch a real-time snapshot of Peru's key macroeconomic indicators in one call.' It enumerates exactly which indicators are included, and explicitly names bcrp_get_series as the alternative for custom date ranges, distinguishing this tool from 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 clearly states when to use this tool (for a quick snapshot of standard daily and monthly indicators) and explicitly directs the agent to bcrp_get_series for custom date ranges or additional series. This gives concrete routing guidance relative to at least one sibling.

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 behavioral disclosure burden. It explains the 1–10 series limit, the same-frequency requirement, per-frequency period formats, and the empty-period behavior. It does not mention authentication, errors, or return shape, but for a data-fetching tool the provided behavior is substantial.

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 well-structured with clear sections and front-loaded purpose. It is slightly redundant by stating the same-frequency rule twice, but the overall length is justified by the frequency-format complexity.

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 no output schema and no annotations, the description covers code discovery, parameter constraints, and period formatting well. The main gap is not explaining how this tool relates to bcrp_get_latest or bcrp_get_series_long, and not describing what the response looks like, though that is somewhat inferable from the tool name.

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 100%, so the baseline is 3, but the description adds genuine value: consolidated period format examples for monthly, quarterly, daily, and annual frequencies, concrete example series codes, and the explicit same-frequency rule. This goes beyond the schema's individual parameter 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?

The description clearly states it fetches time series data from the BCRP API, naming the resource and the specific verb. It does not explicitly differentiate itself from siblings like bcrp_get_latest or bcrp_get_series_long, but the main purpose is unmistakable.

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 clear usage context: how many series codes are accepted, how to discover codes via bcrp_search_catalog, the period format by frequency, and the same-frequency constraint. It does not explicitly state when to prefer bcrp_get_latest or bcrp_get_series_long, 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?

No annotations are provided, so the description carries the full behavioral burden. It discloses the row schema, the date rendering, that missing observations are omitted rather than null, that each series is fetched separately, and that all_history is bounded by max_rows.

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 compact, front-loaded with the core purpose, then clearly moves to sibling differentiation, return semantics, and parameter guidance. Every sentence adds needed information and no filler is present.

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?

Even without an output schema, the description specifies the exact returned row fields and their semantics, explains key edge-case behavior, and names the main alternative. Given the schema already documents parameters and formats, this is complete enough for an agent to invoke 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, and the description adds meaningful extra context: series_codes can mix frequencies up to 50, all_history behavior is bounded by max_rows, and the output mapping is always correct because series are fetched separately. This goes beyond simply restating 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?

The description opens with a specific verb and resource: 'Fetch MANY BCRP series at once as one tidy long-format table.' It also explicitly contrasts itself with bcrp_get_series, so an agent can immediately tell this tool apart from the closest sibling.

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 names the alternative bcrp_get_series and gives concrete selection criteria: use this when series codes do not share a frequency or when more than 10 codes are needed. It also provides an explicit trigger for all_history=true and notes the max_rows bound.

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 provided, the description carries the full behavioral disclosure burden. It discloses that this is a read-only listing operation and describes the returned elements: category IDs, number of series per category, and frequency. However, it does not specify output shape, ordering, or any edge cases, though this is acceptable for a simple parameterless 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?

The description is compact and front-loaded: one sentence states the purpose, one states the outputs and downstream use, and one lists example categories. Every sentence adds useful information, and the category list helps set expectations without unnecessary padding.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a zero-parameter catalog-listing tool, this definition is nearly complete: it explains the purpose, the output elements, and how the results connect to a sibling tool. The only slight gap is ambiguity in 'their frequency'—whether that means data update frequency or frequency of occurrences—and the lack of an explicit output schema, but neither prevents correct selection or 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?

The tool has zero parameters and the schema already has 100% coverage for that fact. The description adds no parameter-level detail because none is needed. A baseline of 4 is appropriate for a zero-parameter tool.

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 begins with a clear action and resource: 'List all available categories in the BCRP series catalog.' It also states that the returned category IDs are usable as the `category` filter in `bcrp_search_catalog`, which differentiates this tool as a lookup/enumeration utility rather than a series retrieval or search tool.

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 clearly implies when to use this tool: when an agent needs the full set of valid catalog categories, especially before calling bcrp_search_catalog. It connects the output to a sibling tool but does not explicitly state when not to use it or list alternative tools, so it lacks a formal exclusion statement.

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 present, so the description carries the full burden. It states what is returned — series codes, names, descriptions, frequency, units, and period format — and how that output connects to bcrp_get_series. It does not discuss result limits or matching semantics, but the disclosed scope 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?

The description is front-loaded with the purpose and return value, followed by a compact list of useful examples and a cross-reference to a related tool. Every sentence and bullet earns its place without digression.

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 search tool with no output schema, the description explains the return fields, provides representative queries, and points to the relevant sibling tool for category browsing. It is sufficiently complete for an agent to invoke it correctly, though it leaves minor details like result limits 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 100%, so the baseline for parameter semantics is 3. The description adds example query intents, but does not substantially extend the parameter meaning beyond what the schema already documents.

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 opens with a specific verb and resource: 'Search the built-in catalog of important BCRP series by keyword.' It also lists the exact fields returned, clearly distinguishing it from sibling tools such as bcrp_list_catalog_categories and bcrp_get_series.

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 clear usage context via example queries and explicitly routes the agent to bcrp_list_catalog_categories to explore categories. It does not explicitly state an alternative for when a series code is already known, but the search intent is clear.

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