MeritValue

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are present, so the description carries the burden. It adds useful context about the output (year-by-year series plus averages) and interpretative framing (signals, not verdicts). However, it does not disclose computational specifics, limitations, or potential errors, leaving some gaps typical for tools without 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?

Three sentences, all purposeful: the question introduces purpose, the second states outputs, and the third provides a crucial interpretative caveat. No wasted words, and the structure is front-loaded and effective.

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 and the existence of an output schema, the description is quite complete. It conveys what the result contains and how to present it. It doesn't mention edge cases or invalid input, but these are less critical for a one-parameter analytical tool.

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 fully covers the single 'ticker' parameter with a clear description. The tool description adds no additional parameter-specific meaning, so the baseline of 3 is appropriate per the high schema coverage.

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 function: assessing business quality via return on invested capital/equity versus cost of capital and share count changes. It distinguishes itself from sibling valuation or fundamentals tools by focusing on moat and management signals.

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 opening question 'Is this a good business?' implies when to use the tool, and the caveat 'These are signals, not verdicts—present them that way' provides usage context. However, it does not explicitly mention alternatives or when not to use, so it falls short of a 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It transparently states that MeritValue holds no market-data license, so it never returns live quotes, and that the price must be user-supplied. It also warns against guessing, adding practical behavioral context beyond a simple function description.

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 three sentences, each earning its place: the first states the core function, the second explains why a live quote is unavailable, and the third gives actionable guidance on sourcing the price. No fluff or redundancy, and the key limitation is front-loaded.

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) and the presence of an output schema, the description is complete. It explains the purpose, the key limitation, and the correct input sourcing. The mention of 'base case' is enough context given sibling tools like get_thesis, and the output schema covers return values.

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 already describes both parameters (ticker and price) with 100% coverage. The description adds no new semantic detail about the parameters themselves—it only instructs how to obtain the price, which is usage guidance rather than parameter meaning. With high schema coverage, 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's function: 'the annual return the base case implies' given a supplied price. It distinguishes itself from siblings by emphasizing the caller must supply the price, which is unique among the listed tools. The verb 'returns' and resource 'expected return' are specific and unambiguous.

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 clear context on how to use the tool: the caller must provide a price, and the agent should ask the user or have them check a broker, not guess. It doesn't explicitly name alternatives or exclusions, but the guidance on not guessing and not presenting guessed prices is actionable and context-rich, fitting the 'clear context, no exclusions' level.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the transparency burden. It discloses that data is normalized, includes provenance, and notes that foreign filers report in home currency. This goes beyond minimal disclosure, though it stops short of detailing any operational constraints like rate limits or data freshness.

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-loading the core content (what is returned and provenance) and then adding usage guidance and a currency caveat. Every phrase earns its place, with no redundancy or filler.

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 one-parameter tool with an output schema, the description fully covers what the tool does, when to use it, and a critical caveat (foreign currency). It is complete enough for an agent to select and invoke the tool correctly without needing more details.

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 has only one parameter (ticker) with a full description including case-insensitivity. Schema coverage is 100%, so the baseline is 3. The description does not add additional parameter-level detail beyond what the schema already provides.

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 normalized fundamentals per fiscal year, listing specific metrics (revenue, earnings, cash flow, capex, debt, shares) and provenance elements (CIK, accession number, XBRL tag). This distinguishes it from sibling tools that provide analysis outputs like business quality or intrinsic value.

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?

Explicitly says 'Use when the user wants the underlying numbers or asks where a figure came from', providing clear context for when to choose this tool. It does not mention when not to use it or name specific alternative tools, but the purpose differentiates it well from siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It explicitly discloses a non-obvious behavior: models can refuse to value, and refusals are meaningful results, not gaps. It also instructs the agent not to substitute numbers, preventing misinterpretation. This goes beyond a minimal description, though it does not cover other potential behaviors like rate limits or error handling.

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 with no redundant words. The first sentence front-loads the core purpose and model list; the second adds a critical caveat. 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 the tool's complexity (multiple models, refusal behavior) and the presence of an output schema (which covers return values), the description adequately explains the key aspects: what models are included, what a fair-value range is, and how to handle refusals. It is slightly generic on why some models refuse, but this is sufficiently covered.

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 covers the only parameter (ticker) with 100% coverage, including case-insensitivity and an example. The description adds no extra meaning to the parameter, so the baseline score of 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 states a specific verb ('get') and resource ('intrinsic value across models') with a clear verb+resource structure. It enumerates the exact models (DCF, earnings-power, Graham number, P/E reversion), distinguishing it from sibling tools like get_business_quality or get_expected_return.

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 clear context: it returns valuation model verdicts and a fair-value range, making it evident when to use this tool. It does not explicitly mention alternatives or exclusions, but the refusal-handling instruction ('Never present a refused model as missing data, and never substitute...') gives important guidance on interpreting output. This is clear context without explicit when-not-to-use guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses determinism (same filings always produce same sentences), byte-identical output to meritvalue.com, and null-returning behavior when filings don't support a moat/fair value read rather than inventing one. These are critical behavioral traits an agent must know to interpret results correctly.

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?

