Stratalize Intelligence

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description adds value beyond those by disclosing output structure (consensus score, sentiment mix, key themes, platform breakdown) and interpreting results (e.g., high consensus signals established narratives). It also cites the data source (Stratalize AI citation composite), which is useful behavioral context. 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 appropriately front-loaded with the usage statement and is not overly verbose. The example is detailed but informative, contributing to understanding. However, the example length slightly increases the overall bulk, so a 4 is appropriate.

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?

The description covers usage context, expected outputs, and an illustrative example, and it does not have an output schema to lean on. It lacks explicit mention of the 'category' parameter and does not address potential limitations or edge cases, but it is sufficiently complete for an agent to select and invoke the tool correctly. The missing parameter documentation keeps it from a 5.

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 for parameter meaning. It explains 'topic' well through examples ('AI in healthcare') and the phrase 'vendor, category, trend, or business topic,' but it does not clarify the optional 'category' parameter or how it modifies the query. This partial compensation justifies a mid-range score.

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 a specific verb ('researching') and resource ('how AI systems characterize a topic') across multiple platforms. It distinguishes itself from siblings by focusing on consensus across AI systems, and it enumerates the outputs (consensus score, sentiment mix, key themes, breakdown).

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 begins with 'Use when researching...' which provides explicit usage context. It also offers an example interpretation, but it does not explicitly state when not to use this tool or name alternatives, so it falls short of a full 5.

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

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

Annotations already declare readOnlyHint=true, and the description adds behavioral details beyond that by outlining the return values and providing an interpretive example (e.g., 'GROWING trend' from consecutive citation increases). This gives the agent a sense of what to expect without contradicting the read-only nature.

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, front-loaded with the use case, followed by output details and an example. It is efficient and every sentence adds value, though the example could be slightly trimmed without losing meaning.

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 single-parameter tool with no output schema, the description covers usage, return values, an example, and data source. It is reasonably complete, though it could clarify output formatting or edge cases, but for this simplicity level it is 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?

The schema has one parameter (brand_name) with zero description coverage, so the description must compensate. It implies the parameter's meaning via the word 'brand' and the example 'HubSpot', but it does not explicitly define what brand_name accepts or any format constraints. This is adequate but not thorough.

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: monitoring vendor brand trajectory and competitor momentum. It specifies the output (4-week momentum score, trend direction, weekly movement series) and provides a concrete example, distinguishing it from sibling tools focused on other metrics.

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 opens with 'Use when monitoring...' and 'or tracking...', giving clear usage scenarios. It does not mention alternatives or exclusions, but the scenarios are specific enough to guide the agent toward this tool versus generic 'get_' siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the data source ('Stratalize go-to-market composite') and an example output, which is useful but does not disclose additional behaviors like pagination or data aggregation. This aligns with the midpoint.

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 plus an example and source attribution. Each part earns its place, but the example is somewhat verbose. Overall well-structured with front-loaded usage guidance.

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 3-parameter benchmark tool with no output schema, the description is thorough. It states the returned metrics, the key filters, provides a concrete example, and cites the source. An agent can confidently select and invoke this 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 67% (industry and ACV have descriptions, gtm_motion does not). The description compensates by explicitly mentioning 'by industry and GTM motion,' giving semantic meaning to the undocumented parameter. The example further illustrates how parameters combine.

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 verbs and resources: 'Returns CAC payback ranges, LTV/CAC guardrails, and channel efficiency benchmarks by industry and GTM motion.' It clearly identifies the tool's purpose and differentiates it from siblings like get_saas_metrics_benchmark by focusing on CAC and GTM benchmarks.

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?

Opens with 'Use when evaluating sales and marketing efficiency, setting CAC targets, or benchmarking GTM performance before a board review,' giving explicit context for when to invoke. It does not mention alternatives or exclusions, 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 declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds the specific metric (unprompted AI mention frequency), a concrete example, and the data source (Stratalize AI citation index), providing useful behavioral context beyond the annotations. No contradictions or hidden behaviors are evident.

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 four short sentences: usage, return type, example, and source. Information is front-loaded with the use case, followed by concise details. No wasted words or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter read-only tool with no output schema, the description covers what it does, when to use it, and provides an illustrative example. It omits details about result limits or edge cases, but the simplicity of the tool makes this acceptable.

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 only one parameter 'category' with no description (0% coverage). The description compensates by stating it applies to a software category and providing the CRM example, making the parameter's meaning clear. It doesn't define exact value formats, but the example implies common category 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 the tool returns vendors ranked by unprompted AI mention frequency in a software category. The example with CRM and specific mention counts makes the purpose concrete. It distinguishes from siblings by focusing on AI-generated recommendation visibility, not generic rankings or other AI metrics.

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 starts with 'Use when assessing brand visibility in AI-generated recommendations or researching which vendors dominate AI platform responses in a software category,' providing clear context for when to invoke this tool. It does not mention alternatives or exclusion criteria, but the intended use case is unambiguous.

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 readOnlyHint and destructiveHint annotations, the description discloses the methodology ('citation volume patterns') and even names the source ('Stratalize citation volume heuristics'). It also explains the output format (score with evidence strings), adding behavioral context that annotations alone do not provide.

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 usage scenario. Every sentence adds value: use cases, return value, example, and source. There is no fluff or redundant 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 it has only one parameter, no output schema, and strong annotations, the description fully covers what the tool does, how results are presented, and an illustrative example. It is sufficiently complete for an agent to invoke the 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?

The input schema has a single 'category' parameter with no description (0% coverage). The description compensates by clarifying it is a 'software category' and gives an example ('ERP category'), directly enriching the parameter semantics. While it doesn't enumerate valid values, the example and phrasing make the parameter meaning clear.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: 'assessing whether a software category faces near-term displacement risk' and 'timing a market entry or exit decision.' It also specifies the returned value (disruption risk score 0 to 1 with evidence strings) and provides a concrete example, making the purpose unmistakable.

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 begins with 'Use when...' and explicitly lists two use cases, providing clear context for when to invoke the tool. It does not mention alternatives or when-not-to-use, but the guidance is specific enough for an agent to select this tool over siblings.

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

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

Annotations already indicate read-only/non-destructive; description adds meaningful output behaviors: median monthly spend, p25/p75 band, sample size, and source composite. It doesn't cover all edge-case behaviors but adds enough beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four sentences, front-loaded with usage trigger, followed by return details, a useful practical example, and source attribution. Every sentence earns its place with no repetition of schema/annotations.

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 3-param benchmark tool with no output schema, it communicates the key return fields and meaning; however, it omits how optional 'industry' affects results and default behavior, leaving a moderate gap.

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 describes only category (33% coverage); description compensates by explaining company-size filtering and the category example, but leaves 'industry' parameter semantics entirely unspecified and gives no valid-value guidance.

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 specific verb 'benchmarking total spend in a software category against same-size peers', clearly identifying the resource and scope. It distinguishes from siblings like get_industry_spend_benchmark by narrowing to software categories by company size.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use ('Use when benchmarking total spend in a software category against same-size peers') and provides an interpretive example for negotiation mandate. It does not name alternatives/exclusions, so not 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 declare readOnlyHint=true and destructiveHint=false, so the description adds context by mentioning 'live' data and an 'ML-DSA-65 signed receipt'. However, it does not explain what the signed receipt implies for the response, nor any rate limits, data sources, or error behavior, so it provides only partial transparency 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 a single sentence that front-loads the core purpose ('Live company intelligence synthesis:') and packs useful detail. Some specifics like 'ML-DSA-65' may be over-technical, but the sentence remains focused and without 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?

