What a stock price is betting on: implied growth, duration, and margin, read from SEC filings.
Scored across 5 tools
Each tool operates on a distinct scope: single stock (whats_priced_in), a pair (compare_priced_in), a ranked list (most_stretched), coverage inventory (list_coverage), and report takeaways (get_report_summary). The three reverse-DCF tools share a common method but are clearly separated by cardinality, so boundaries are understandable though a user must read descriptions to distinguish them.
Three tools follow a verb_noun pattern (compare_priced_in, get_report_summary, list_coverage), but most_stretched and whats_priced_in break it with adjective/question-style names. The convention is mixed, though all remain snake_case and readable.
Five tools is well-scoped for a niche implied-expectations service, with each tool covering a distinct query shape (single, pair, ranking, coverage, report). No tool feels redundant or missing at this count.
The surface covers the core lifecycle of the domain: query one ticker, compare two, rank the market, discover coverage, and read report summaries. Minor gaps exist — no tool to retrieve full report sections or historical implied-expectations series — but the primary workflows are covered.
Side-by-side of what two US stock prices are each betting on: implied growth and duration (plus any held margin input) from a reverse-DCF inversion of each price. No Boothcheck house fair value or rating — a comparison of the assumptions embedded in the two prices.
| Name | Required | Description | Default |
|---|---|---|---|
| tickerA | Yes | First US ticker, e.g. AMD | |
| tickerB | Yes | Second US ticker, e.g. NVDA |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/destructive hints. The description adds transparency about the output being derived from reverse-DCF and that it is a comparison, not a recommendation. It also clarifies the scope to US stocks, which is useful beyond the schema.
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 sentences, front-loaded with the core purpose, and the second sentence adds a clarifying exclusion. Every word earns its place; no filler or redundancy.
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 (two parameters, no output schema), the description gives sufficient context about what the output represents (implied growth, duration, margin input). It could mention potential limitations or edge cases, but for this scope it is complete enough.
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% with descriptions for both tickerA and tickerB, including examples. The description's mention of 'US stock prices' reinforces the US ticker requirement but adds little beyond the schema's own parameter descriptions.
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 performs a side-by-side comparison of what two US stock prices imply about growth and duration via reverse-DCF. It explicitly distinguishes itself from sibling tools by noting it provides no house fair value or rating, making its purpose unique.
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 provides context on when to use the tool: when comparing assumptions embedded in two prices, and it explicitly excludes house fair value or rating. It does not name alternative tools, but the 'No Boothcheck house fair value or rating' line implicitly directs users away for valuation opinions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The 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.
Inventory of US tickers with an implied-expectations model record, with its resolution level (whole-company, segment, financials, REIT, and kin). Model-record coverage does not guarantee a published priced-in decomposition or completed narrative report. Paginated at 100; inventory cached for up to one hour.
| 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 cover the safety profile (readOnly, non-destructive, closed world), and the description adds real operational context beyond them: pagination at 100 items and an inventory cache of up to one hour, which affects how fresh results are. The 'coverage does not guarantee X' caveat is a useful expectation-setting trait. It stops short of describing the response shape.
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?
Three tight sentences that front-load what the inventory contains, then layer the important caveat and the operational limits. No filler, though the parenthetical 'and kin' is slightly informal and the final sentence packs two distinct facts (pagination, cache TTL) together.
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?
With no output schema, the description carries the burden of explaining the return content and does so: the entity set, the resolution-level field, and the caveat that coverage is not equivalent to a published decomposition or report. An agent can call this correctly; only the exact response fields remain unspecified.
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 description coverage is 100% and the single page parameter is fully documented in the schema. The description only restates the page size ('Paginated at 100'), adding no new syntax or constraint semantics. Baseline 3 for a schema that does the heavy lifting.
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?
States a specific resource (inventory of US tickers holding an implied-expectations model record) and its dimension of variation (resolution level: whole-company, segment, financials, REIT). It is clearly not a priced-in lookup like whats_priced_in or a comparison like compare_priced_in, though it never names those siblings explicitly.
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?
Usage is only implied: the caveat that model-record coverage does not guarantee a published decomposition or completed narrative nudges the agent to treat this as a coverage check before calling deeper tools. There is no explicit when-to-use statement, no when-not-to-use, and no named alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rank US stocks by how much growth is already baked into their price (implied operating-income growth from a reverse-DCF read of the current price). Returns the top N with the growth and duration each price assumes (plus any held margin input). Not a sell list — a ranking of where the bar to clear is highest.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many names to return (1-20, default 8) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds meaningful context by stating it is not a sell list and clarifying the output includes 'growth and duration'. This goes beyond the annotations without contradicting them, though it omits data-source or timing details.
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 sentences, front-loads the core action, and every clause earns its place. It efficiently covers purpose, method, output, and a caution without redundancy.
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 simple tool (one optional parameter, no output schema), the description fully covers sufficient context: what it does, what it returns, and what it does not do. The reverse-DCF methodology note adds depth, and the no-output-schema gap is compensated by the return-shape description.
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% for the single 'limit' parameter, so the schema already documents the range and default. The description references 'top N' but provides no additional parameter-level detail beyond what the input schema already states.
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?
Description uses a specific verb ('Rank') and identifies the resource ('US stocks') plus the metric ('growth baked into price'), clearly distinguishing it from a generic list or sell recommendation. The parenthetical definition ('implied operating-income growth from a reverse-DCF read') adds precision without ambiguity.
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 conveys clear usage context: it ranks by 'how much growth is already baked into price' and explicitly states it is 'Not a sell list', so an agent knows not to use this to get sell recommendations. However, it doesn't name sibling alternatives like compare_priced_in or whats_priced_in, so the 'when to use vs alternatives' is only partially explicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Invert a US stock's current price into the bet it implies: the operating-income growth rate, how many years it must be sustained, and (where the route holds one as an input) the terminal operating margin assumption, versus what the company has actually delivered (from SEC EDGAR filings, reverse-DCF). boothcheck does not return a Boothcheck house fair value, price target, or buy/sell rating — it shows what the price assumes so the user can judge the bet. Covers about 2,000 US tickers.
| 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 indicate read-only and non-destructive, and the description adds valuable behavioral context: reverse-DCF methodology, SEC EDGAR data source, coverage of about 2,000 US tickers, and what it intentionally does not return. No contradiction with annotations; the added context goes beyond the schema.
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 front-loaded with the core purpose, followed by exclusions and scope, all in three sentences. It is concise, though phrases like 'boothcheck' and 'where the route holds one as an input' are slightly confusing and could be cleaned up for clarity.
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 reverse-DCF tool with no output schema, the description covers key output dimensions (growth, years, terminal margin), data source, and coverage. It does not specify exact return format or behavior for uncovered tickers, but the core context is sufficiently complete for selection and invocation.
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 describes the single ticker parameter, but the description adds meaning by specifying US stocks, coverage scope (~2,000 tickers), and that the analysis is based on current price. This helps the user understand ticker validity and potential coverage limitations.
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 inverts a US stock's current price into implied operating-income growth, years sustained, and terminal margin, versus actual delivered results. This is a specific, unique purpose that distinguishes it from siblings like compare_priced_in and most_stretched, which likely focus on comparison and ranking.
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?
It provides clear context for when to use the tool: to judge the bet a price implies, and explicitly lists exclusions (no fair value, price target, or rating). However, it does not explicitly name alternative tools or state when to prefer a sibling, so it lacks full alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_strategiesget_strategiesget_report_summarylist_coveragecompare_priced_inmost_stretchedwhats_priced_inIntrinsic stock value from SEC filings: DCF, EPV, Graham, moat signals. Deterministic, not guessed.
Free US stock research from SEC filings: five plain answers on 3,000+ stocks. No API key.
Real SEC EDGAR filing metrics: margin-of-safety, EPS growth, going-concern flags.
SEC filings, company financials, holdings, earnings calls, stock prices, options and macro data.
Add one secure layer between your agents and this server.
