equity.diagnosticGet the platform's cached or refreshed multi-source equity diagnostic. It returns findings, watch items, coverage, and cited evidence without reimplementing any metric.
| Name | Required | Description | Default |
|---|---|---|---|
| mode | No | cache-first | |
| limit | No | ||
| symbol | Yes | Market symbol, for example NVDA, BRK.B, or BTC/USD | |
| exchange | No | Optional exchange or MIC code used to disambiguate the symbol |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so safety is covered. The description adds useful context about the return payload (findings, watch items, coverage, cited evidence) and the cache-first vs. refresh behavior, which goes beyond the annotations. No contradiction.
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 a single, well-structured sentence that front-loads the core purpose and lists the key outputs. Every phrase earns its place; there is no redundant information.
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 read-only diagnostic tool with no output schema, the description adequately communicates the type of data returned and the caching behavior. It does not explain the exact structure of findings or coverage, but given the tool's simple parameter set and annotations covering safety, the description is reasonably complete. Minor gaps exist around the meaning of 'coverage' and how the mode parameter affects freshness.
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 provides descriptions for only the symbol parameter (50% coverage). The description mentions 'cached or refreshed' which implicitly maps to the mode parameter but does not explicitly explain it. The limit and exchange parameters remain undocumented in both the schema and description, leaving the agent to infer their purpose. Since the description adds some context for mode but not others, a 3 is appropriate.
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 the tool retrieves a cached or refreshed multi-source equity diagnostic and lists the returned content (findings, watch items, coverage, cited evidence). It implies a comprehensive diagnostic distinct from sibling tools like market.quotes or company.profile, though it does not explicitly name an alternative.
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 guidance is provided on when to use this tool versus siblings like market.quotes, company.profile, or company.financials. The description only mentions the caching mode but does not explain under what circumstances a user should choose this diagnostic over other market data tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.