The description gives a good overview of the tool's domain, but with no output schema and no parameter explanations, it leaves gaps: what exactly does the signed receipt look like? What is 'focus' used for? How does this differ from similar synthesis tools? It is adequate for a basic understanding but not fully complete for an agent to invoke correctly without guessing.

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 description coverage, the description must explain both parameters. It implicitly identifies 'company' as the named company, but 'focus' is never mentioned or described, leaving the agent to guess its semantics. The description lists output content but does not map to parameters, so it only partially compensates for the missing schema descriptions.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool provides live company intelligence synthesis covering recent litigation, regulatory exposure, financial, and news developments. This specific content list distinguishes it from siblings like get_regulatory_news_synthesis or get_public_company_financials, and the 'named company' target makes the resource 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 only mentions 'for due diligence workflows' as a use context, but does not provide guidance on when to use this tool versus the many similar synthesis tools (e.g., get_competitive_landscape_synthesis, get_market_intelligence_brief). No explicit when/when-not or alternatives are given, leaving the agent without clear selection criteria.

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 indicate readOnlyHint=true and destructiveHint=false, and the description does not contradict them. It adds valuable context about the data source (DOL Office of Foreign Labor Certification), the aggregate nature of the results, and provides a concrete example with wage levels and certified positions. This goes beyond the annotations without introducing ambiguity.

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 use case, followed by a clear output statement, a concrete example, and a source attribution. Every sentence adds value and there is no fluff or repetition of schema details.

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 absence of an output schema, the description adequately explains what the tool returns (aggregates, example values, source). It could be more explicit about handling optional parameters or return field structure, but the example and dimension list are sufficient for a read-only, filterable data lookup 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 description coverage is 0%, so the description must compensate. It references all four dimensions ('by employer, job title, state, and fiscal year') which map to the schema properties (company_name, job_title, state, fiscal_year), and the example clarifies employer/job title. However, it does not explain value formats, optionality, or parameter combinations, leaving room for interpretation.

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: 'Returns DOL LCA and H-1B wage aggregates by employer, job title, state, and fiscal year.' It includes a specific use case ('Use when benchmarking compensation against disclosed employer wages') and an example, making it easy to distinguish from sibling tools like get_salary_benchmark or get_employer_h1b_wages.

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 first sentence provides explicit use-case context: 'Use when benchmarking compensation against disclosed employer wages or assessing H-1B wage practices before a talent acquisition or competitive hire.' It does not explicitly name alternative tools or exclusion criteria, but the use case is clear enough to guide 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?

Annotations already mark the tool as read-only (readOnlyHint: true). The description adds useful context about the response format ('switch narrative and mention counts') and the data source ('Stratalize citation displacement composite'), going 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?

Three sentences: usage, return value, example plus source. Every sentence serves a purpose 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?

For a single-parameter read-only tool with no output schema, the description provides sufficient operational context, including an example output. Minor gaps: no explicit note on output format beyond the example, but that's acceptable given the simplicity.

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 only vendor_name with 0% description coverage, but the description clarifies that this refers to the 'target vendor' and gives a concrete example (Salesforce), making the parameter meaning clear.

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: 'Returns vendors mentioned as replacements for a target vendor with switch narrative and mention counts.' This is specific and differentiates from sibling tools like get_vendor_alternatives and get_competitive_landscape_synthesis by focusing on displacement signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with 'Use when tracking competitive threats to an incumbent vendor or identifying switching trends' which explicitly defines the use case. It does not mention alternatives or when not to use, so it stops short of a full 5.

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

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

Annotations already indicate read-only and non-destructive behavior. The description adds valuable context by specifying that the synthesis uses 'live web sources' (implying real-time research) and provides a 'signed provenance receipt' (implying verifiable output). This goes beyond the safety annotations, though it does not cover rate limits, latency, or caching.

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 a single, well-structured sentence that front-loads the core purpose ('Competitive landscape synthesis') and efficiently packs in the scope, output contents, data source, and provenance feature without 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 the simple schema (one parameter) and annotations covering safety, the description is fairly complete. It explains what the tool covers (leaders, positioning, dynamics) and notes the source and provenance receipt. However, it does not describe the return format or structure of the synthesis, and some terms like 'signed provenance receipt' could use elaboration.

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 one parameter 'market' with 0% description coverage, so the tool description must compensate. It does so partially by stating the tool is 'for a market category,' implying the 'market' parameter is the category. However, it does not provide examples, formats, or additional guidance to fully clarify parameter semantics.

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 synthesizes a competitive landscape for a market category, covering current leaders, positioning, and dynamics. It distinguishes itself from sibling tools by focusing specifically on competitive landscape synthesis and mentioning the unique 'signed provenance receipt' feature.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when one needs competitive landscape synthesis for a market category, but it does not explicitly state when to use it over the many sibling synthesis tools or provide exclusions. Without explicit alternatives or when-not-to-use guidance, the usage context is only implied.

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=true and destructiveHint=false. The description adds useful context beyond that: it specifies the data source (DOL LCA public data), the type of data returned, and includes an illustrative example with concrete numbers. This enriches the behavioral understanding 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 reasonably concise and front-loaded with the usage guidance, followed by return details and an example. The example is slightly long but illustrative. No redundant filler; each 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?

For a tool with one required parameter, read-only annotations, and no output schema, the description provides sufficient context: what data is returned, the source, and a realistic example. It is complete enough for an agent to select and invoke the tool correctly. Minor gap: no mention of possible limits or pagination, but not necessary given the tool's simplicity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema already covers the parameter fully with examples ('e.g. Google, Deloitte, Cognizant'), achieving 100% schema description coverage. The description adds minimal extra meaning beyond repeating the employer name in the example; it does not provide format or additional constraints, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool returns prevailing wage statistics, certified job titles, wage levels, and state distribution from DOL LCA filings, with a specific use case (analyzing employer H-1B compensation strategy). This distinguishes it from sibling tools like get_salary_benchmark or get_company_salary_disclosure by focusing on H-1B/DOL data.

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 when to use: 'Use when analyzing an employer H-1B compensation strategy or benchmarking tech sector wages against DOL prevailing wage data.' It does not name alternatives or exclusions, but the context is clear enough to guide selection among siblings.

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

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

