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

Description discloses the output structure (counts and metric total + share per bucket) but does not mention any behavioral traits such as required permissions, rate limits, or whether the operation is read-only. With no annotations provided, the description partially compensates but lacks safety context.

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?

Two short, front-loaded sentences that efficiently convey the tool's action and output. No redundant or unnecessary information.

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 parameter count (1 optional) and existence of an output schema, the description covers the main functionality and return fields. However, it does not explain the metric parameter's role or provide context compared to sibling tools, leaving some gaps.

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 0% with no parameter descriptions. The description does not elaborate on the 'metric' parameter, its possible values, or how it affects results. This leaves agents guessing despite the parameter being optional with a default.

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 clearly states the tool buckets funds by adaptation vs mitigation categories and returns counts and metric totals. However, it does not explicitly distinguish from sibling tools like fund_type_distribution or portfolio_summary, leaving some ambiguity about when to use this specific tool.

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?

No explicit guidance on when or when not to use this tool versus alternatives like fund_summary or sector_summary. The description only implies usage for adaptation/mitigation classification without exclusions or context.

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?

No annotations provided, so description carries full burden. Discloses that source='fund' uses pre-aggregated data, source='projects' computes distinct project IDs, and filters_json narrows rows. Lists possible agg values. Lacks mention of output format or edge cases, but output schema exists. Minor gap, otherwise comprehensive.

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?

Well-structured with bullet points and clear sections. Purpose is front-loaded, then usage guidelines, then parameter details. No wasted words. Every sentence adds value.

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 complexity (two sources, filter, multiple aggregation methods) and presence of output schema, the description is complete. Covers core functionality, usage constraints, and parameter details sufficiently.

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 0% (no parameter descriptions), so description must add meaning. It does: explains source options, filters_json with example, agg values (mean/median/min/max). This adds significant value 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?

Clearly states it computes the average number of approved projects per fund grouped by fund_type. The verb 'Average' and resource 'projects per fund by type' are specific. It distinguishes from siblings like portfolio_summary and rank_by_column by stating what not to use it for.

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 'Use ONLY when the user explicitly wants an average per fund by type'. Provides clear negative examples with alternative tools (portfolio_summary for total count, rank_by_column for ranking) and explains the two source options.

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?

No annotations exist, so the description carries the burden. It mentions that metrics default to 'all four stages + projects approved', giving some behavioral insight. However, it does not disclose read-only nature, side effects, or any limits, leaving some transparency gaps.

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 that front-load the purpose, explain parameters, and provide a key usage rule. Every sentence is essential and there is no 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 presence of an output schema and the tool's moderate complexity (2 parameters), the description covers the essential inputs and workflow. It does not explain output structure, but that is supplemented by the output schema, making it sufficiently 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 coverage is 0%, so the description must compensate. It explains 'fund_ids' as a list of integer IDs and instructs how to obtain them. For 'metrics', it notes the default and that it specifies columns, adding meaning beyond the schema's bare type definition.

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 verb 'comparison' and the resource 'multiple funds' with specificity on 'across selected metrics'. It distinguishes from sibling tools like fund_summary, which likely focuses on a single fund.

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?

Provides explicit guidance on obtaining fund IDs from search_funds and warns against guessing or hard-coding. It implies when to use this tool (for comparison) versus individual fund details, though it does not explicitly exclude other use cases.

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?

No annotations are provided, so the description carries the full burden. It describes the output but does not disclose that the operation is read-only, nor does it clarify behavior when both parameters are provided or error conditions. The existence of an output schema partially mitigates 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?