Four sentences, each serving a distinct purpose: definition, determinism, null handling, and usage priority. The description is front-loaded with the core action and contains no fluff 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?

For a one-parameter tool with an output schema, the description covers the tool's purpose, data source, determinism, edge-case behavior, and usage guidance. The presence of an output schema makes explaining return structure unnecessary. It is complete for the tool's complexity.

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 fully documents the single 'ticker' parameter with an example and case-insensitivity. Since schema description coverage is 100%, the baseline is 3. The description adds no additional parameter semantics beyond what the schema provides.

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 computes an investment thesis from SEC filings, combining business quality and fair value. It distinguishes itself from siblings by explicitly positioning itself as the first tool to use when asking whether a company is worth owning, differentiating it from get_business_quality and get_intrinsic_value.

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 explicit usage guidance: 'Use this first when asked whether a company is worth owning.' This clearly indicates when to invoke the tool. However, it does not name alternative tools for specific subtasks or state when not to use this tool, so it falls short of full 5.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the transparency burden. It discloses a key prerequisite and the meaning of a 403 error ('plan limit and not an error to retry'), which is useful operational behavior. However, it does not explicitly state that the operation is read-only or describe any side effects, though the nature of 'ranking' implies a safe read. The provided note adds some context but not comprehensive transparency.

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 long, front-loaded with the core purpose ('Rank covered companies...') and includes a valuable error-handling caveat in the second sentence. There is no fluff or redundant information, making it appropriately concise and well-structured.

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 screening tool with only 2 optional parameters, an output schema, and no annotations, the description covers the essential context: what it does, the key requirement, and error handling. The output schema and parameter schema fill in the remaining details, so the description is complete for effective tool 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 input schema has 100% description coverage for both parameters (limit and model), including the enum values for model. The description adds no extra meaning beyond what's already in the schema—it only mentions 'chosen model' generically. Therefore, the baseline of 3 applies, as the schema does the heavy lifting and the description doesn't compensate further.

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 function: 'Rank covered companies by a chosen model's value.' It uses a specific verb ('Rank') and identifies the resource ('covered companies') and the dimension ('value'). This distinguishes it from sibling tools like get_intrinsic_value or search_companies, which fetch single-company data or search, respectively.

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: it's for ranking the covered universe by a valuation model. However, it does not explicitly state when to use this tool over alternatives (e.g., when you need a broad screen vs. a single company valuation) or mention any exclusions. The only usage-related note is about the 403 error handling, which is an operational caveat rather than a when-to-use guideline.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries full burden. It clarifies resolution behavior via example and partial-ticker support, plus coverage scope. It doesn't describe return format/sorting/failure behavior, but the output schema and simplicity of the tool soften the gap.

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 sentences, each with a job: define action, give example and when-to-use, define scope. No redundant restatement of the title or schema.

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 two-parameter resolver with an output schema, the description covers purpose, example, workflow placement, and data coverage. Nothing meaningful is missing for an agent to invoke 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 already documents both parameters at 100% coverage, so baseline is 3. The description adds beyond schema by showing fuzzy/partial matching with 'coca cola' and 'partial ticker', making query semantics clearer.

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 opens with a specific verb+resource ('Resolve a company name or partial ticker to covered companies') and a concrete example ('coca cola' finds KO). It also distinguishes this tool from siblings by positioning it as the lookup step before other tools.

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?

Explicitly states when to use ('Use this before the other tools when you have a name rather than a symbol') and adds coverage context ('US filers with SEC filings') that helps the agent decide if this is appropriate. No explicit alternative listing is needed since siblings are downstream.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.