Annotations already mark the tool as readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds useful context: the data source (USASpending.gov synced data), the example output, and the analytical purpose. It does not contradict annotations and adds substance, though it omits any mention of response size or potential limitations.

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 and front-loaded with the primary use case. Each sentence earns its place: the usage trigger, the data returned, a concrete example, and the source citation. There is no redundancy or filler; the example is illustrative without being overly verbose.

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?

The description covers the tool's purpose, data type, and provides a realistic output example. Given the lack of an output schema, the example is valuable. However, it does not mention data freshness, potential delays in syncing, or how the results are ordered/limited, which would enhance completeness for a data query tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has only 20% description coverage (only state has a description). The description compensates by explicitly listing the filtering dimensions: 'vendor, agency, NAICS code, and fiscal year.' It also implies the vendor is the required parameter via the example. The state parameter is not mentioned, and formats (e.g., fiscal_year) are only suggested by the example, so it is not a 5.

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 verb and resource: 'Returns contract obligation data by vendor, agency, NAICS code, and fiscal year from USASpending.' It also names specific use cases (federal revenue concentration, competitor identification, vendor dependency) and provides a concrete example. This distinguishes it from sibling tools like get_vendor_contract_intelligence by emphasizing the federal/USASpending 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 says 'Use when researching a company federal revenue concentration, identifying government contract competitors, or assessing vendor dependency on federal business.' This provides clear context for when to use the tool, but it does not mention alternatives or when not to use it, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds that the data comes from the GitHub public API and gives an example output, but it does not disclose potential rate limits, data freshness limitations, or behavior for missing organizations. This is moderate added value beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences, front-loaded with usage guidance, then returns, then an illustrative example. Every sentence earns its place, and there is no redundancy or padding.

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 tool with one parameter and no output schema, the description adequately explains what the tool returns ('organization profile and top repository stats with stars, forks, contributors, language breakdown') and provides a concrete example. It lacks edge-case handling or return-format details, but these are not critical given the simplicity and the presence of annotations.

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 one parameter, org_or_company, with 0% description coverage. The description implies the input is a company or organization name through the HashiCorp example and the phrase 'company GitHub footprint,' but it never explicitly states that org_or_company should be the company name. This partially compensates for the missing schema description, justifying a baseline score.

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 with specific verbs and resources: 'Returns organization profile and top repository stats — stars, forks, contributors, and language breakdown.' It also separates itself from sibling tools by focusing on GitHub ecosystem intelligence, distinct from broader vendor or market intelligence 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 opens with explicit usage guidance: 'Use when assessing a technology vendor open-source presence, evaluating developer community strength, or researching a company GitHub footprint before a technical due diligence.' It provides clear context but does not mention when not to use it or name alternatives, so it stops 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?

Annotations already indicate a read-only, non-destructive operation. The description adds meaningful behavioral context by detailing the return values (median monthly spend, category breakdown, productivity medians) and providing a sample output, plus the source. 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?

The description is well-structured with a use case, output summary, example, and source. It is somewhat verbose but every sentence adds value, and the example is particularly helpful for understanding the tool's output.

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?

Despite no output schema, the description provides sufficient context for a simple lookup tool: when to use it, what it returns, a realistic example, and the source. The main gap is the lack of parameter details, but this is already captured in parameter semantics, so overall completeness is solid.

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. While it mentions that results are 'by industry' and gives a healthcare example, it does not explain the 'industry' parameter format or the optional 'company_size' parameter at all. The description offers minimal semantic value beyond what the parameter names imply.

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: validating IT spend against industry peers and building budget baselines. It specifies the output (median monthly spend, category breakdown, productivity medians) and uses a concrete example, making its function unambiguous and distinct from sibling tools focused on categories or company size.

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 provides two usage scenarios: validating total IT spend and creating budget baselines for board presentations. However, it does not distinguish when to use this tool over closely related siblings like get_category_spend_benchmark or get_industry_spend_profile, so it offers clear context without exclusions or alternative guidance.

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

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

Annotations already indicate read-only, and the description adds meaningful context: output includes spend bands, category ranges, and outlier flags, plus a concrete example and data source. This goes beyond the minimal safety annotation and sets expectations for the response.

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 with a purpose, example, and source—each adds value without redundancy. The first sentence front-loads the primary use case and output, making it easy to scan.

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 2-param tool with no output schema, the description explains the output structure and provides a concrete example. It is self-contained enough for an agent to understand what the tool returns and when to invoke it.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% with parameter descriptions and an enum. The description's example (500-person healthcare) clarifies how industry and employee_count combine, adding semantic meaning beyond the schema by showing how the inputs map to a real-world scenario.

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 the tool returns spend bands, category ranges, and outlier flags scaled to employee count for a specific industry and headcount. The example with a 500-person healthcare org makes the purpose concrete and distinguishes it from sibling tools by emphasizing employee-count scaling.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Use when sizing a technology budget for a specific industry and headcount, or identifying category spend outliers,' providing clear usage context. It doesn't name alternative tools or exclusions, but the use case is specific enough to guide 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds the source methodology (Stratalize citation heuristics) and an example with citation share percentages, but doesn't detail the possible signal types or limitations, which would add more behavioral transparency.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences: a usage instruction, a return definition, and a concrete example plus source. Each sentence adds valuable information and it's front-loaded with 'Use when', making it efficient and well-structured.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple read-only tool with one parameter and no output schema, the description covers when to use, what it returns, and gives an illustrative example. It doesn't specify the exact return format, but the example provides enough context for an agent to understand the output shape, so it's fairly 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?

