get_evidenceThe primary documents a ticker's signals were derived from — insider Form 4s, Congressional disclosures, institutional holdings and macro series, each with the filing it came from. Use this to cite a claim rather than assert it. Paid keys only, and slower than the other tools because it is computed on demand.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | Ticker symbol, e.g. AAPL. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only provide readOnlyHint=true, so the description carries the burden for extra behavioral context. It discloses that paid keys are required, that the tool is slower because it computes on demand, and that results include the filing each document came from. This adds meaningful behavior beyond the annotation without contradicting it.
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 succinct yet informative: two sentences present the core purpose, followed by usage guidance and constraints. There is no wasted wording or repetition of schema fields, making it easy to scan.
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 tool's simplicity (one parameter, readOnly annotation, no output schema), the description provides sufficient context: what is returned, use case, auth requirement, and performance characteristic. It could go further by describing output structure in more detail, but it adequately covers the essentials.
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 already documents 'ticker' with an example (e.g., AAPL), and schema coverage is 100%. The description does not add additional parameter-level details but ties ticker to 'a ticker's signals,' which is mild context. This meets the baseline for schema-covered parameters.
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 identifies the tool as returning the primary source documents behind a ticker's signals, listing specific document types (Form 4s, congressional disclosures, institutional holdings, macro series). This distinguishes it from sibling tools like get_signal or get_consensus by emphasizing the underlying evidence, though the verb is implicit rather than explicitly stated ('retrieves').
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 gives a clear use case: 'Use this to cite a claim rather than assert it.' It also notes constraints: paid keys only and slower than other tools due to on-demand computation, implying alternatives for speed or without paid access. However, it does not explicitly name specific sibling tools to use instead.
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.
get_composite and get_consensus both return per-ticker consensus with dimension breakdowns, creating ambiguity; agents might call the wrong one. Other tools are clearly distinct, but this overlap requires extra care.
All tools follow a verb_noun pattern: get_ for single entities, list_ for collections, and rank/search/screen as action verbs. The pattern is consistent and predictable across the entire set.
15 tools is well-scoped for a market intelligence server, covering single-ticker queries, lists, discovery, and market-level signals without unnecessary bloat.
The surface covers core workflows: ticker resolution, consensus, evidence, trades, positioning, screening, and market signals. Minor gaps exist (e.g., historical consensus or direct ticker comparison), but they are not critical.