Which analysts called this ticker, and were they right? Lists stored calls on the ticker with each call's benchmark-adjusted outcome at the given horizon. Analytics, not advice.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | ||
| horizon_days | No |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must bear the full burden of behavioral disclosure. It mentions that calls are 'stored' and outcomes are 'benchmark-adjusted,' but it omits critical details like data freshness, authentication requirements, rate limits, error handling, or what happens if the ticker is invalid. The caveat 'Analytics, not advice' adds context but insufficiently addresses behavioral expectations.
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 extremely concise, consisting of three sentences with no redundant or filler content. It front-loads the core question, states the function, and adds a clarifying disclaimer. Every sentence earns its place.
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 that an output schema exists, the description does not need to explain return values. However, with only two parameters (one required) and no annotations, the description covers the main concept but lacks detailed parameter semantics, usage boundaries, and behavioral context. It is minimally complete for a simple tool but leaves important gaps.
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?
With 0% schema description coverage, the description should compensate by explaining both parameters clearly. It mentions 'ticker' in the first sentence and references 'given horizon' implicitly for horizon_days, but it does not explicitly describe the parameter types, constraints, or formats. For example, it does not clarify that ticker should be a symbol or that horizon_days is an integer with a default value.
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's purpose: listing stored calls on a ticker with benchmark-adjusted outcomes. It uses specific language ('lists', 'stored calls') and distinguishes itself from analytical tools by noting 'Analytics, not advice.' The question format immediately conveys the value proposition.
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 implies usage context: when you want to see if analysts were right on a ticker. However, it does not explicitly state when to use this tool versus its siblings (e.g., analyst_recent_calls, analyst_track_record) or provide exclusion criteria. The guidance is clear but not specific about alternatives.
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.
Most tools have clearly distinct purposes (e.g., analyst_views fetches views, analyst_debate compares them, analyst_track_record scores accuracy). Some overlap exists between sentiment tools (stocktwits_symbol, ticker_social_sentiment) but descriptions clarify boundaries. Overall, an agent can differentiate them.
Naming is mostly lowercase with underscores, but conventions vary: some use prefixes (analyst_, direction_review_), some are single words (quote, leaderboard), and others are verb_noun (score_ticker, screen_stocks). This inconsistency makes patterns less predictable, though prefixes help group related tools.
With 24 tools, the server is slightly above the ideal range of 3-15 for coherence. While each tool seems justified for the financial analysis domain, the volume could be overwhelming. Some tools (e.g., tweet_store_stats, direction_review_batch) are operator-only, reducing the surface for typical agents.
The tool set covers core workflows: fetching analyst views, tracking accuracy, SEC fundamentals, insider activity, material events, live quotes, social sentiment, and screening. Gaps like earnings calendar or portfolio management are minor given the focus on analyst-driven analysis. The operator tools for direction review add internal completeness.