The schema has a single 'category' string parameter with no description. The tool description mentions 'any software category' and uses 'AI infrastructure' in the example, implying the input is a software category name. However, it doesn't explicitly name the parameter or explain valid values, and with 0% schema coverage, the description only partially compensates.

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: evaluating VC software category attractiveness and portfolio category exposure. It specifies exact outputs (growth signal, top brands, citation evidence) and gives a concrete example with AI infrastructure, distinguishing it from sibling tools that focus on other signals like disruption or brand momentum.

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 when evaluating VC software category attractiveness or assessing portfolio category exposure before an investment decision,' providing a clear usage context. However, it doesn't name alternatives or state when not to use, so it falls short of the highest bar.

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=true and destructiveHint=false. The description adds valuable context beyond that: 'Data reflects actual filed returns, not survey estimates' and 'Source: IRS Statistics of Income Division', which gives provenance and reliability without contradicting 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 front-loaded with use cases and a clear statement of what it returns. The example is illustrative but makes the description longer than strictly necessary; every sentence adds value, so it is not overly verbose.

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 (2 params, no output schema), the description covers use cases, data source, output fields (gross receipts, net income margins, effective tax rates), and provides a concrete example. It is complete enough for an agent to select and invoke the 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 50%; the industry parameter is already described in the schema, and the description reinforces it with an example ('Healthcare and Social Assistance'). However, the entity_type parameter is not explained in the description and only has an enum/default in the schema, so the description does not fully compensate for the missing schema description.

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 a specific verb+resource: 'Returns IRS SOI aggregate statistics from actual filed corporation income tax returns' along with the key metrics (gross receipts, net income margins, effective tax rates). This distinguishes it from sibling tools that focus on spend benchmarks, market signals, or other data sources.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening 'Use when benchmarking financial performance..., establishing valuation comparables..., assessing typical effective tax rates..., or producing financial due diligence context' provides explicit use cases. However, it does not name alternative tools or state when NOT to use this tool, so it lacks the exclusion/alternative guidance that would merit 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 indicate a safe read operation. The description adds valuable behavioral context: synthesized from live sources and includes a cryptographic receipt. It does not, however, explain what the receipt is for or how to verify it, which is an omission.

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 a single, well-structured sentence that front-loads the key output and scope. It is efficient and avoids 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 no output schema, the description partially compensates by listing the returned content (bill status, passages, amendments) and the live-source synthesis behavior. However, it does not describe the output format, the nature of the cryptographic receipt, or any limitations of the synthesis, leaving gaps for 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 description mentions 'topic and jurisdiction' in the context of scoping the search, giving meaning to the two parameters. With 0% schema description coverage, this is helpful, but it lacks details on expected formats, examples, or constraints beyond what the schema's min/max lengths provide.

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 synthesizes legislative intelligence: current bill status, recent passages, and amendments, scoped by topic and jurisdiction. This specific content differentiates it from sibling tools like get_regulatory_news_synthesis and get_web_research_synthesis.

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 use for tracking legislative activity on a topic and jurisdiction, but provides no explicit guidance on when to choose this tool over alternatives such as get_regulatory_news_synthesis. There are no stated exclusions or prerequisites.

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 indicate readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds that the tool returns data only when FRED API is configured, mentions daily updates, and provides an example with interpretation. It does not explain behavior when FRED is unconfigured, but this is contextual beyond annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three sentences with each serving a purpose: usage context, output list, and illustrative example. It is slightly dense but not wordy, and the example adds practical value. A score of 4 reflects its efficient yet informative structure.

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 read-only tool with one optional parameter and no output schema, the description provides a good overview including data points, source, update frequency, and an example. It is missing parameter semantics and failure-mode behavior, but overall it gives sufficient context for most use cases.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one optional parameter, signal_type, with no description and 0% schema coverage. The tool description never mentions this parameter, leaving its meaning and allowed values entirely unexplained. Since the description fails to compensate for the low schema coverage, this is a critical 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 provides a current macro environment snapshot with specific data points (Fed funds rate, Treasury yields, CPI, PCE, employment) and gives use-case context (trading brief, CFO board presentation, investment committee). This distinguishes it from sibling tools focused on specific categories or company-level signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Use when a current macro environment snapshot is needed for a trading brief, CFO board presentation, or investment committee context.' This provides clear when-to-use guidance. However, it does not mention exclusions or alternatives, so it earns a 4 rather than 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 declare readOnlyHint=true, so safety is covered. The description adds that the output is AI-generated, based on a citation composite, with up to six themes and sentiment skew, going beyond annotations with useful behavioral 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?

Three sentences, front-loaded with use case, then outputs, then a concrete example. 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?

No output schema, and the description omits the 'topic' parameter semantics. However, it covers the main purpose, output examples, and source. Missing param documentation is a clear gap.

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 explain parameters. It explains the required 'industry' parameter via example and 'any industry' mention, but does not explain the optional 'topic' parameter at all. Partial compensation.

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 quick industry intelligence brief and validates market narrative, with a specific list of outputs (summary, themes, sentiment). It does not explicitly name a sibling alternative, but the use case is distinct among the many sibling 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?

It gives an explicit 'Use when' condition (producing a brief or validating narrative for strategy deck), which is clear context. It doesn't mention when not to use or alternatives, so not 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 declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds valuable context about the output type (consolidating/fragmenting), citation evidence, and a concrete example, going 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?

Three sentences, front-loaded with usage guidance, then output description, example, and source. Every sentence earns its place with no redundancy or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool is simple (one parameter, no output schema), and the description covers what it returns (signal type, citation evidence), use cases, and a concrete example. This is sufficient for an agent to invoke it correctly, though it could add a note about how the signal is calculated or typical categories.

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% and the schema only says 'category' is a string. The description implies the parameter is a software category name via the example 'HR tech', which adds some meaning, but it does not explain acceptable values or formatting beyond the single example.

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 ('assessing') and resource ('software category maturity', 'market entry', 'consolidation risk'), and clearly identifies the output as a market structure signal. It distinguishes itself from sibling tools by focusing on consolidation/fragmentation signals.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit use cases ('Use when assessing...') but does not mention when not to use it or name alternative tools. The context is clear enough for an agent to select it appropriately among many siblings.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context by citing the data source ('DOL Enforcement Data') and the post-quantum signed settlement receipt with a verification URL, which goes beyond a typical read operation.

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 long, front-loaded with the core purpose, and every sentence adds value: purpose, source/use case, and verification mechanism. No redundant or vague wording.

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?

Despite the lack of an output schema, the description lists the key return components (inspections, violations, penalties, violation type breakdown) and provides context on data source and verification. For a single-parameter read-only tool, this is 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 description coverage is 0%, but the single parameter (employer_name) is directly clarified by the phrase 'for a named employer' in the first sentence. The description provides enough semantic context for the agent to understand what value to supply, even without a schema description.

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 ('Get') and resource ('OSHA enforcement data'), and enumerates specific outputs ('total inspections, violations, cumulative penalties, and violation type breakdown'). This distinguishes it from sibling tools like get_workplace_safety_benchmark or get_employer_h1b_wages.

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 names use cases ('Use in vendor diligence, M&A, or ESG risk'), providing clear context for when to invoke this tool. It does not explicitly mention when not to use it or name alternative tools, but the context is unambiguous.

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=true and destructiveHint=false. The description adds behavioral context by detailing return values (median spend, category breakdown, savings %) and citing data source (Stratalize PE Intelligence composite), enhancing transparency 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?

Three focused sentences: use case, return values, and an illustrative example. No redundant or filler content. The structure is efficient and front-loaded with the most important usage 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?

The description provides return value details and an example, which is helpful given no output schema. However, the complete omission of parameter semantics is a significant gap, as the agent cannot determine how to invoke the tool with meaningful arguments. This balances to a minimum viable score.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has two parameters (sector and company_count), but the description does not mention either. With 0% schema description coverage, the description entirely fails to explain what these parameters do, acceptable values, or how they affect results. This is a severe 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 benchmarks PE portfolio company technology spend, specifying use case and return metrics. It distinguishes from sibling tools that focus on categories or industries by emphasizing 'portco' and 'across a portfolio'.

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 when benchmarking portco technology spend for PE operating partners or building a software cost reduction case across a portfolio', providing clear when-to-use context. However, it does not mention exclusions or alternatives, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description need not repeat safety. It adds value by explaining the score range (0.91 vs below 0.50), the interpretation (high divergence signals a content gap opportunity), and the data source, which goes 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 three concise sentences, front-loaded with the 'Use when' trigger, and every sentence adds value (purpose, return, example/source). 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?

