Statistics of the World

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 not disclose whether the operation is read-only, what the output format is, how defaults are selected, or edge-case behavior. The only behavioral detail is the 2-10 country limit, which is also in the schema. This is insufficient.

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 a single, front-loaded sentence with no wasted words, effectively stating the tool's core action.

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 the absence of annotations and output schema, the description is too minimal to provide complete context. It does not explain what the comparison result looks like, how data is sourced, or any caveats. Sibling tools like get_indicator_ranking suggest different purposes, so more detail is needed.

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. The description adds no new parameter details beyond the schema, except clarifying the minimum of 2 countries, but this is minor. The schema already documents both params.

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 uses a specific verb (Compare) and resource (countries on indicators), and the name differentiates it from sibling compare_sources. It also specifies the count range (2-10), making the tool's scope clear.

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 explicit guidance on when to use versus alternatives; the description only states the action. However, the tool's name and context imply it is for multi-country comparisons, while siblings like get_country_overview target single countries. Since this is not explicit, score 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?

With no annotations, the description carries the full burden and does well: it explains that as_of and revision pin SOTW stored state rather than publisher availability, and that the pilot mode exposes definition mismatches and provenance. It omits permissions, rate limits, and response shape, but the state-pinning caveat is a genuinely useful disclosure.

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 front-loaded sentences with no filler: default behavior first, then the pilot-mode condition, then the optional pinning caveats. Some terms ('SOTW', 'recorded-state provenance') are jargon-heavy but each 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 comparison tool with no annotations and no output schema, the description covers both operating modes, the required coupling of parameters, and the meaning of as_of/revision pinning. Missing are auth needs and what a comparison result contains, but the core behavioral picture is complete enough to call 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 schema already documents every parameter, including year, as_of, revision, and country_id. The description reinforces the coupling (year requires country_id, revision requires as_of) but adds little syntax or format information beyond what the schema states, warranting the baseline 3.

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 verb and resource ('Compare source readings') and enumerates what is returned by default (latest IMF, World Bank, UN readings with their own years), which is concrete. It distinguishes the two modes clearly, though it doesn't name the sibling compare_countries to route the agent away from it.

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 gives an explicit condition for switching modes: use the default, or supply country_id and year ('exact year or common') for the 20-economy, 10-concept pilot. It stops short of naming alternatives or stating when not to use the tool, so it is clear context without full routing guidance.

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

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

No annotations are present, so the description carries the burden. It discloses that results are grouped by category, which is useful, but it does not mention permissions, response format details, or pagination. The read-only nature is implied but not stated.

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 a single, front-loaded sentence that efficiently conveys the core action and purpose with no unnecessary 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 simple list tool with no output schema, the description adequately conveys that it returns categories and their indicators. It lacks finer details like filtering semantics or potential size, but the parameter description covers the basics, making this sufficient for its simple nature.

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 schema already provides 100% coverage for the optional category parameter. The description adds 'grouped by category', which infers how the filter relates to the output structure, offering a slight enhancement 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?

The description uses a specific verb 'List' and identifies the resource 'available indicators', adding 'grouped by category' to clarify the output structure. This distinguishes it from sibling tools like search_indicators.

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 does not mention when to use this tool versus alternatives such as search_indicators. It only states what it does, leaving the agent without explicit guidance on tool selection.

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 must carry the full behavioral burden, and it does disclose real constraints: no inferred quarters, no currency conversions, publication pins only guard current registry coherence and do not reconstruct a historical filing snapshot. However, it says nothing about permissions, pagination, limits, or the shape/immutability of returned data, leaving notable gaps.

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, reasonably compact, but dense with opaque jargon like 'immutable acquisition evidence' that does not clearly earn its place. The core purpose is front-loaded, which helps.

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

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

