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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: data sources (Yahoo Finance primary, BSE API, NSE API proxy-gated), async job behavior, and the requirement of AICI_RESEARCH_PROXY_URL for full access. This goes beyond the annotations and helps set expectations without contradicting them.

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 long but well-organized with bullet points and clear sections for modes and input formats. Every sentence carries useful information, and the structure makes it scannable. It is somewhat dense, but the complexity of a tool with four modes justifies the length, and no redundancy is present.

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 complex tool with multiple modes, input formats, async behavior, and external dependencies, the description is remarkably complete. It covers all key aspects: what each mode returns, accepted query formats, supported sectors, proxy/ENV prerequisites, and source fallbacks. The presence of an output schema means return-value details are handled elsewhere, so the description fully satisfies the contextual burden.

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?

Despite 100% schema coverage, the description significantly enriches parameter meaning. It elaborates each mode's returned fields (e.g., company includes CIN, directors, status), lists supported sector keys for sector_overview, and gives concrete input format examples (e.g., 'RELIANCE', '500325', 'L17110MH1973PLC019786'). This transforms the schema's bare enum and string descriptions into actionable guidance.

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 provides 'Indian capital market intelligence' and enumerates four distinct modes (company, market_quote, sector_overview, mca_filing) with specific data fields for each. This distinguishes it from sibling tools like china_market_data or generic market research tools by naming the exact exchanges (NSE, BSE) and MCA registry coverage.

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?

Usage is implied through detailed mode descriptions and input formats, including the note that mca_filing requires a CIN. The async parameter is explicitly explained ('Use for slow tools to avoid client timeouts') and the ENV requirement for NSE direct API/MCA is stated. However, it does not explicitly name alternative sibling tools or provide when-not-to-use scenarios, so it stops short of a perfect guideline score.

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