For a single-parameter, read-only tool with no output schema, the description provides robust context: use case, return type, interpretation, and source. It lacks explicit response structure or error scenarios, but these are minor given the tool's simplicity.

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 no descriptions and only one required parameter, brand_name. The description implies the input is a vendor/brand via examples (Salesforce) but does not explicitly explain the parameter's meaning. It also mentions 'vendor or topic', which is slightly inconsistent with a brand_name-only input, leaving some 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: identifying gaps between AI platform recommendations and actual market position, and returns a platform agreement score. This specific verb ('identify gaps') and resource ('platform divergence') distinguishes it from sibling tools like get_ai_consensus_on_topic, which focuses on consensus topics.

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 opens with 'Use when identifying gaps...' providing a clear trigger for when to apply this tool. However, it does not explicitly name alternative tools or state when not to use it, though the context is clear enough.

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=true and destructiveHint=false, so the safety profile is covered. The description adds behavioral context by listing the three output components (market rate, brand index, displacement signals) and providing a concrete example of the output format, which helps the agent understand what the tool returns 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 three sentences with an illustrative example. It is not overly verbose, but the example is a bit extended. All sentences contribute meaningful information about purpose, usage, and expected output, earning a high score without quite reaching perfect conciseness.

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?

The tool has one parameter, no output schema, and annotations cover safety. The description explains what it does, when to use it, and what it returns (with an example). It is complete for the tool's simplicity, though it could theoretically clarify return structure or limitations, but that's not necessary for this level of 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?

Schema coverage is 0%, so the description must compensate. It does so by mentioning 'any vendor' and using Salesforce as an example, clarifying that vendor_name refers to the vendor being analyzed. Though it doesn't explicitly name the parameter, the single required parameter is obvious from context, making this sufficient.

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 verb (returns), resource (market rate data, brand index snapshot, competitive displacement signals), and purpose (vendor diligence for PE/VC portfolio companies). It distinguishes itself from siblings by combining multiple intelligence types into one composite output, as evidenced by the specific data categories listed.

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 context for when to use: 'when conducting vendor diligence for a PE or VC portfolio company before a value creation initiative.' It does not explicitly name alternatives or exclusions, but the use case is clear and specific enough to guide selection among sibling 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, and the description adds a valuable caveat about cache lag ('cache may reflect prior quarter — verify against latest SEC filing for time-sensitive analysis'). It also discloses the data source (SEC EDGAR synced filings), which is beyond the annotations and helps set expectations about data freshness.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is four sentences and front-loaded with the primary use case, then the return value, a caveat, and an illustrative example. Each sentence earns its place, though the example with specific numbers is slightly verbose for a tool definition.

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 single-parameter, read-only tool with no output schema, the description is fairly complete: it states what data is returned, the source, the freshness caveat, and gives a concrete example. It does not cover all edge cases (e.g., parameter format, non-US companies), but given the tool's simplicity, the essential context is provided.

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 schema description coverage at 0%, the description must compensate for the undocumented 'company_name' parameter, but it only provides an example ('Salesforce FY2024') without explaining whether to pass a ticker, legal name, or how to handle fiscal years. The example could be misinterpreted as including the fiscal year in the parameter, but the schema only allows a single string for company_name.

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 ('Returns') and the resource ('SEC EDGAR financial statement data — income statement, balance sheet, and key ratios') for public company financials. It distinguishes itself from sibling tools by focusing on public companies and SEC filings, and even includes specific use cases (comparable company analysis, M&A due diligence, investor brief).

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 when pulling public company financials for a comparable company analysis, M&A due diligence, or investor brief,' giving clear context for when to use this tool. It does not name alternative tools or state when not to use it, but the use cases are specific enough to imply differentiation from other data sources.

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=true and destructiveHint=false, so the agent knows this is a safe read operation. The description adds valuable context: results are real-time, synthesized from live sources, and include a signed receipt for source verification. This goes beyond the annotations and helps set expectations.

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 a single sentence that packs in purpose, agency examples, output details, and the signed receipt feature. It is free of fluff and front-loads the core function, though it could be split into two sentences for easier 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?

Given the tool has only two simple parameters, no output schema, and strong read-only annotations, the description adequately covers what it returns (enforcement/rule-change developments), how it works (live sources, synthesis), and a distinguishing feature (signed receipt). It does not explain the return format, but this is not a major gap for a tool of this 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?

Schema description coverage is 0%, so the description must compensate. It names example agency values (SEC, FTC, OCC, CFPB, FDA) and implies the topic is a free-text subject. However, the phrase 'for a topic or agency' is ambiguous regarding whether topic is always required, and it doesn't detail the relationship between the two 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 that the tool synthesizes real-time regulatory news for a topic or specific agency, listing examples (SEC, FTC, OCC, CFPB, FDA). It distinguishes itself from sibling tools by focusing specifically on regulatory enforcement and rule-change developments.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides clear context for when this tool is appropriate: when regulatory news on a topic or agency is needed. It lists relevant agencies, which helps with selection. However, it does not explicitly mention alternatives or exclusions, so it stops short of full guidance.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds that the source is 'Stratalize market intelligence composite' and gives a detailed example of the output format (GROWING signal, citation shares, disruption risk), which enriches understanding 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 four sentences: usage, return summary, concrete example, and source attribution. Every sentence adds value with no redundancy, and the most important usage guidance 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?

The description explains what the tool returns and provides a concrete example of the output structure, which is critical since no output schema is available. It lacks detail on the exact response format (e.g., JSON structure) but is sufficient for tool selection and invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema has a single 'category' string with no description. The description clarifies it is a software category and provides 'CRM' as an example, which adds crucial semantic meaning. However, it does not enumerate valid categories or formatting expectations, so it falls short of a perfect score.

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 growth signal, AI citation leaders, and disruption risk for a SaaS category, with a concrete CRM example illustrating each output. This distinguishes it from sibling tools that focus on individual signals (e.g., get_category_ai_leaders, get_category_disruption_signal).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The opening sentence 'Use when assessing a SaaS category investment thesis, competitive dynamics, or market momentum before a strategic decision' provides clear usage context. It does not explicitly mention alternatives or exclusions, but the context is sufficient for most scenarios.

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=true and destructiveHint=false, so safety is covered. The description adds valuable context about the output content (specific metrics), a concrete example with numbers, and the data source (Stratalize tables), which 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?

The description is four sentences long, each serving a distinct purpose: usage context, output list, illustrative example, and source attribution. It is informative without being bloated, though the example could be considered slightly verbose.

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 lack of an output schema, the description compensates by listing the metrics returned and providing a concrete example. It explains the use case and source, making the tool's behavior predictable. It stops short of detailing return format or parameter interactions, but overall completeness is high.

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 parameters are already well-defined. The description adds the concept of 'ARR band' and an example, but does not elaborate on how optional parameters like burn_multiple or growth_rate_pct affect the results. This is adequate but not a major enhancement over 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 explicitly states the tool 'Returns Rule of 40, burn multiple, CAC payback, NRR, gross margin, and ARR growth targets by ARR band,' which is a specific verb+resource that clearly defines its function. It also distinguishes itself from sibling tools by focusing on SaaS financial metrics, not generic benchmarks.

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 context: 'Use when assessing SaaS company financial health, preparing investor reporting, or benchmarking KPIs before a fundraise or board presentation.' It does not explicitly mention when not to use or name alternatives, but the 'Use when' phrasing gives clear situational guidance.

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

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