For a 9-parameter tool with 0% schema coverage, no required params, no output schema, and no annotations, the description omits critical operating detail such as how cik/tag/date range combine, default paging via limit, and what nonsense values do. It is not adequate to call the tool confidently.

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 description names none of the 9 parameters (cik, tag, from, to, limit, filed_from, filed_to, evidence, publication). 'Issuer/concept', 'filing dates', and 'publication pins' are faint thematic hints at best and do not compensate for the total lack of parameter documentation.

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 ('Read') and resource ('reviewed SEC company catalog' / 'issuer/concept facts'), which lets an agent distinguish this SEC-facts tool from the economic-data siblings. It is slightly muddled by offering two modes (catalog vs. facts) in one breath, but the subject matter is unambiguous.

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 explicit when-to-use or when-not-to-use guidance and no named alternative among the 16 sibling tools. The only implicit condition is that it returns SEC issuer/concept facts, leaving the agent to infer routing from the name.

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 usefully discloses the return contents (metadata: region, income level, capital) and that the list is complete and static (217 + World aggregate), but says nothing about permissions, cost, or pagination. Adequate but not rich.

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 carrying scope, count, aggregate inclusion, and payload fields with zero 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?

For a trivial read-only, single-optional-param list tool with no output schema and no annotations, the description covers purpose, scope, and the shape of the returned metadata. Only the relationship to sibling lookup/detail tools (e.g. get_country_overview) is 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?

One optional parameter at 100% schema description coverage, so the schema already documents the region filter and baseline 3 applies. The description does not mention the filter at all, and its mention of 'region' as returned metadata could even be momentarily confused with the filter parameter.

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 ('List') and resource ('countries and territories'), and pins down the exact scope: all 217 plus the World aggregate. That completeness implicitly separates it from the singular sibling get_country_overview, so an agent can choose 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?

The description frames this as a directory/reference listing, which implies its role as a lookup source for country identifiers, but it never states when to use it instead of get_country_overview or compare_countries, nor any prerequisites. Usage is only 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?

With no annotations provided, the description carries the burden. It discloses the general behavior (returns multiple statistics) and lists fields, but does not mention time periods, data freshness, or any limitations. This is adequate but not rich.

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

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

One sentence, front-loaded with the action and resource, and uses an example list. No wasted words; it is concise and well-structured.

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 one-parameter tool with no output schema, the description covers the core purpose and return fields. However, it could be improved by specifying whether data reflects current year or a specific timeframe, and it does not reference sibling tools.

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 fully documents the only parameter (country_id) with a detailed description of ISO codes, so the tool description adds no additional parameter semantics. The high schema coverage justifies the baseline score.

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 the tool retrieves key statistics for a country and lists specific examples (GDP, population, life expectancy). It does not explicitly distinguish from sibling tools like get_historical_data or compare_countries, so it misses the top score.

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 when a country overview is needed, but provides no explicit guidance on when to use it versus alternatives such as get_historical_data or get_series_data. This is implied usage, not explicit direction.

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 does add valuable interpretation caveats ('Reference-age screens are not publisher deadlines', 'A single VPS observer is not external uptime monitoring'), but says nothing about permissions, return format, or what the freshness/probe measurements actually contain.

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 four reasonably sized sentences with no obvious repetition, but the lead sentence is dense and front-loads obscure terminology before stating anything an agent can act on. The useful caveats are buried at the end rather than structured.

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 and no annotations, so the description must do more; it partially compensates by explaining how to interpret the status output. Still, with three undocumented parameters at 0% coverage and no return-format description, an agent lacks enough to invoke or read the tool reliably.

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 document all three parameters, yet it explains only matrix (returning definition/geography pairs). The geo and series_id parameters are left entirely undefined in both the schema and the description, leaving most of the parameter surface undocumented.

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 verb 'Inspect' is present and the resource is roughly data freshness, source import ages, and 'operating probes', so an agent can infer this reports data-status/health rather than returning data values. However, the jargon-heavy phrasing ('reviewed macro country-level freshness', 'public operating probes') makes the exact purpose hard to pin down, and it never names how it differs from siblings like get_release_calendar or get_series_data.

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 explicit when-to-use versus the large set of sibling data tools. The closest thing to guidance is the conditional 'matrix=true returns actual definition/geography pairs', which is parameter behavior, not usage context. The closing caveats read as disclaimers rather than routing advice.

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. It usefully discloses a data-quality behavior (unreliable publisher values withheld, raw_value retained) and that reference periods and publishing schedules vary, which is real behavioral context beyond the schema. It does not cover auth requirements, pagination via limit, or what 'reviewed' guarantees, so coverage is only partial.

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 resource list is front-loaded, but two dense sentences carry heavy jargon ('observation-bound evidence', 'national qualifiers', 'complete geography cohort') that slows parsing. It is not bloated but it is not tightly economical either.

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 tool with no annotations and no output schema, the description covers the primary access modes but leaves many parameters and return-shape expectations unaddressed. It is minimally adequate rather than complete.

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 17% (just as_of and revision documented), so the description must compensate. It adds meaning for catalog, series_id, latest, and geo (browse vs cohort vs history), but says nothing about from, to, limit, format, recorded, or generation, leaving roughly half the parameters unexplained across both sources.

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 (Read) and concrete resources (reviewed GDP, inflation, jobs, trade, production, energy, credit packs), so the agent knows this retrieves reviewed economic data. It is clear on its own, but it does not explicitly differentiate itself from siblings like get_series_data or search_data, leaving the boundary 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?

