Get a snapshot of a country's key macro indicators (latest available values): GDP, GDP per capita, GDP growth, inflation, unemployment, and population. Country accepts an ISO code.
| Name | Required | Description | Default |
|---|---|---|---|
| country | Yes | Country as an ISO code or name, e.g. US, USA, or United States. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It adds the useful trait 'latest available values' and 'snapshot,' implying a read-only, point-in-time operation. However, it does not disclose anything about units, currency, data availability, or response structure beyond the indicator names.
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 focused sentence conveys the action, scope, and returned indicators without repetition or filler. The key behavioral distinction ('latest available values') is front-loaded, and the parameter hint is placed at the end.
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 snapshot tool, the description is largely complete: it lists the indicators, states the latest-value behavior, and the schema fully documents the parameter. It would benefit from noting the response format, but the absence of an output schema is partially mitigated by the explicit indicator list.
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% for the single parameter, and the schema already explains that 'country' accepts an ISO code or name. The description's statement that 'Country accepts an ISO code' adds no meaning beyond the schema; it is slightly less complete because it omits country names.
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 ('Get'), a clear resource ('a country'), and the exact content returned ('GDP, GDP per capita, GDP growth, inflation, unemployment, and population'). The word 'snapshot' plus the bundled indicator list distinguishes this from siblings like country_indicator or compare_countries.
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 guidance about when to choose this tool over siblings such as country_indicator, compare_countries, or us_series. The phrase 'latest available values' implies a use case, but it never states an explicit condition or names an alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.
Each tool has a distinct query shape: cross-country single-indicator comparison, single-country time series, single-country snapshot, indicator discovery, and US BLS time series. The descriptions clearly mark these boundaries, so an agent is unlikely to confuse them.
All tool names use lowercase snake_case and are readable, but they mix verb-led names like compare_countries and list_indicators with noun-led names like country_indicator and us_series. This is a minor inconsistency rather than a chaotic or unpredictable pattern.
Five tools is well-scoped for a read-only economic data server. Each tool covers a unique, necessary capability: discovery, single-country indicator history, country snapshots, cross-country comparison, and US BLS data.
Core workflows are covered well: discover indicators, fetch country-level macro data, profile a country, compare countries, and access US series. A minor gap is that cross-country historical comparisons are not directly supported and would require composing multiple country_indicator calls.