Annotations already indicate readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds value by describing the content of the returned playbook and a concrete example. However, it does not disclose any limitations (e.g., data freshness or vendor coverage) beyond the provided example, so it earns a mid-range score.

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: a usage condition, a clear statement of outputs, and a concrete example with source attribution. It is front-loaded, efficient, and every sentence earns its place without 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?

Despite lacking an output schema, the description enumerates exactly what the tool returns: timing strategy, leverage points, walk-away alternatives, and a negotiation script. The example grounds the output format. This is complete for a read-only intelligence tool with simple 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 input schema has 100% description coverage for all three parameters (vendor_name, renewal_days_out, contract_value_annual), so the schema already documents them. The description's example implicitly references renewal timing and leverage but does not add explicit parameter-level 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 what the tool does: returns timing strategy, leverage points, walk-away alternatives, and a complete negotiation script for any vendor. The specific example (Datadog renewal) makes the purpose concrete. It does not explicitly differentiate from sibling tools like get_vendor_negotiation_intelligence, but the 'playbook' framing and detailed outputs distinguish it enough.

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 opens with a clear usage condition: 'Use when a major SaaS contract is approaching renewal or auto-renewal risk.' This provides a definite trigger. It doesn't mention when not to use or alternatives, but the context is specific enough to guide 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?

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds meaningful behavior: it returns percentile-based estimates, supports state/industry adjustments, gives an illustrative example, and cites the BLS source. 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?

The description is front-loaded with usage context and remains focused, but the final sentence about retention percentages is tangential to tool invocation and the source attribution could be shortened. Still, every sentence earns some place and there is 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?

For a read-only benchmark tool with no output schema, the description covers purpose, output percentiles, an example, adjustment dimensions, and the data source. It does not specify the exact response structure, but the described outputs are sufficient for an agent to understand how to use and interpret the 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 description coverage is 100% and each parameter already has clear descriptions/examples (e.g., state as 'Two-letter US state code', industry with enumerated examples, job_title with examples). The description reinforces that state and industry are adjustment dimensions but adds no new syntactic or formatting guidance 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 opens with 'Use when...' and clearly states the tool returns p25, p50, p75 wage estimates with state and industry adjustments, making its purpose specific and distinct from siblings like get_company_salary_disclosure. The verb 'Returns' plus the resource (salary benchmark) anchors it well.

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 lists three use cases: setting compensation ranges, evaluating a job offer, and preparing a comp committee presentation. It does not name alternatives or when-not-to-use, but the context is clear and actionable.

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=true and destructiveHint=false, and the description adds useful behavioral context: it returns top brands, trend narrative, themed bullets, and names the data source (Stratalize AI citation composite). This goes beyond the schema and annotations, though it doesn't disclose limitations like data recency or sector coverage boundaries.

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 primary use cases, then details the return content, a concrete example, and the source. Every sentence adds value, and there is no redundant restatement of the tool name or schema. It is appropriately sized for the tool's simplicity.

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 single-parameter, read-only tool with no output schema, the description covers the necessary context: when to use it, what it returns, a working example, and the data source. The low complexity means this is sufficient for an agent to select and invoke the tool correctly without additional detail.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema provides only a generic 'sector' string with no description or enum, and schema description coverage is 0%. The description compensates partially by noting 'any equity sector' and giving the example 'Financials,' but it does not specify acceptable formats, capitalization, or possible values. The guidance is helpful but incomplete.

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 top brands by AI mention share, sector trend narrative, and themed bullets for any equity sector. It gives a concrete example (Financials) and names specific use cases, making the purpose specific and actionable. It does not explicitly contrast with sibling tools like get_category_ai_leaders, so it falls short of a 5.

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 when producing equity research, tracking brand share in AI sector coverage, or benchmarking a company AI visibility against sector peers.' This provides clear contexts, but it does not mention when not to use it or name alternative tools, so it lacks the full exclusion guidance 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is covered. The description adds behavioral context by detailing what the tool returns, including a concrete example showing the level of specificity (e.g., '$0.02/call adds $8,400/yr'). It also cites the data source (Stratalize category pricing composite), which is 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 well-structured and appropriately sized. It front-loads the usage case, then summarizes the output, provides a voluminous but illustrative example, and ends with a source attribution. No unnecessary sentences; every part earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple, read-only tool with one parameter and no output schema, the description is quite complete. It covers purpose, usage, output content, and even gives an example of the output style. It lacks details on return format or limitations, but these are not critical given the simplicity and the presence of annotations.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has one parameter 'category' with no description (0% coverage), so the description must compensate. It does by explaining that categories are software categories, with 'CRM' as an example, and clarifies that output is 'by category.' This provides enough context for the parameter, though it could explicitly list allowed values or format.

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 what the tool does: 'Returns common pricing models, hidden cost patterns, implementation cost ranges, and budget guidance by category.' It specifies both the resource (software pricing intelligence) and the scope (by category), and the example with CRM hidden costs distinguishes it from sibling tools focused on vendor benchmarks or negotiation.

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 provides usage context: 'Use when evaluating a new software purchase or reviewing a vendor quote for hidden costs.' This gives a clear when-to-use, but it does not mention when not to use or alternatives, though sibling tool names imply alternatives. It lacks explicit exclusion of other 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds output details (medians, segments) and a source, but it introduces a significant transparency gap: it says 'software category spend' while the required parameter is vendor_name. This mismatch likely misleads the agent about what input to provide, which is a behavioral disclosure issue beyond what annotations offer.

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 a single coherent paragraph that front-loads the 'when to use' guidance, includes a concrete example with illustrative numbers, and names the data source. It is not overly verbose, though the example does take up space that could have been used to clarify the input.

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?

There is no output schema, so the description must fully define the contract. It provides return segments and an example, but it fails to explain the required vendor_name input and how it maps to a software category. This is a critical completeness gap for a tool with only one parameter—without that clarification, an agent cannot correctly invoke the 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 description provides zero information about the vendor_name parameter and even suggests the input is a software category instead. With 0% schema description coverage, the description was expected to compensate, but it actively misdirects the agent about the required input, making this a critical failure.

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 SMB, mid-market, and enterprise median monthly spend for software categories, positioning it as a size-segmented benchmarking tool. The verb 'returns' and the resource 'median monthly spend by company size' are specific and differentiate it from sibling tools that focus on other dimensions like industry or vendor.

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 spells out the intended use case: 'Use when benchmarking software category spend against same-size organizations before a purchase or renewal.' This gives clear context, but it does not mention exclusions or alternatives, such as when a different benchmark tool would be more appropriate.

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=true and destructiveHint=false, so safe read is known. Description adds meaningful context: auth requirements (public/no-auth vs OAuth), payment/pricing tiers, and scope (governed tools across multiple verticals), 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?