The description is extremely concise (three sentences), front-loaded with the main purpose, and every sentence adds value—no filler or repetition.

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 has two optional parameters, no required ones, and an output schema, the description adequately covers the input options and output summary. Missing details like error handling are minor given the simplicity, and the output schema fills in return structure.

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 0%, but the description adds examples ('e.g. 'fund.csv'' and 'e.g. 'cfu://funds'') and implies the parameters are alternatives. However, it does not explain when to use one over the other or the exact format expected beyond the examples.

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 specific nouns ('Row count, column names, dtypes, and null counts') and implies the verb 'describe'. It clearly distinguishes the resource (dataset) and output, setting it apart from siblings like 'preview_dataset' (shows rows) and 'list_datasets' (lists names).

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 'Use when column names are uncertain; skip as a first step if... already lists the columns you need.' This provides clear when-to and when-not-to guidance, though it does not name specific alternative tools.

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?

No annotations are provided, so the description carries full burden. It discloses sorting behavior (ascending worst first), default/max values for top_k, response trimming to avoid context overflow, and the presence of 'total_funds_below_threshold' to check truncation. This is comprehensive for a filter tool.

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 moderately concise; every sentence adds meaningful information. It is structured logically (purpose, parameters, usage tip, response details). Could be slightly more terse, but it's not wasteful.

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 (5 params, output schema exists), the description covers the main behaviors, parameter constraints, and response characteristics. It feels complete for an agent to use correctly without additional documentation.

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 0%, so the description must add value. It explains ratio_metric options, top_k default and max, and mentions response columns. However, filename and fund_col are not described, leaving some parameters unexplained. Still, the key parameters are well-defined.

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 funds where a ratio metric falls below a threshold, sorted by ratio ascending. It uses a specific verb ('returns') and identifies the resource ('funds'). The tool is distinct from siblings like 'search_funds' or 'fund_summary' by focusing on ratio-based filtering.

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 a clear use case: 'Use for screening underperformers' and gives an example query. However, it does not explicitly state when not to use the tool or name alternatives, so it stops just 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. It reveals the write action and memory clearing, but does not disclose side effects like multiple call behavior or synchronous write. Adequate but could be more explicit.

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 main action. Every sentence adds value with no 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, the description covers purpose and usage timing. It does not detail return values, but an output schema exists. The 'clear memory' phrase could be clarified, but overall sufficient.

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 0%, so the description must compensate. It explains the 'extra_notes' parameter as optional free-text, adding meaning. However, the 'query' parameter is not described, leaving a gap.

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 writes a full run log to a specific file path and clears memory, using a specific verb and resource. This distinguishes it from siblings like 'start_run' and 'get_audit_trail'.

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 instructs to call this once at the end of each user query to persist the audit trail, providing clear context. It does not mention exclusions or alternatives, but the sibling set implies this is the finalization step.

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?

No annotations provided, so description carries full burden. It discloses that response includes match_method, confidence, fuzzy_candidates, and match_warning, and instructs to relay these to the user. Explains fuzzy matching behavior and warning when similarity is low.

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?

Description is well-structured with bullet points and clear sections. It is somewhat verbose but every sentence adds value. Front-loaded with core purpose.

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 4 parameters, no schema descriptions, but output schema exists, the description covers tool behavior well. Explains output fields and usage patterns without needing to replicate return value 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?

Schema coverage is 0%, so description should compensate. It mentions fund_name is key and mentions fuzzy matching, but does not explicitly describe filename, fund_col, or use_fuzzy_match parameters. Partial compensation leaves significant gaps.

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 conversion ratios between funding stages for a single named fund. It uses specific verbs like 'For a single named fund: conversion ratios' and distinguishes from siblings like portfolio_summary and fund_stage_totals.

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 (user asks about full funding pipeline, conversion ratios, efficiency, comparing ratios) and when not to use (portfolio-wide totals, raw stage amounts). Names alternatives: portfolio_summary, fund_stage_totals, fund_summary. Also advises to use search_funds first if unknown.

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?

No annotations are provided, but the description discloses key behavioral traits: top_k parameter behavior in portfolio mode (default 20, max 30) and that the response includes total_funds and showing_top. It implies read-only query behavior. Could be improved by explicitly stating the tool does not modify data.

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 well-structured: begins with core purpose, then usage guidelines, exclusions, and parameter details. It is not overly verbose, though the 'More direct than...' sentence is slightly extraneous. Every sentence contributes value.

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 complexity (4 parameters, portfolio vs. single fund modes) and the presence of an output schema, the description covers main usage scenarios and parameter nuances adequately. It provides enough information for an agent to select and invoke 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 0%, so the description carries the burden. It explains top_k defaults and max, and that fund_name=None indicates portfolio mode. However, it does not explain filename or fund_col parameters, though they have reasonable defaults. Overall adds significant meaning 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 clearly states the tool computes dollar gaps between consecutive funding stages (pledge→deposit, deposit→approval, approval→disbursement) for a single fund or the whole portfolio. It includes specific verb+resource and distinguishes from sibling tools like portfolio_summary and fund_stage_totals.

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 examples (e.g., 'how much pledged money has not been deposited') and when-not-to-use (e.g., 'Do NOT use for a global approved-vs-disbursed question with no fund named — use portfolio_summary'). It also notes this tool is more direct than manually subtracting fund_stage_totals.

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?

The description indicates it returns raw totals and no ratios, implying read-only behavior. With no annotations, it carries full burden and does so adequately, though it could explicitly state idempotency.

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 well-structured with clear sections, but could be slightly more concise by removing redundant phrases. Minor waste but overall efficient.

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?

Output schema exists, so return values need no description. The description covers purpose, usage, parameters, and exclusions comprehensively, making it complete for a 3-parameter 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?

Despite 0% schema description coverage, the description fully explains each parameter: scope values ('portfolio', 'fund', 'fund_type', 'sector'), fund_id requirement when scope='fund', and value filtering by fund_type or fund_focus_sector.

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 it provides 'raw dollar totals at each pipeline stage for a scope' and explicitly excludes ratios, distinguishing it from sibling tools like fund_conversion_ratios and fund_summary.

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 explicit guidance on when to use (total amounts by fund type/sector), when not to use (conversion ratios, portfolio-wide overview), and directs to specific alternatives (fund_conversion_ratios, fund_summary, portfolio_summary, search_funds).

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?

No annotations are provided, and the description only covers output contents. It does not disclose whether the tool is read-only, requires specific permissions, has rate limits, or any side effects. The behavioral traits are not addressed beyond what can be inferred.

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 extraneous information. It front-loads the core purpose in the first sentence and adds context in the second. Every part contributes to understanding.

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 existence of an output schema (not shown), the description need not detail return structure, but it lists key components. It lacks prerequisites, error conditions, or examples. For a simple one-parameter tool with a composite output, the description is nearly 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 0%, and the description only implies that 'fund_id' identifies the fund. It does not explain the parameter's format, range, or any constraints beyond the schema's 'integer' type. The description compensates only minimally for the lack of parameter documentation.

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 produces a 'structured profile card' including metadata, four stage metrics, portfolio share, and conversion ratios. It explicitly distinguishes itself from siblings by noting it combines two separate functions (B's fund_summary and A's fund_conversion_ratios).

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 its use when both fund summary and conversion ratios are needed together, but it does not explicitly state when to use this versus alternatives like 'get_fund_details' or 'fund_conversion_ratios'. No when-not or exclusion criteria are provided.

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?

The description implies a read-only aggregation by focusing on totals and percentages. It mentions sorting descending and default/max for top_n. No annotations are provided, but the description adequately conveys non-destructive behavior.

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 with three sentences: the first states the purpose, the second explains 'metric', the third explains 'top_n'. No wasted words; all information is front-loaded and useful.

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 output schema exists (so return values are covered), the description fully covers the tool's purpose and parameters. It is complete for a simple aggregation tool with no nested objects or complex behavior.

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?

With 0% schema coverage, the description fully defines parameters: 'metric' selects the stage column (implicitly listing pledge/deposit/approval/disbursement) and 'top_n' limits results (default 20, max 200). This adds essential meaning 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 clearly states it returns 'Totals and percentage share by fund_type, sorted descending.' It specifies the verb (totals and percentage share), the resource (fund_type), and the sorting, distinguishing it from siblings like fund_summary or portfolio_summary.

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 explains that 'metric' selects the stage column and 'top_n' limits results, providing clear context for use. It does not explicitly mention alternatives or when not to use, but the guidance is sufficient given the tool's straightforward purpose.

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?

No annotations provided, so description carries full burden. It discloses the tool returns a compact audit trail, but does not elaborate on side effects (e.g., read-only nature), performance implications, or format. 'Compact' hints at limited data, but more detail would improve 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?

Two sentences with no wasted words. Front-loaded with main purpose and a clear usage instruction. 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 zero parameters and an output schema present, the description adequately explains what the tool does and when to use it. It could mention that it only shows the current run, but that is implied. Sufficient for a simple inspection 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 tool has zero parameters and schema coverage is 100% (vacuous). Per guidelines, baseline is 4 for 0 parameters. Description adds no parameter info, but none is needed.

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 clearly states the tool returns the compact audit trail for the current run, listing tools called and dataset/columns used. It is a specific verb+resource and distinguishes from sibling tools which focus on summaries, fund details, or reporting.

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 'Call at any point mid-run to inspect what has been executed so far', providing clear when-to-use guidance. No explicit alternatives or when-not-to-use, but context implies it is for runtime inspection, and siblings cover different use cases.

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?

No annotations are provided, so the description must carry the burden. It states the tool returns a 'full dataset record,' which implies a read operation with no side effects, but does not elaborate on the exact return structure, error handling, or any constraints. The presence of an output schema partially mitigates this, but the description itself adds minimal behavioral context beyond the core purpose.

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 and immediately states the core purpose. Every sentence adds value, and there is no redundancy. It is well-structured for quick understanding.

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 low complexity (single required parameter, read-only, output schema exists), the description is adequately complete. It informs the agent about the required input, the prerequisite (need an ID), and directs to an alternative for name-based queries. It does not mention error cases or performance, but these are implicit in read operations.

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 0%, so the description must compensate. It adds semantic meaning by specifying that the fund_id parameter should be an integer identifier, not a name, and that the tool requires an ID. However, it does not provide details on the format, range, or validation of the ID, so the compensation is partial.

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 a full dataset record for a single fund by fund_id. It specifies the resource (fund) and identifier (fund_id), and distinguishes it from siblings like fund_summary and search_funds by noting that resolve_entity should be used when only the fund name is available.

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 guidance: 'Use resolve_entity first if you only have a fund name, not an ID.' This tells the agent when to avoid this tool and which alternative to use, which is excellent for decision-making.

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?

No annotations are present, so the description bears full responsibility. It discloses the output format (Markdown) and content (stage discipline, integrity rules). While it could mention that the output is large or read-only, the current description is adequate for a simple retrieval tool with no side effects.

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?

Two sentences efficiently cover purpose and usage guidelines without redundancy. The first sentence is front-loaded with the core function, and the second provides clear guidance. Every word adds value.

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 simplicity (no parameters, output schema exists), the description covers the essential: what it returns, in what format, and when to use it. It lacks an explicit note on the expected size or that it is a read operation, but these are implied. Overall, it is sufficiently complete for a tool with no inputs.

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, so the baseline is 4. The description does not need to add parameter semantics, and it correctly omits any parameter discussion. The schema coverage is 100%, leaving nothing to compensate.

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 the full schema contract as Markdown, specifying 'stage discipline, integrity rules'. It also distinguishes from sibling get_schema_contract_summary by noting it provides the complete governance text, making the purpose concrete and differentiated.

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?

Explicit guidance is given: 'Prefer get_schema_contract_summary for a compact JSON view' and 'Not intended as the first step for routine lookups — use when you need the complete governance text or summary is insufficient.' This tells the agent exactly when to choose this tool over 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?

No annotations are provided, so the description must carry the burden. It discloses that the payload is large, implying performance considerations. However, it does not explicitly state whether the operation is read-only, requires authentication, or other behavioral traits. More detail on safety or side effects would improve 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?

Three sentences, each with clear purpose: first defines what the tool returns, second gives when-to-use, third gives when-to-avoid. No wasted words, and essential information 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 zero parameters and an existing output schema, the description covers the tool's purpose, usage context, and a behavioral caveat (large payload). It is complete enough for an agent to decide when to invoke this tool appropriately.

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?

There are zero parameters, and the schema coverage is 100% (trivially). According to guidelines, no parameters yields a baseline of 4. The description does not need to add parameter information because there are none.

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 a machine-readable JSON schema contract for all datasets, specifying layers, keys, grain, and cross-layer rules. It distinguishes itself from single-table queries and implies it is a summary across datasets, differentiating it from the sibling 'get_schema_contract'.

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 when to use ('cross-dataset analysis, formal governance rules') and when to avoid ('first call for simple single-table questions when column names are already provided'). This provides clear guidance on appropriate context and 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?

No annotations are provided, so the description carries the full burden. It warns that responses can be large, which is a key behavioral trait. However, it does not disclose other potential behaviors like permissions or pagination, though for a simple list tool this may be sufficient.

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, front-loaded with purpose, each sentence adds distinct value: purpose, usage guidance, and when-to-use. No wasted words.

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 zero parameters and presence of an output schema, the description covers purpose and usage well. It could mention pagination or size implications beyond 'large', but is fairly 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?

There are no parameters (schema coverage 100%), so the baseline is 4. The description adds context about the output fields, which provides value beyond the empty 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 clearly states the tool lists registered datasets and specifies the returned fields (URI, primary key, grain, description). It also distinguishes itself from sibling analysis tools by advising when to use them instead.

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 provides when to use (unknown dataset list or need registry metadata) and when not to use (if client already documents known files, prefer analysis tools). Mentions alternatives and cautions against unnecessary calls.

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?

The description discloses key behavioral traits: values are sorted, unique, non-null, and limited to 200. No annotations are provided, so the description carries the full burden. It does not mention read-only status or performance implications, but the stated traits are adequate for basic understanding.

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: two sentences with no wasted words. The first sentence front-loads the core functionality, and the second provides the primary use case. Every sentence adds value.

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 has 4 parameters and an output schema (not shown), the description covers the purpose and use case but lacks parameter documentation. It does not explain how to specify the dataset (via dataset_uri or filename) or the role of the limit parameter. While the output schema likely describes return values, the description could be more complete for a tool with multiple undocumented parameters.

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 0% parameter description coverage. The description only implicitly explains the 'column' parameter by stating 'in a column'. The 'limit', 'filename', and 'dataset_uri' parameters are not described. Since coverage is very low, the description should compensate but does not provide meaningful details about these parameters beyond their names.

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 it returns sorted unique non-null values from a column, with a maximum of 200. This distinguishes it from sibling tools like 'list_datasets' (lists datasets) or 'describe_dataset' (describes a dataset). The verb is implied (list), and the resource is column values, making the purpose specific and 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 explicitly says to use this tool to discover valid filter values before passing them to query tools. This provides clear context for when to use it, but it does not explicitly mention when not to use it or name alternative tools. However, the sibling list includes query tools, so the guidance is mostly sufficient.

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?

No annotations are provided, so the description carries full burden for behavioral disclosure. It does not state whether the tool is read-only, whether it modifies data, or any performance or side-effect implications. This lack of transparency is a significant gap for a tool that likely scans entire tables.

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 concise with three sentences and an example. Important information is front-loaded. It is not overly verbose, though the example could be slightly more polished.

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 that an output schema exists, the description does not need to explain return values. It covers the tool's purpose, usage context, and mentions filename aliases. It is fairly complete for a reporting tool, though it could be improved with a brief note on expected output structure.

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 0%, but the description explains the roles of 'filename', 'group_by', and 'columns' through text and an example. However, the optional 'limit' parameter is not mentioned. The description adds meaning but falls short of full 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 groups rows by a column and reports missing-value counts for specified columns. It uses specific verbs and identifies the resource (dataset table). It distinguishes itself from siblings like sector_summary or fund_summary by focusing on data completeness auditing.

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 recommends using the tool 'before analysis to audit data completeness and find problematic records,' providing a clear use context. It does not mention alternatives or when not to use, but the context is adequate for typical usage.

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?

No annotations provided, so description carries full burden. It describes the tool as returning aggregated global totals with no arguments, implying read-only behavior. Could be more explicit about being non-destructive, but sufficient for a query tool.

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?

Two concise paragraphs: first states purpose, second gives usage guidance. Every sentence adds value, no fluff.

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 zero parameters and presence of output schema, description fully covers what the tool does and when to use it. No gaps.

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?

No parameters, so baseline is 4. The description adds value by detailing what the return value includes (fund count, sums, adaptation/mitigation counts), which is not in 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?

Clearly states it provides portfolio-wide totals across all funds, including fund count, sums per pipeline stage, and adaptation/mitigation fund counts. Explicitly distinguishes from sibling tools by directing single-fund queries to 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?

Provides explicit use cases (e.g., 'total pledged/approved/disbursed across ALL funds') and explicitly states when not to use it ('Do NOT use for a single fund'), with concrete alternative tool names.

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 full burden. It states the maximum rows (25) and parameter options but does not explicitly state that the tool is read-only or mention any authentication requirements. It implies non-destructive behavior through 'inspect,' which is adequate but not fully explicit.

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, consisting of two short sentences that convey all essential information. It is front-loaded with the core functionality and uses no unnecessary words.

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 that the tool has an output schema (not shown), the description does not need to explain return values. It effectively covers the purpose, parameters, and usage context. It could mention that the output is a table or data frame, but the output schema likely provides that.

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 description adds meaning beyond the schema by explaining that 'filename' or 'dataset_uri' can be used and that 'n' is for the number of rows (max 25). However, it does not specify that the two parameters are mutually exclusive or provide format examples. Given 0% schema description coverage, the description compensates partially.

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 that the tool returns the first N rows of any dataset table with a max of 25. It specifies the verb 'preview' and the resource 'dataset table'. It also distinguishes itself from sibling tools by focusing on raw data inspection, which is unique among the listed 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 explicitly says to use it 'to inspect raw data shape before analysis,' providing clear context. However, it does not mention alternative tools or when not to use it, but given the unique purpose among siblings, the lack of exclusions is acceptable.

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 takes on the full burden of behavioral disclosure. It details filter behavior (OR logic, substring fallback, error handling), top_k limits (default 20, max 100), and response contents (total_groups_found). It could explicitly state the tool is read-only, but overall transparency is high.

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 well-structured with sections (When to use, Do NOT use, parameter details). Every sentence provides value, though the length is justified by the tool's complexity. Slightly verbose but not wasteful.

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 complex tool with ranking, grouping, filtering, and multiple datasets, the description covers usage, parameters, edge cases (substring fallback), and response note. The presence of an output schema reduces the need to describe return format. The description is complete and leaves no critical gaps.

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 0%, so the description must explain parameters. It adds meaning for value_column, filters, and top_k, including default values and behavior. Filename, group_by, and ascending are self-explanatory from their names. The description compensates well but could elaborate on all parameters.

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 any grouping column by any numeric column in any dataset.' It provides specific use cases and explicitly distinguishes from sibling tool rank_entities, making the purpose 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 includes a 'When to use' section with concrete examples (top donors, regional analysis) and a 'Do NOT use when' section that identifies alternatives (rank_entities) with specific conditions (long-format datasets, standard pipeline totals). This provides excellent guidance on when to choose this tool.

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?

No annotations provided, so description bears full burden. It describes the operation (ranking by stage total), explains supported layouts, and notes optional filters and default top_k. However, it does not explicitly state whether the tool is read-only or whether it has side effects, nor does it detail output behavior beyond what's implied.

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?

Description is well-structured with sections, front-loading the main action. It is somewhat verbose but each sentence adds value. Minor redundancy in listing stage values twice.

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 7 parameters, no schema descriptions, and presence of an output schema, the description covers core functionality well but misses details on parameters like 'filename', 'group_by', and 'top_k'. It provides adequate context for a moderately complex ranking 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?

Schema coverage is 0%, so description must compensate. It explains 'stage' values and optional 'filters' as a dict. It introduces the concept of layouts (wide/long) which maps to group_by, stage_col, and amount_col. However, it does not explain 'filename', 'group_by', or 'top_k' semantics in detail, leaving some gaps.

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 clearly states it ranks entities by a finance STAGE total, listing specific stages (pledge, deposit, approval, disbursement). It distinguishes from siblings like rank_by_column and fund_conversion_ratios by specifying the exact resource (entities by stage total) and supported layouts.

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 provides 'When to use' and 'Do NOT use when' sections, listing alternatives for each exclusion case (e.g., rank_by_column, fund_conversion_ratios, filter_funds_by_threshold). This gives clear guidance on tool selection.

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?

No annotations provided, so description carries full burden. Mentions use of difflib and return values (best_match, candidates), but lacks details on case sensitivity, matching algorithm specifics, or any side effects. It implies read-only behavior but does not explicitly confirm safety or idempotency.

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, front-loaded with core purpose. Each sentence adds value: purpose, usage guideline, and return value. No redundant or filler content.

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 fuzzy-matching complexity and lack of annotations, the description covers purpose and usage well. It mentions the output schema exists (return values defined elsewhere). However, it omits behavioral details like case sensitivity and performance considerations, which would enhance completeness.

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 0%, so description must compensate. It clarifies the query parameter as a user-supplied string (e.g., fund name) but does not explain the column parameter, top_k, filename, or dataset_uri. This leaves significant ambiguity for a tool with 5 parameters.

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 clearly states the tool's function: fuzzy-match a user-supplied string against real column values using difflib. It specifies the result includes best_match and candidates, and distinguishes its role as a preprocessing step for other tools. This clearly differentiates it from sibling search 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 'Always call this before any tool that takes a fund name, type, or sector string' and explains the benefit of preventing 'not found' errors. This provides strong guidance on when to use the tool, effectively distinguishing it from sibling tools like search_funds.

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?

No annotations provided, but the description adds behavioral context by explaining the match_relevance field (0-1) and warning about low scores meaning substring-only hits, instructing the user to verify. This adds value 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 concise with three sentences, each adding value: defines search scope, mentions return columns and relevance, and provides usage guidance. No wasted words.

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 adequate but lacks details on potential error conditions or pagination. It mentions 'key financial metrics' but does not specify which ones, relying on 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 0%, and the description does not explain the 'query' parameter semantics or the 'limit' parameter's purpose beyond default value. It only mentions 'keyword search' which is generic, leaving parameter details missing.

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 'Keyword search across fund name, type, focus, and sector columns' with a clear verb and resource. It implies searching across multiple columns, which distinguishes it from siblings like filter_funds_by_threshold or get_fund_details, but does not explicitly differentiate.

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 says 'Use as the primary entry point when a user mentions a fund name or theme,' providing clear usage context. It does not mention when not to use or alternatives, but the guidance is sufficient.

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?

No annotations are provided, so the description carries full burden. It describes grouping by sector and metric but does not detail behavioral traits like sorting order, whether shares are percentages, data freshness, or error handling. While it mentions 'totals and share', it lacks specifics.

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: first defines purpose and metric, second gives usage condition, third lists exclusions. Every sentence adds value, and core information is front-loaded. No unnecessary words.

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?

An output schema exists, so return values need not be explained. The tool is simple with two parameters, and the description covers purpose, one parameter, and usage guidelines. Missing explanation for 'top_n' is a minor gap, but overall the description is sufficiently complete for this context.

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 0%, so the description must compensate. It explains the 'metric' parameter with allowed values, but does not explain 'top_n' (default 20). Since top_n likely limits the number of sectors, omitting its meaning leaves a gap.

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 it aggregates totals and share by fund_focus_sector and explains the metric parameter. It distinguishes from sibling tools by explicitly advising against use for geographic regions or project-level sectors, directing to rank_by_column instead.

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 ('when the user asks how pledges or flows split across fund focus sectors') and when-not-to-use (geographic regions, project-level sectors) with concrete alternative tools (rank_by_column). This leaves no ambiguity about appropriate contexts.

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?

Without annotations, the description carries the burden. It discloses clearing previous events, returning a run_id, and automatic logging of subsequent calls. This is good, but could mention idempotency or re-calling behavior.

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 concise with five sentences, each serving a purpose: stating purpose, usage timing, side effects, and context. No wasted words, front-loaded with essential information.

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 an output schema (not shown) and one parameter, the description covers initialization behavior and logging side effects. It lacks details on parameter semantics and whether this step must be followed by finalize_run, but the sibling list provides context.

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 0%, so the description must add meaning to the single 'query' parameter. The description mentions 'for a user query' but does not specify what the query string should contain (e.g., raw user question, formatted query). This leaves ambiguity.

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 purpose: 'Begin a new audit run for a user query.' It further specifies to call at the start of each user question, distinguishing it from siblings like finalize_run and get_audit_trail.

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: 'Call once at the start of each user question.' It implies this is a setup step, but does not explicitly exclude other uses or mention alternatives, though context suffices.

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