list_coverageThe honest inventory of what boothcheck currently solves: every US ticker with a live implied-expectations record, with the resolution level each was solved at (whole-company, segment, financials, REIT, and kin). Paginated at 100.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number, 1-based (100 tickers per page) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is known. The description adds useful behavior context: pagination at 100 and the scope (US tickers with live records). However, it does not mention ordering, error cases, or what happens on out-of-range pages, so it provides moderate value beyond 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 two concise sentences: the first establishes purpose and content, the second states pagination. No filler or repetition. Information is front-loaded and 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?
For a simple paginated list tool with one optional parameter, the description is nearly complete. It explains what items are included and the pagination behavior. The lack of an output schema is mitigated by the description's clear mention of the returned fields (ticker and resolution level). Minor omissions like total count or default page are not critical.
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 fully documents the single page parameter with type, minimum, and description (including '100 tickers per page'). The description reinforces the pagination size but adds no new information beyond what the schema already states, so the baseline 3 applies.
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 explicitly states the tool's purpose: listing every US ticker with a live implied-expectations record and its resolution level. This clearly distinguishes it from sibling tools that analyze or compare data, making it the inventory/list endpoint.
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 this tool is the authoritative source for checking what coverage exists ('honest inventory'), but it does not explicitly state when to use it over alternatives like get_report_summary or most_stretched. No exclusion conditions or when-not-to-use guidance is provided.
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.