Description is front-loaded with 'START HERE — Returns the complete Stratalize tool catalog' in the first sentence. Each subsequent sentence adds distinct value (verticals, access methods, pricing, call order) with 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?

For a zero-parameter discovery tool without output schema, the description covers purpose, access/auth, pricing model, and explicit call order. It provides enough context for an agent to decide this is the first tool to invoke before using domain-specific siblings.

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?

Tool has zero parameters and empty schema, so schema coverage is 100%. The description compensates by outlining what the response contains (tool catalog by vertical and role), which is sufficient; no parameter clarification 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 uses specific verb 'Returns' and resource 'complete Stratalize tool catalog', clearly distinguishing from sibling data tools. 'START HERE' and 'discover tools by role or vertical' establish it as discovery entry point, not one of the domain-specific get_* 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 instructs 'Call this first to discover tools by role or vertical', giving clear when-to-use. Also distinguishes access modes (public MCP vs x402 micropayments vs OAuth), but does not name specific sibling alternatives or when-not-to-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?

Annotations already declare readOnlyHint=true and destructiveHint=false, reducing risk concerns. The description adds useful behavioral context: data source ('Stratalize market composite'), ranking criteria ('mention count and median spend'), and an illustrative example showing output interpretation. It does not mention pagination or limit behavior, but the annotation coverage lowers the burden.

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 use case is front-loaded and the description is concise overall. The example sentence is somewhat long but earns its place by clarifying output and spend spread. 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?

For a simple read-only tool with no output schema, the description covers purpose, use case, ranking logic, example output, and data source. Missing details like how 'limit' affects results and exact return format are minor given the tool's simplicity.

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 for the two parameters (category, limit). It only implies 'category' via the HR tech example and never explains the 'limit' parameter. The description adds minimal meaning beyond the schema property 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 uses a specific verb ('Returns vendors ranked by mention count and median spend') with a clear resource (vendors) and scope (by category). It distinguishes itself from sibling tools like get_category_spend_benchmark by focusing on vendor-level ranking within a category.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use when building a vendor shortlist for a new software category purchase.' It provides clear context but does not mention exclusions or alternative tools, so it falls short of a 5.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the description only needs to add context. It adds the data source ('USPTO PatentsView synced data') and an example illustrating output granularity. It does not describe pagination/rate limits, but the read-only hint covers safety. This is comparable to the get_calls example which scored 3.

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 appropriately sized at about four sentences. It front-loads usage guidance, then describes output, provides a concrete example, and ends with data source. The example is somewhat verbose but earns its place by showing the output format. No redundant 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 no output schema, the description explains the high-level return values (patent counts, filing years, CPC classification) and gives an example. However, it doesn't detail the exact structure and misses the patent_year parameter entirely. For a two-parameter tool with no output schema, it is adequate but not fully 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%, so the description must compensate. It implicitly clarifies assignee_name via 'rollups by assignee' and the Qualcomm example, but it completely omits the optional patent_year parameter. This leaves a parameter without any meaningful context beyond its name and type.

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: 'Returns USPTO filing rollups by assignee — patent counts, filing years, and CPC classification.' It also gives specific use cases (IP portfolio strength, competitor activity, M&A due diligence) and distinguishes itself from the sibling tools, none of which specialize in patent data.

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 when assessing a company IP portfolio strength, tracking competitor patent activity, or preparing M&A patent due diligence'). It does not mention alternative tools or when not to use it, but the sibling list contains no close patent-related tools, so 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so safety is known. The description adds valuable context: the data source ('Stratalize competitive displacement composite') and a concrete example showing the structure of results, which goes beyond annotation basics.

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 cover purpose, usage context, an example, and the data source. The layout is front-loaded with the use case and every sentence contributes meaning without unnecessary jargon.

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 only 2 parameters and no output schema, the description is quite complete: it states what is returned, gives an example output structure, and cites the source. It could optionally mention the number of alternatives returned, but this is not essential for the tool's use case.

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 vendor_name and reason are described with appropriate detail, including an enum for reason. The description adds no new parameter semantics; it merely echoes that vendor_name is the incumbent, which the schema already states.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: returning alternative vendors with migration complexity scores, estimated savings, and switching narrative. The verb 'returns' plus the specific resource 'alternative vendors' distinguishes it from sibling tools like get_vendor_benchmark or get_competitive_displacement_signal.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly states when to use: 'Use when evaluating a vendor switch or building a competitive RFP against an incumbent.' It does not provide when-not-to-use or name alternative tools, but the context is clear and actionable.

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=true and destructiveHint=false, so safety is clear. The description adds valuable contextual behavior: it returns data from benchmark_cache when fresh, otherwise guidance to load intelligence in Stratalize, and it cites data sources (benchmark_cache + Stratalize composites). This goes beyond annotations to explain conditional/caching behavior, though it doesn't detail response format.

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 and appropriately sized. It opens with the use case, lists return fields, notes cache behavior, provides a concrete Salesforce example, and cites data sources—all in two sentences plus a source line. Every sentence earns its place with no redundant wording.

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 (2 params, 1 required), annotations covering read-only safety, and no output schema, the description is complete. It explains the purpose, the key return fields, data freshness behavior, source, and an illustrative example. No critical contextual information is missing for an agent to select and invoke the 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 description coverage is 100%, so both parameters (vendor_name and mcp_client_source) are fully documented in the schema. The description reinforces vendor_name with an example and clarifies the output context, but it doesn't add new parameter-level semantics beyond what the schema provides, so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb+resource ('get vendor benchmark') and defines its purpose: providing org-specific vendor pricing vs market for CFOs/procurement leads before renewal or negotiation. It lists concrete return fields (market_low, market_median, etc.) and differentiates from sibling tools like get_vendor_market_rate by emphasizing the org-specific and negotiation context.

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 when to use the tool ('when a CFO or procurement lead needs org-specific vendor pricing vs market before renewal or negotiation'), giving clear context. However, it does not mention when not to use it or name specific alternatives, so it stops short of full exclusion guidance.

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

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

The description goes beyond the readOnly/destructive annotations by detailing exactly what data is returned and includes a concrete example with a Sankey-like insight (cost of missing the notice window). It also cites the source, increasing trust. No hidden behaviors are 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?

