live_quote

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

With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool requires specific API credentials, falls back gracefully when not configured, and provides a list of output fields only 'when configured.' It also states 'zero delay' as a performance trait. It doesn't cover edge cases like invalid symbol handling or rate limits, but the provided information is substantial and honest.

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 well-structured with sections and bullet points, front-loaded with the core purpose in the first sentence. It is longer than minimal but every paragraph contributes essential information (credentials, setup, fallback, output specifics, examples). The pricing comparison with Zerodha is arguably extraneous, but it does help justify the tool's value. Overall, it is reasonably concise for the amount of context provided.

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 that an output schema exists, the description correctly avoids duplicating return types. It covers the full lifecycle: what the tool does, prerequisites, setup steps, fallback behavior, and concrete examples. It also explains the distinction from paid alternatives and lists the exact data fields provided. This is sufficient for an agent to use the tool correctly and to guide a user through setup.

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 only declares 'symbol' as a string with no description. The tool description compensates fully by defining it as an 'NSE symbol' and giving examples: 'RELIANCE, TCS, NIFTY, BANKNIFTY.' It also shows concrete usage examples ('live_quote("RELIANCE")'), which adds practical meaning far beyond the schema.

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 'Real-time NSE quote via Angel One SmartAPI — zero delay, no yfinance lag.' It specifies the exact resource (NSE quotes) and distinguishes from alternatives by emphasizing real-time data and the specific broker API. This leaves no ambiguity about what the tool does and how it differs from sibling quote tools like 'nse_quote' or 'stock_quote'.

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 provides clear context for when to use this tool: for real-time NSE quotes without delays, needing Angel One credentials, and with a graceful fallback if not configured. It mentions the paid alternative (Zerodha Kite Connect) and implies the tool is free for account holders. However, it does not explicitly name sibling tools or state when *not* to use it (e.g., if the user lacks Angel One credentials), so it falls short of a perfect 5.

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