It describes two operating modes (catalog=true to browse, or a series_id with latest/geo for retrieval), which is useful implied usage. However, it never names an alternative sibling or states which condition should route the agent elsewhere, so the when-not guidance is absent.

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 full responsibility for behavioral disclosure. It adds the '20+ years' time span detail, but it does not explicitly state that the operation is read-only, does not mention response format, pagination, authentication needs, or error behavior. The verb 'get' implies a safe read, but the lack of explicit disclosure leaves significant gaps.

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 a single sentence, front-loaded with the core action and scope, and contains no redundant or filler text. Every word adds value, and it is highly 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 is relatively simple with only two parameters and a clear purpose, and the description covers the main functionality. However, it does not explain the return structure of the time series, nor does it clarify how to obtain valid indicator_id or country_id values, and it does not address potential overlap with get_series_data. These omissions leave some operational ambiguity.

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% (both parameters have descriptive comments). The description adds no new parameter-level semantics beyond what the schema already provides—it merely restates 'country and indicator pair,' which maps directly to the two parameters. Per the calibration baseline, a score of 3 is appropriate when the schema already documents all 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?

The description clearly states a specific verb ('Get'), a resource ('historical time series'), and a precise scope ('country and indicator pair', '20+ years'). This effectively distinguishes it from sibling tools like get_series_data by emphasizing the long time span, while also being immediately understandable.

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 conveys clear context: use this tool to retrieve historical time series for a specific country and indicator over 20+ years. It implies the appropriate scenario, though it does not explicitly mention alternative tools or any when-not-to-use conditions.

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 discloses tier-based availability and top/bottom support, but does not explain return format, missing data behavior, or potential errors.

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 with clear front-loaded purpose, no redundancy.

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 description gives a basic overview but lacks output format details and edge-case behavior, leaving the agent uncertain about the response structure.

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?

All three parameters are well-described in the schema, and the description adds nothing beyond the schema. Baseline 3 applies due to high schema 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?