The description is concise, front-loaded with the use case, then lists outputs and provides an example, all in three sentences. Every sentence adds value; the example is particularly informative without being verbose.

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 read-only tool with one parameter and no output schema, the description is remarkably complete. It specifies purpose, usage timing, output fields, an illustrative example, and data source. It does not need to explain return structure because the outputs are explicitly enumerated.

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 a single required parameter `vendor_name` with no description (0% coverage). The description implicitly clarifies that the vendor name should be provided ('for any major vendor') and offers 'Salesforce' as an example, but it does not specify format or acceptable naming conventions. This is adequate but not fully compensating for the missing schema description.

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 typical contract length, auto-renewal notice window, price escalation percentage, and key risk clauses for a vendor. It specifies the use context of reviewing a new vendor agreement or benchmarking before negotiation, distinguishing it from sibling tools like negotiation playbooks.

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 when to use: 'Use when reviewing a new vendor agreement or benchmarking contract terms before a negotiation.' It does not explicitly list alternatives or exclusions, but the context is clear and the example reinforces the intended use.

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=true and destructiveHint=false, so the safety profile is covered. The description adds valuable behavioral context: it reveals a fallback mechanism (Stratalize composite medians) and the data source, plus an example interpretation. 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 concise, front-loaded with the use case, and packs essential information (returned fields, fallback, source, example) into two sentences with 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?

There is no output schema, so the description lists the returned fields and provides an example, making the return format clear. It also covers fallback behavior and data source. It could mention potential limitations or edge cases, but for a lookup tool with this complexity, it is 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 description coverage is 100%, so the schema already documents all three parameters. The description adds no additional parameter-level meaning beyond the schema, which yields the baseline score 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 clearly states the tool's purpose: to help CFOs/procurement teams determine if they are overpaying for software vendors, and it lists the returned fields. However, it does not explicitly differentiate itself from sibling tools like get_vendor_benchmark or get_software_pricing_intelligence, so it lacks full sibling differentiation.

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 when a CFO or procurement team needs to know if they are overpaying for any software vendor'). It provides clear context but does not mention when not to use it or name 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is known. The description adds value beyond this by disclosing the specific data returned (discount percentages, negotiation windows, leverage points, auto-renewal risk flags, script) and provides a concrete example with numbers, giving the agent a clearer expectation of the tool's output richness. It could go further by noting any limitations (e.g., coverage gaps for niche vendors) but this is not required.

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 and front-loaded: it opens with the usage trigger, then lists the returns, and ends with a concrete example and source. Each sentence serves a purpose with no fluff or repetition. The structure is ideal for quick agent parsing.

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 effectively explains what the tool returns by enumerating key data points and providing an example. It covers the main aspects an agent needs to know for invocation and result interpretation. It could be more complete by mentioning error handling or data availability for unknown vendors, but given the simplicity of a single parameter, this is a minor gap.

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 provides only vendor_name as a required string with no description (0% schema coverage). The description compensates by stating the tool works 'for any vendor' and gives an example with 'Salesforce', making it clear that vendor_name is the vendor's name. While not a formal parameter description, it adds meaningful context beyond the bare 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's purpose: 'Use when preparing to renew or renegotiate a SaaS contract' and lists specific outputs ('returns typical discount percentage, best negotiation windows, leverage points, auto-renewal risk flags, and a negotiation script'). It distinguishes itself from sibling tools by focusing on negotiation-specific intelligence for any vendor, not just benchmarks or market analysis.

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 when-to-use guidance: 'Use when preparing to renew or renegotiate a SaaS contract.' This clearly indicates the primary use case. However, it does not mention when not to use it or name alternative tools, so it misses the full 'when-not/alternatives' criteria for 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 indicate read-only, but the description adds substantial context: return format (score 0-1), risk indicators, negative mention evidence, classification, and recommendation. The example illustrates how to interpret the output, which goes well beyond the annotation's safety profile.

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 detailed but every sentence adds value: use case, output, example, and source. It is front-loaded with the trigger scenario. It could be trimmed slightly, but overall it is well-structured and 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 simple one-parameter, read-only tool with no output schema, the description covers purpose, output format, use case, and interpretation. It is complete enough for an agent to select and invoke the tool correctly without further guidance.

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 a single vendor_name parameter with no description, so the description must compensate. It indirectly defines the parameter through the use case and example ('Vendor X'), making it clear that the value is the vendor's name. However, it lacks explicit detail on format or matching rules, which would elevate it further.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's function: screening a vendor for financial instability or procurement risk. It specifies the output (risk score 0-1, indicators, evidence) and provides a concrete example, making it distinct from sibling tools like get_vendor_benchmark.

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 when screening a vendor for financial instability or procurement risk before a long-term contract commitment,' which gives a clear trigger context. It does not name alternatives, but the use case is specific enough to guide 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?

Annotations already declare readOnlyHint=true and destructiveHint=false, covering safety. The description adds valuable context: the synthesis is 'governed', every source domain is bound into an ML-DSA-65 signed receipt, and the receipt is anchored on Base—non-obvious implementation details beyond the safe-read annotation.

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, efficiently packed. The first sentence introduces the core concept and the second explains the flow. Some jargon (ML-DSA-65, Base) may be unfamiliar but isn't wasted; overall it's appropriately sized.

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 tool with one parameter and no output schema, the description covers the input (research question) and the output behavior (AI synthesis plus signed receipt). It doesn't specify the return format or what 'governed' means, but it is sufficiently 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?

With a single parameter and schema coverage 0%, the description clarifies that the parameter is a 'research question', adding meaning beyond the bare `question` field in the schema. However, it doesn't mention the 5-500 character constraints or provide guidance on question specificity, so 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's function: 'Agent submits a research question; returns an AI synthesis across live web sources with every source domain bound into an ML-DSA-65 signed receipt.' This is a specific action (web research synthesis) with a distinctive output (signed receipt), distinguishing it from sibling synthesis 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 implies usage: when a governed web research synthesis with a signed receipt is needed. It does not explicitly mention alternatives or exclusions among the many sibling synthesis tools, so the guidance is only implicit, not explicit.

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=true and destructiveHint=false, so the baseline safety profile is covered. The description adds valuable behavioral context: establishment-specific data is gated behind an OSHA sync, while industry composites are available without sync. This is beyond what annotations provide and helps set expectations.

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, front-loaded with the core purpose and immediately followed by availability and use case details. Every phrase adds value, and there is 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?

No output schema exists, so the description carries the burden of explaining what data is returned. It covers the main content types (injury rates, top-quartile performance, EMR context) and the use cases. It does not mention return format, pagination, or data vintage, but for a benchmark lookup tool this is sufficiently complete for an agent to select and invoke it.

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 mentions 'company, industry, NAICS code, and state,' which maps to the three parameters (company_or_industry, naics_code, state) and clarifies that 'company_or_industry' can represent either a company or an industry. It does not specify exact formats or constraints, but provides enough semantic meaning for a basic query.

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 OSHA injury and illness rate benchmarks, with a specific verb ('get') implied and a resource ('benchmarks') plus dimensions (company, industry, NAICS code, state). This distinguishes it from sibling tools like get_osha_enforcement, which focuses on enforcement actions rather than benchmark rates.

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 practical usage context: industry composite benchmarks are immediately available, while establishment-specific data requires an OSHA sync. It also lists use cases (insurance, bonding, public contract prequalification). It does not explicitly name alternative tools or say when not to use, but the guidance is clear enough for selection decisions.

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