search_econ_seriesSearch the Econ Data Library catalog (billions of series from 300+ sources: national accounts, prices, trade, labor, energy, markets…). Free, no key needed. Returns series ids usable with get_econ_series.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| query | Yes | Free-text search, e.g. 'germany inflation' or 'GDP per capita' | |
| source | No | Restrict to one source id, e.g. 'worldbank', 'ecb', 'imf_weo' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true. Description adds that the tool is free and requires no key, helpful for authentication context. No mention of rate limits or pagination, but sufficient given read-only nature.
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 zero waste. Front-loaded with core purpose, then authentication and output usage. Excellent conciseness.
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 3 parameters and no output schema, description covers purpose, output usage, and authentication. Lacks pagination or error behavior details, but largely complete given tool simplicity and sibling context.
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 67% with examples for query and source. Tool description adds no parameter-specific information beyond schema, so 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 states it searches the Econ Data Library catalog, listing billions of series from 300+ sources. It distinguishes from siblings like get_econ_series by specifying it returns series ids.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says 'Free, no key needed' indicating zero authentication. Suggests workflow by noting results are usable with get_econ_series. Lacks explicit when-not scenarios but provides sufficient context.
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 targets a distinct resource/action: auth status, freshness, econ series, metadata, family status, HF/IP download links, dictionaries, source listings, and search. No overlapping functionality.
All tool names follow a consistent verb_noun pattern: get_* for retrieving specific items, list_* for enumerations, search_* for queries. Naming is uniform and predictable.
11 tools is well-scoped for a data library server covering multiple domains (econ, HF, IP) with retrieval, metadata, listings, and status checks. No redundancy or excessive granularity.
The toolset covers the full lifecycle for a read-only data service: status/auth, search, retrieval (via download links), metadata, variable dictionaries, and source listings. No obvious gaps for the stated purpose.