finstack-mcp

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

With no annotations, the description carries the full burden and performs well by disclosing the rich return payload (current price, volume, market cap, P/E, 52-week range, sector). It also notes the 'real-time' latency characteristic. Minor deduction for lacking error handling behavior (e.g., invalid symbol response) or rate limit context.

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?

Excellent structure with clear sections: purpose declaration, return value summary, Args documentation, and usage examples. Every sentence adds value. The front-loaded action statement 'Get real-time NSE...' immediately clarifies intent.

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 single-parameter simplicity and presence of an output schema, the description is complete. It appropriately previews the return contents without needing to detail the full output schema structure. The Indian market context (NSE) is clearly established.

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 description coverage is 0%, requiring the description to fully compensate. It successfully explains the 'symbol' parameter as an 'NSE stock symbol' and provides concrete, helpful examples (RELIANCE, TCS, INFY). Could be improved by noting formatting constraints (e.g., uppercase requirement, no exchange suffix).

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?

Description uses specific verb 'Get' with clear resource 'real-time NSE quote' and scopes it to 'Indian stock'. It distinguishes from siblings like 'bse_quote' and 'stock_quote' by explicitly naming the National Stock Exchange, and from 'nse_historical' by emphasizing 'real-time'.

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?

While the 'real-time' descriptor and NSE naming implicitly guide usage, there is no explicit guidance on when to choose this over siblings like 'bse_quote' (different exchange) or 'nse_historical' (historical vs. current data). No 'when not to use' or prerequisite information is provided.

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