get_report_summaryThe bullet takeaways of a boothcheck narrative research report plus which sections exist. Public reports are summarized keylessly; a signed-in Founding Access account key opens the full cached library. Never a fair value, target, or rating.
| Name | Required | Description | Default |
|---|---|---|---|
| ticker | Yes | US stock ticker symbol, e.g. NVDA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavioral context: access requirements for full vs. public reports, and the explicit content boundary that no fair value, target, or rating is included. No contradiction with annotations.
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 and well-structured: two sentences cover purpose, access, and exclusions without any redundant information. Every word 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 the tool's simplicity (one parameter, no output schema, safe read-only behavior), the description covers purpose, access, and content boundaries sufficiently. It implies a return structure ('bullet takeaways' and 'which sections exist') that is clear enough for an agent to use it correctly.
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 coverage is 100% and the only parameter (ticker) has a clear description. The tool description does not add extra parameter-level detail beyond stating the report context, so the baseline of 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 returns bullet takeaways of a boothcheck narrative research report and lists which sections exist. It also explicitly says it never provides fair value, target, or rating, distinguishing it from sibling tools like whats_priced_in or most_stretched.
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 for retrieving report summaries and clarifies access conditions (keyless for public reports, Founding Access key for the full library). It also states what the tool does not provide ('Never a fair value, target, or rating'), serving as an exclusion, though it does not name alternative tools explicitly.
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.
Each tool targets a distinct purpose: single-stock inversion, pairwise comparison, market-wide ranking, coverage inventory, and report summaries. No two tools could be confused for the same function.
Three tools use a verb_noun pattern (compare_priced_in, get_report_summary, list_coverage), but most_stretched is an adjective and whats_priced_in is a question phrase. This mix of styles makes the naming pattern inconsistent, though all are lowercase and underscore-separated.
With exactly 5 tools, the set is well-scoped for a niche financial analysis service. Each tool earns its place and there is no unnecessary duplication.
The tool set covers the core workflows: discovering coverage, analyzing a single ticker, comparing two, screening for the most stretched, and accessing report summaries. Any missing functionality (e.g., full report text) is a content restriction, not a tool-surface gap.