call_bse_api

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

With no annotations, the description carries the full burden and does disclose the default-filling precedence: defaults come from scripcode and quarter, and anything in params overrides them. That is genuinely useful behavior. However it omits error behavior for invalid endpoints, auth requirements, rate limiting, and response size/pagination characteristics for a raw passthrough.

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?

Single paragraph, front-loaded with purpose and return format, then the necessary endpoint enumeration, then the defaulting rule. The long endpoint list is bulky but is the only place that enum exists, so every token 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?

The description states the return type (raw decoded JSON), which substitutes for the missing output schema, and covers the parameter-defaulting model. For a generic gateway spanning 23 endpoints with no schema descriptions, no annotations, and no per-endpoint parameter documentation, an agent still lacks error handling and per-endpoint argument guidance.

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 compensate, and it largely does: it supplies the full enum of endpoint values (absent from the schema), documents the quarter format ('130.00' or 'Q1 FY27'), and explains how scripcode/quarter feed defaults while params overrides them. It stops short of describing per-endpoint params shapes, but the override rule is unambiguous.

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+resource ('Call any documented BSE endpoint and return its raw decoded JSON') and enumerates the 23 valid endpoints, which makes the scope concrete. It does not explicitly contrast itself with the curated siblings (get_quote, get_market_depth), so an agent must infer that this is the generic escape hatch.

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 statement of when to use this low-level passthrough versus the specialized sibling tools it overlaps with (e.g. the MarketDepth endpoint vs get_market_depth, GetQuoteAllSearchDatabeta vs get_quote). The endpoint enumeration implies usage but gives no selection rule or prerequisites.

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