Get U.S. Treasury yield curve data — daily yields for maturities from 1-month to 30-year. Essential for understanding interest rate environment and yield curve shape.
| Name | Required | Description | Default |
|---|---|---|---|
| days | No | Days of daily history to return, 1-3650 (default 30 = last month) |
Changes observed during successful MCP inspections. Dates show when Glama detected each change.
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 explains that the tool returns daily yields for specific maturities, but does not mention the data source, freshness, or any rate limits. The behavior is mostly transparent for a straightforward data retrieval 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 two concise sentences with no extraneous information. It front-loads the core purpose and follows with a contextual usage hint, making it easy to parse quickly.
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 retrieval tool with one parameter and no output schema, the description is mostly complete. It explains the data and purpose, though it could briefly mention the return format (e.g., array of objects with date and yields).
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 provides 100% coverage with a clear description for the single 'days' parameter. The tool description adds no additional semantic information about the parameter beyond what the schema already states.
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 U.S. Treasury yield curve data, specifying the yield maturities (1-month to 30-year) and the use case (understanding interest rate environment and yield curve shape). It distinguishes itself from sibling tools like get_fed_rates (Fed funds) and get_economic_indicators (broad indicators) by focusing specifically on the yield curve.
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 interest rate analysis, but does not explicitly guide when to use this tool versus alternatives such as get_fed_rates or get_economic_indicators. No 'when not to use' or trade-offs are mentioned.
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 and action, and descriptions explicitly disambiguate similar pairs (e.g., get_congress_member vs get_congress_trades, get_crypto_holder vs get_crypto_holders). No two tools appear to do the same thing.
The dominant pattern is get_<noun>, with list_<noun> for enumerations. Minor deviations exist: a bare 'search' tool and the 'sec_' prefix on SEC filing tools break the uniform verb_noun style, but the pattern remains predictable.
At 24 tools, this is on the heavier side, but the server spans multiple financial data domains (SEC filings, stocks, insider trading, crypto, rates, economics), so each tool has a clear purpose. It is just below the 'too many' threshold.
The tool surface is remarkably complete for financial data retrieval: SEC filing lifecycle is covered (list -> index -> document), institutional ownership is available from both stock and institution perspectives, and insider/congress/crypto/economic data are all present. No obvious gaps or dead ends.