treasury-mcp

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 states what data is returned (e.g., BTC holdings, average acquisition cost) but does not cover critical traits like whether this is a read-only operation, potential rate limits, data freshness, error handling, or authentication needs. For a tool with no annotations, this leaves significant behavioral 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 front-loaded with the core purpose in the first sentence, followed by a bullet-like list of return values and a clear parameter explanation. Every sentence adds value without redundancy, and the structure is efficient for quick comprehension.

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 tool's moderate complexity (single parameter, no annotations, but with an output schema), the description is reasonably complete. It explains the purpose, return data, and parameter semantics. Since an output schema exists, it need not detail return values further, though it could improve by addressing behavioral aspects like data sources or limitations.

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 description coverage is 0%, so the description must compensate. It adds meaningful semantics by explaining the 'ticker' parameter as 'Company ticker or key' and providing concrete examples (e.g., 'MSTR', 'METAPLANET'). This clarifies the parameter's purpose and format beyond the bare schema, though it doesn't detail constraints like valid ticker formats or error cases.

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 specific action ('Get detailed Bitcoin treasury holdings') and resource ('for a specific company'), distinguishing it from siblings like get_treasury_companies (which likely lists companies) or get_btc_price (which provides price data). The verb 'Get' combined with the detailed resource scope makes the purpose explicit and differentiated.

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 detailed treasury data for a company is needed, but provides no explicit guidance on when to use this tool versus alternatives like get_treasury_companies or parse_latest_filing. It mentions the required 'ticker' parameter, which gives some context, but lacks when-not scenarios or named alternatives.

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