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

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint. The description adds value beyond those by specifying what the audit looks for and that it returns 'an overall verdict'. No contradictions 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 two sentences with no filler. The audit scope is front-loaded, and the usage trigger is stated in the second sentence. Every phrase 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 full schema coverage, rich annotations, and a moderate complexity tool, the description sufficiently explains what the tool checks and when to use it. It does not detail the exact return structure beyond 'overall verdict', but this is a minor gap for a read-only audit tool without an output schema.

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%, so parameter meanings for start, end, period, and symbol are already fully documented. The description adds little beyond implying that the audited asset corresponds to the 'symbol' parameter, so a baseline 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 opens with a specific verb ('Audit') and a specific resource ('an asset's price history'), then enumerates concrete checks: missing closes, zero-volume bars, gaps, suspicious one-session moves, and stale bars. This clearly differentiates it from sibling tools like get_price_summary or compare_assets.

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 explicitly states when to use the tool: 'when a result looks surprising or before a long-period analysis' and 'before trusting figures built on it'. It does not name specific alternatives or exclusions, but the usage context is clear enough to guide an agent.

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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds a valuable behavioral boundary: 'Settings are shown as present or absent, never their values.' This tells the agent it will not receive sensitive configuration values, which meaningfully shapes expectations. It also implies a status-report style output without exposing internals.

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 exactly two sentences with no fluff. The first sentence states the core functionality and scope; the second explains the output behavior and when to invoke the tool. Every clause carries information useful to an agent, and the most important action verb 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?

For a zero-parameter diagnostic tool with no output schema, the description is complete: it states what is reported, which categories are covered, how settings are represented (present/absent), and when to call it. There is no return-format expectation to document beyond the stated behavior. The tool's role among siblings is clear, so an agent can 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?

The tool has zero parameters and the input schema is empty, so the description cannot add parameter-level meaning. The baseline for zero parameters is 4, and the description appropriately focuses on what the tool reports rather than inputs. Nothing is missing here.

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 and resource: 'Report which data sources this server will use and which settings are missing.' It enumerates the covered data categories (price data, financial statements, inflation, news), making the tool's scope unmistakable. The tool is clearly a setup/diagnostics tool, distinct from the data-retrieval siblings.

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 when-to-use guidance: 'Call it when a tool says a source is not configured, or before a first report.' This gives clear trigger conditions for an agent. It does not explicitly name alternatives or when-not-to-use conditions, but the context of sibling tools makes the distinction implicit, so it earns a 4 rather than 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?

Annotations already provide readOnlyHint, idempotentHint, and openWorldHint. Beyond that, the description discloses output behavior: returns are nominal and in each asset's own currency, mixed currencies are flagged, and ratios are fractions (0.12 means 12%). It also specifies a shared date window, adding valuable context not present in 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 three focused sentences: the first states the action and metrics, the second gives usage guidance, and the third clarifies output formatting. Every sentence earns its place, and the core purpose is front-loaded. No redundant or filler text.

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 there is no output schema, the description explains the return values (returns, volatility, max drawdown per asset) and formatting details (fractions, currency flagging). It covers the key aspects needed to call and interpret the tool, though the exact response structure is not fully specified, which would require inference by the agent.

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 has 100% description coverage, so the baseline is 3. The description mostly mirrors the schema's constraints (2-10 symbols, date window) and does not add per-parameter meaning beyond the schema's own descriptions. It provides no additional details for start, end, or period beyond the schema.

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 and resource: 'Put 2 to 10 assets side by side' and enumerates the metrics returned (total and annualized return, volatility, maximum drawdown). It explicitly notes returns are nominal, which differentiates it from the sibling compare_real_return, and clarifies it compares multiple assets or an asset against an index, setting it apart from single-asset 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?

The description gives a clear usage context: 'Use it to compare assets or an asset against an index.' It also conveys important usage nuances about mixed currencies and fraction formatting. However, it does not explicitly name alternatives or state when not to use the tool, such as for real (inflation-adjusted) returns.

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?

Annotations already declare the operation safe (readOnly, idempotent, openWorld), and the description adds genuinely useful behavioral details beyond that: it works without API keys, it reports how far the inflation series reaches if it ends early, and it clarifies that ratios are fractions. 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 compact and front-loaded with the core question, followed by a useful usage directive, a data-completeness caveat, and a formatting note. It is slightly dense in the first sentence's list of outputs, but 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?

With no output schema, the description compensates by enumerating the returned metrics and explaining ratio conventions and truncated inflation data. Parameter details are covered by the schema, and safety is covered by annotations, leaving no critical calling requirement missing.

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%, so the schema fully documents all five parameters. The description adds the ratio-format caveat and general context like high-inflation currencies, but does not add parameter-specific meaning beyond what the schema provides, matching the baseline of 3.

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 concrete question the tool answers ('did this asset beat inflation?') and enumerates its specific outputs: nominal return, cumulative CPI inflation, real return, annualized real return, and the same holding valued in USD and gold. This clearly distinguishes it from sibling tools like compare_assets and portfolio_real_return by its unique real-return/inflation focus.

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 explicitly states when to use the tool: 'Use it for any question about real, inflation-adjusted or purchasing-power returns, especially for high-inflation currencies.' It does not name alternatives or give exclusion criteria, so it stops short of the strongest possible routing guidance, but the context is clear.

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?

Annotations already provide readOnlyHint, openWorldHint, and idempotentHint, lowering the burden. The description adds meaningful behavioral context beyond annotations: it clarifies that results are measurements, not causal proof, and that ratios are expressed as fractions (0.12 means 12%). This helps the agent 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?

The description is front-loaded with the core action and output, then a usage cue, then a critical interpretation caveat and unit convention. Every sentence earns its place, and there is no repetitive or filler content despite covering a fairly rich tool.

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 there is no output schema, the description does a good job enumerating the computed values and their units, so an agent knows what to expect. It also clarifies the non-causal interpretation. Minor gaps like handling of missing sessions or non-trading event dates are not addressed, but the core calling context is complete.

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%, so the schema already documents all four parameters and their meanings. The description reinforces the default windows (1st, 5th, 20th session) and the benchmark concept, but it does not add parameter-specific semantics that are not already present in the input schema.

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 and resource: 'Measure how an asset's price moved after a dated event.' It enumerates the exact outputs (returns at 1st/5th/20th session, benchmark return, excess, drift), which clearly differentiates it from siblings like get_price_summary and compare_assets.

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 explicitly says 'Use it for "how did the market react to X" questions,' giving clear context for when to invoke it. It also adds a useful exclusion by stating it measures but does not prove causation Temp, though it does not name alternative tools or when-not conditions explicitly.

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?

Beyond the readOnly/idempotent annotations, the description discloses source provenance (SEC vs unofficial), the need to verify material figures in KAP filings, and its behavior of flagging missing/non-reconciling quarters and implausible jumps. It also clarifies that ratios are fractions, which prevents misinterpretation.

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 dense but every clause carries information: metrics, time horizons, inflation handling, data-quality behavior, source caveats, and units. It is front-loaded with the core purpose and keeps the caveats at the end, with no 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?

With no output schema, the description compensates by enumerating the returned figures (up to eight quarters, four years, as-reported and real), growth comparisons, and quality flags. It also gives market-specific verification guidance, so an agent knows what to expect and how to trust the data.

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 sole parameter symbol is fully described in the input schema as 'A symbol returned by search_assets,' so schema coverage is 100%. The description does not add further syntax or formatting details about the parameter, leaving the schema as the sufficient source.

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 'Summarize a company's recent financial statements,' a specific verb+resource, then enumerates exact metrics such as revenue, margins, debt-to-equity, and growth rates. This clearly distinguishes it from siblings like get_price_summary and compare_real_return, which target price and return data rather than statement-level financials.

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 text makes its context clear—financial-statement summarization with inflation adjustment and data-quality flags—so an agent can infer when it is relevant. However, it never explicitly states when to prefer it over sibling tools or when not to use it, and it names no alternatives.

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?

Beyond the readOnly/idempotent/openWorld annotations, the description discloses meaningful behavior: only the last ~90 days, newest-first ordering, syndicated duplicates merged, and a strong caveat that these are listings, not verified facts. This materially helps an agent use the results safely.

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?

Every sentence earns its place: definition and output format, use case, time coverage, and trust/citation caveat. It is compact, front-loaded, and free of 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?

With no output schema, the description compensates by listing the returned fields, ordering, deduplication, time range, and reliability caveats. The parameter semantics are fully covered by the input schema, so nothing essential is missing for an agent to call this tool 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%, so the schema already documents query, days, limit, and language. The description adds no parameter-specific detail beyond what the schema provides, such as language options or limits, so the baseline score 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 opens with a specific verb and resource: 'List recent news articles about a company or topic,' and immediately lists the output fields, ordering, and deduplication behavior. It clearly distinguishes this tool from asset/search and price tools by focusing on news listings.

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 gives explicit use cases: explaining what happened around a price move or adding context to a report. It does not mention when not to use it or compare it with sibling tools, so it lacks explicit alternatives-based routing, but the usage context is clear.

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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: results are in the asset's own currency, ratios are expressed as fractions (0.12 means 12%), and it explicitly lists the returned metrics. This gives the agent a clear picture of output semantics without contradicting 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 composed of four short, purposeful sentences. The core purpose is front-loaded, followed by usage guidance, alternatives, and a final clarifying note about ratio format. Every sentence contributes new information; there is no fluff or redundancy. It is well-structured for quick scanning.

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 read-only tool with no output schema, the description explains what the user will get: total and annualized return, annualized volatility, max drawdown with dates, and data coverage. It also specifies currency and ratio format, so an agent knows exactly what response to expect. Combined with the explicit usage guidance and alternatives, nothing essential is missing.

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% — every parameter has a clear description, including the period's behavior ('Lookback ending at `end`. Ignored when `start` is given.'). The tool description does not add extra meaning beyond the schema; it restates 'over a period' but does not clarify syntax or relationships beyond what schema already provides. With full 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 opens with a specific verb and resource: 'Measure one asset's performance over a period' and then enumerates exact metrics (total/annualized return, volatility, max drawdown with dates, data coverage). It explicitly distinguishes itself from siblings by naming compare_real_return for inflation/US-dollar/gold terms and compare_assets for multiple assets, so an agent can immediately tell which tool fits.

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 gives an explicit when-to-use rule: "Use it for 'how did X do' questions." It also names two alternatives and the conditions that select them (inflation/US-dollar/gold → compare_real_return; several assets → compare_assets). This is direct, actionable guidance with no ambiguity.

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?

Annotations already mark the tool as read-only, idempotent, and open-world, and the description adds meaningful behavioral detail without contradicting them: it computes as of today, restates payments in today's purchasing power, replays the same payments into alternatives, excludes sales and dividends, and clarifies that ratios are fractions. This goes well beyond the 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 compact and front-loaded with the core outputs, followed by the use case, limitations, and a critical unit clarification. Every sentence earns its place, with no redundant phrases 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 tool with no output schema, the description covers outputs, alternatives, the inflation question, limitations, and ratio interpretation. It could also mention how current prices are obtained or edge cases like missing data, but the essential information needed to call and interpret the tool is present.

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%, so the schema alone documents purchases, currency, compare_with, and inflation_region. The description reinforces that purchases are dated and that alternatives include USD, gold, or an index, but it does not add significant meaning beyond the schema. Baseline 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 uses a specific verb ('Evaluate') and resource ('a set of dated purchases') and enumerates concrete outputs: total paid, current value, return, annualized money-weighted return, and real return. It clearly conveys its inflation-comparison purpose, though it does not explicitly distinguish itself from the similarly named sibling compare_real_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 gives an explicit use case ('did my savings keep up with inflation') and states a clear exclusion: 'Purchases only; sales and cash dividends are not modelled.' It provides context for when to use the tool, but it does not mention alternatives or when another sibling such as compare_assets would be preferable.

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?

Annotations already declare readOnlyHint, openWorldHint, and idempotentHint, so the bar for disclosure is lower. The description adds useful behavioral context: what the search returns (canonical symbols, asset class, exchange) and what it explicitly does not return (prices). This goes beyond the annotations without contradicting them.

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 short sentences, each earning its place: the main purpose, the primary use case context, and the key non-return boundary. 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 two-parameter search tool with rich annotations, the description is complete. It explains what the tool returns, when to use it, and what it does not do, which is all an agent needs 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 description coverage is 100%: both `query` and `limit` are documented in the schema. The description reinforces that `query` can be a name or ticker but does not materially add new parameter-level detail beyond the schema.

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 and resource: 'Find assets by name or ticker and return their canonical symbols, asset class and exchange.' It also distinguishes this tool from siblings by noting that 'every other tool takes the symbols it returns,' making its role as a symbol lookup clear.

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 gives explicit usage guidance: 'Use this first whenever you are not certain of an exact symbol.' It also clarifies the tool's relationship to all other tools and states a negative boundary ('Does not return prices'), helping an agent decide when not to use it.

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