finstack-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 and succeeds in detailing the output format as a 'comparison table' containing specific financial metrics. It transparently lists the exact data points returned (price, P/E, P/B, ROE, etc.), allowing the agent to anticipate the response structure. However, it omits operational details such as whether data is real-time or delayed, rate limits, or authentication requirements.

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 employs a clear hierarchical structure with distinct sections for purpose, arguments, and examples, ensuring the primary function is front-loaded in the first sentence. The metrics list, while lengthy, is necessary to specify the tool's scope. The three examples, though slightly repetitive, effectively illustrate different markets and sectors, justifying their inclusion without excessive verbosity.

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 input and the existence of an output schema, the description provides comprehensive coverage by documenting the parameter constraints (2-5 stocks) and preemptively listing the returned financial metrics. It addresses the 0% schema coverage gap through detailed argument descriptions. The inclusion of specific metrics and formatting details ensures the agent has sufficient context for invocation.

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%, but the description fully compensates through an explicit 'Args' section that defines the 'symbols' parameter as 'Comma-separated stock symbols (2-5 stocks)'. It provides clear formatting guidance and multiple concrete examples (RELIANCE,TCS,INFY and AAPL,MSFT,GOOGL) that clarify the expected input syntax. This effectively bridges the gap left by the undocumented schema field.

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 opens with the specific action 'Compare' and resource 'stocks,' immediately clarifying intent. It distinguishes itself from single-stock siblings like 'stock_quote' by specifying the '2-5 stocks' scope and 'side by side' comparison format. The enumerated list of financial metrics (P/E, ROE, etc.) further differentiates it from general profile tools.

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 description provides concrete examples of usage scenarios (comparing Indian IT giants, US tech stocks, and banks), it lacks explicit guidance on when to select this tool over single-stock alternatives like 'stock_quote' or screening tools like 'stock_screener'. The constraint '2-5 stocks' is clearly stated, offering implicit guidance on appropriate use cases. However, no explicit 'when-not-to-use' or alternative recommendations are provided.

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