The description clearly states a specific action (rank countries) and resource (indicator available to the caller's tier), distinguishing it from sibling tools like get_historical_data or search_indicators by focusing on ranking/ordering.

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 for ranking queries but does not explicitly state when to prefer this over alternatives like get_historical_data or compare_countries, nor does it mention exclusions.

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 meaningful work: it discloses that values are sampled quotes rather than trades, that quiet/unavailable states and separate definition versions are included, and that pre-collection history does not exist. It does not cover auth needs, pagination, or error/empty 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?

Four dense sentences, front-loaded with what is read before constraints and caveats. Every sentence carries information; slight compression makes it feel terse, but nothing is redundant.

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 with no annotations, no output schema, and 0% schema coverage, the description covers return semantics, data provenance limits, and the key window constraint. The main remaining gap is pagination/limit behavior and result shape, which the agent must infer.

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 supplies the 31-day maximum window (absent from the schema), the UTC timestamp expectation for from/to, and the meaning of market/symbol. Only the 'limit' parameter (max 5000) is left undocumented in both places.

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: reads 'forward sampled pool states or perpetual midpoints' and explicitly distinguishes them from trades or cash-security OHLC. However, it never differentiates itself from close siblings like get_historical_data or get_onchain_quotes, leaving the agent to guess which history tool applies.

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 hard prerequisites (exact market, symbol, UTC from/to, 31-day cap) and a boundary ('no history is inferred before collection began'), which implies when the tool is valid. But there is no explicit when-to-use vs alternatives guidance despite several overlapping history/quote siblings.

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 does disclose meaningful behavior: unavailable prices return null, derivatives mode returns midpoints with original units, source time, spread and depth checks, and catalog=true avoids source reads. It omits auth/permission needs and rate limits, but the operational traits it does give are substantive.

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?

Dense but front-loaded: core purpose first, then mode semantics, then edge cases (null prices, catalog shortcut). A few clauses are compressed to the point of awkwardness but no sentence is wasted.

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 annotations and no output schema, so the description must cover behavior and returns. It handles null handling and per-market return content well, but leaves the category parameter and the overall response shape only partially specified.

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 25%, so the description must compensate and it partly does: it explains both market enum values in depth, the catalog flag's side effect, and the symbol format (perpetual IDs like xyz:SILVER). However, the category enum (11 values) is never addressed, leaving a gap that the low schema coverage was supposed to be filled.

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?

Opens with a specific verb+resource ('Read SOTW-computed public onchain prices') and immediately distinguishes its two market modes. It does not explicitly contrast itself with the sibling tools, but the resource domain is unambiguous.

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?

States the default (market=pools) and what each mode reads, plus the catalog=true shortcut for listing reviewed contracts without source reads. That gives an agent clear routing between the parameter values, though there is no explicit 'when not to use' guidance or sibling routing.

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 to rely on, the description carries the burden and does a solid job: it warns that a passed date does not confirm publication and that related series readings are not verified against the scheduled release. This is meaningful behavioral context beyond the schema, though it does not cover error handling 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 two sentences with no filler. The core subject is front-loaded in the first sentence, and the second sentence packs critical caveats compactly without being verbose.

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 read-oriented calendar tool with fully described optional parameters, the description conveys the main output type, mentions primary source URLs, and provides the key reliability caveats. It is slightly less complete because there is no output schema and the return shape is not described beyond the basic calendar concept.

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 schema already documents all six parameters. The description adds contextual nuance about date-passed status and unverified related series, which is useful, but it does not add per-parameter meaning; 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?

The description clearly identifies the resource: institutional release schedules with primary source URLs, and the tool name 'get_release_calendar' reinforces the action. It distinguishes the tool from data-series siblings by focusing on schedules rather than indicator values, though it does not explicitly contrast it with any 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?

The usage context is implied by 'release schedules': an agent can infer this is for upcoming or past institutional release dates rather than historical data. However, the description offers no explicit when-to-use guidance, no exclusions, and does not name an alternative tool such as get_series_data or get_historical_data.

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, and it largely does not: the only behavioral fact disclosed is that every response carries source licence and attribution. Nothing is said about read-only nature (only implied by 'get'), error behavior, rate limits, or how observations are shaped — truncation/pagination hints live only in the schema.

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?

It leads with the frequency qualifier, which is the most decision-relevant part, but the body is a sprawling single sentence listing dozens of source families. Much of that enumeration is catalog content better suited to list_series, so the description is bulky without being front-loaded with an actual action statement.

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 annotations and no output schema, the description should explain what a response looks like and the read-only nature of the call. It covers data coverage and attribution metadata and routes to list_series for discovery, but omits the nature of the returned observations and any behavioral caveats, leaving notable gaps for a 5-parameter retrieval 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 description coverage is 100%, including defaults, maximums, truncation semantics, and the warning not to combine latest with geo/from/limit, so the schema already does the heavy lifting. The description contributes only additional example series IDs, which is marginally useful but not meaningfully beyond the schema's own examples.

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 enumerates in detail what data families are served (UST yields, SOFR/EFFR/OBFR, BIS policy rates, IMF CPI, OECD bond yields, PORTWATCH, etc.), so an agent can infer the tool retrieves observations for a series. However, the actual operation is never stated in verb+resource form — there is no sentence like 'returns time series observations for a given series_id', leaving the purpose implied rather than declared.

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 only routing guidance is 'Call list_series to browse', which implies this tool is the fetch step after browsing. There is no statement of when to prefer this over the many overlapping siblings (get_economic_data, get_historical_data, get_market_history, compare_sources) and 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.

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

With no annotations available, the description carries the full burden for behavioral transparency. It discloses what the output contains (frequency, unit, source, licence for each series), which is helpful. However, it does not mention any such details as pagination, ordering, or potential limitations, though the simple nature of a list might not require them.

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 a single concise sentence, front-loaded with the verb and resource, and every phrase adds meaning (types of series and returned attributes). No wasted 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?

Given that this is a parameterless list tool with no output schema and low complexity, the description adequately covers what the tool does and what it returns. It is complete for its intended purpose.

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 no parameters, so the description does not need to explain parameter semantics. The baseline for 0 params is 4, and the description provides no irrelevant parameter information.

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 the action ('List') and the resource ('high-frequency series catalog'), and specifies the types of series (rates, yields, monthly labour and energy) and the attributes returned (frequency, unit, source, licence). This distinguishes it from sibling tools like get_series_data (which likely fetches data) and search_indicators (which searches for indicators).

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 for browsing the catalog of high-frequency series when an overview of available series is needed, but it does not explicitly state when to use this tool instead of alternatives like get_available_indicators or search_indicators. No exclusions or alternatives are mentioned.

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 does disclose two non-obvious traits: the exact scope of geo (historical membership only, not freshness or reviewed definitions) and the need to retain 'version' while paging. It does not state whether this is read-only, how results are ordered, or what the response shape is.

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?

Four short sentences with the scope stated first, then behavioral caveats. Nothing is padded, though 'Preserve kind, exact identity, units and source terms' reads as an instruction of unclear intent and costs a sentence without obvious payoff.

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?

Eight parameters, no annotations, no output schema, and zero schema coverage means the description is the only source of truth. It addresses geo and version but leaves the majority of parameters and the overall result shape unaddressed, which is insufficient for a tool this broad.

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% across 8 parameters, so the description must compensate. It explains geo's semantics and version retention, and its resource enumeration hints at 'kind', but source, market, query, page, and limit are left entirely undocumented in both schema and description.

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 verb (Search) and enumerates resource categories that map loosely to the 'kind' enum (annual, economic, series, onchain, company), which is genuinely informative. However, phrases like 'qualified economic definitions' and 'other source time series' are jargon-heavy and ambiguous, and no sibling is named or excluded even though search_indicators and list_series overlap heavily.

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 clarifies one conditional semantic ('geo filters historical source membership... does not establish freshness'), but never says when to choose this tool over search_indicators, get_series_data, or list_series. There is no when-to-use, when-not-to-use, or alternative routing guidance.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It only says 'Search for indicators by keyword' without specifying the return format, search matching behavior (e.g., partial/fuzzy), or any other behavioral traits. This lack of detail could lead to incorrect assumptions about the tool's output.

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 two concise sentences, starting with the action ('Search for indicators by keyword') and then providing the use case. There is no redundant wording or filler, making it easy to parse and front-loaded with essential 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?

For a low-complexity tool with one parameter, no annotations, and no output schema, the description adequately covers the purpose and usage. However, it omits the structure of the response (e.g., list of matching indicators with names and IDs). Since the description hints at finding indicator IDs, it is minimally sufficient but not fully complete.

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 fully documents the single 'query' parameter with examples ('gdp', 'population', etc.), achieving 100% schema coverage. The description does not add extra parameter semantics beyond what the schema already provides. Therefore, the baseline score of 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?

The description states a specific verb and resource: 'Search for indicators by keyword.' This clearly distinguishes it from sibling tools like get_available_indicators or list_series, which focus on listing all indicators or series. The phrase 'find the right indicator ID' reinforces the unique purpose of locating a specific indicator.

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 provides clear usage context: 'Use when you need to find the right indicator ID.' This tells the agent when to invoke the tool but does not explicitly mention alternatives or exclusions. Since sibling tools exist, a contrast would strengthen the guidance, but the context is sufficiently clear for a straightforward search scenario.

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