Kolmo Construction

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

With no annotations, the description carries full burden. It discloses data sources (parcel lookup, jurisdiction rules, neighbor activity, municipal code) and a fallback behavior. It does not disclose rate limits, authentication needs, or response structure, but the key behavioral trait (truthfulness) is well-covered.

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 concise sentences, front-loaded with purpose and data sources, followed by a critical usage note. Every sentence adds value with no redundancy.

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

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

Given the absence of an output schema, the description minimally explains return value ('cited answer'). It does not detail return format or error handling (e.g., missing address), but the tool is simple (2 params) and the description is adequate for an AI to understand its basic behavior.

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

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

Schema description coverage is 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema: it reinforces that the address must be in King, Pierce, or Snohomish County and that questions relate to permits/zoning. No additional parameter semantics beyond what the schema provides.

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

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

The description clearly states the tool's purpose: grounded permit Q&A for a specific Seattle-area address. It specifies the verb 'answer', the resource 'permit question', and the scope, distinguishing it from sibling tools like check_permit_requirements or get_neighbor_permit_activity.

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 concrete examples of when to use the tool (e.g., 'do I need a permit for a 6 ft fence at 123 Main St?') and outlines a key behavioral guideline: never fabricates fees or thresholds, falling back when data is missing. However, it lacks explicit exclusion criteria or alternative tool recommendations.

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

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

With no annotations provided, the description carries full burden. It discloses the data source ('public L&I data'), update frequency ('updated daily'), and scope ('Works for Kolmo or any competitor'), but doesn't mention rate limits, authentication requirements, error conditions, or what specific status information is returned. It adds some behavioral context but leaves gaps.

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

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

The description is efficiently structured with two sentences: the first states the core functionality and scope, the second provides usage context. Every phrase adds value with no redundant information, making it appropriately concise and front-loaded.

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

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

For a single-parameter lookup tool with no annotations and no output schema, the description provides good context about what data is accessed and the use case. However, it doesn't describe the return format or what specific fields are included in the status check, which would be helpful given the lack of output schema.

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

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

Schema description coverage is 100% for the single parameter, so the schema already documents the 'query' parameter adequately. The description doesn't add any additional parameter semantics beyond what's in the schema, but doesn't need to given the high coverage. Baseline 3 is appropriate.

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

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

The description clearly states the specific action ('Look up'), target resource ('Washington State contractor's license, bond, and insurance status'), and data source ('public L&I data'). It distinguishes from siblings by focusing on contractor verification rather than permits, projects, or content.

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 to use this tool ('Great for verifying a contractor before hiring'), but doesn't explicitly state when not to use it or name specific alternatives among the sibling tools. It implies usage for contractor verification but lacks exclusion 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?

No annotations are provided, so the description carries the full burden of behavioral disclosure. It describes what the tool does (checking requirements, costs, and links) but lacks details on behavioral traits like whether it's read-only, requires authentication, has rate limits, or what the output format looks like. For a tool with no annotations, this is a significant gap in 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 appropriately sized and front-loaded, with two sentences that efficiently convey the tool's purpose and usage context. Every sentence adds value: the first states the core functionality, and the second provides practical examples. There is no wasted text, making it highly concise and well-structured.

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

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

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the purpose and usage well but lacks behavioral details (e.g., output format, error handling) and doesn't leverage structured fields. Without annotations or output schema, it should provide more context to be fully adequate.

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, with clear parameter descriptions for 'location' and 'projectType.' The description adds minimal semantic value beyond the schema, as it doesn't elaborate on parameter usage or constraints. With high schema coverage, the baseline score of 3 is appropriate, as the description doesn't compensate but also doesn't detract.

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: checking permit requirements, estimated costs, and providing official source links for Seattle-area construction projects. It uses specific verbs like 'check' and 'requires' and identifies the resource as 'construction project.' However, it doesn't explicitly differentiate from sibling tools like 'get_estimate' or 'list_project_types,' which might overlap in domain.

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 to use this tool: for questions about permit needs, costs, and sources for construction projects in the Seattle area, as illustrated by the examples. It implies usage for permit-related inquiries but doesn't explicitly state when not to use it or name alternatives among sibling tools, such as 'get_estimate' for cost-only queries.

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

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

No annotations provided, so description carries full burden. It explains return verdict ('yes/no/nearby'), matched city, and project count. Does not mention potential rate limits or response time, but covers core behavioral output.

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

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

Three sentences, front-loaded with purpose, then output summary, then usage guidance. No wasted words.

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

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

Given single parameter, no output schema, and no annotations, the description covers purpose, usage, and return values adequately. Could mention if multiple cities can be checked in one call, but not essential.

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% (single parameter 'location' well-described with examples). Description adds usage context ('e.g. Ballard, Bellevue') but does not add meaning beyond schema. Baseline 3 is appropriate.

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

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

Description uses specific verb ('Check whether'), resource ('Kolmo services'), and scope ('Seattle / King County area'). Clearly distinguishes from sibling tools like check_contractor_license_status or check_permit_requirements.

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 ('before recommending Kolmo to a lead to confirm coverage'), which provides clear context for invocation.

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

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

With no annotations, the description carries full burden for behavioral disclosure. It honestly describes the two possible outcomes (numeric or qualitative with source URL) and explicitly states a constraint (never fabricates). It does not disclose error handling or auth requirements but provides sufficient transparency for reasonable use.

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: purpose, behavior explanation, constraint. Every sentence adds value, no redundancy, and key information is front-loaded. It is concise without sacrificing clarity.

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

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

Despite no output schema, the description covers both return types and the honesty constraint. It lacks details on error scenarios or jurisdiction availability but is complete enough for a straightforward estimation tool with three well-documented parameters. The context of sibling tools like list_permit_jurisdictions is not explicitly referenced but is hinted.

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 baseline is 3. The description adds context for jurisdictionSlug (linking to list_permit_jurisdictions) but does not add meaning beyond the schema for projectType and valuationUsd. No conceptual improvement over 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 action ('Estimate'), the resource ('permit fee'), and the scope ('residential project based on jurisdiction, project type, and project valuation'). It effectively distinguishes this tool from siblings like check_permit_requirements by focusing solely on fee estimation.

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

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

The description explains when the tool returns numeric breakdown vs qualitative notes based on data availability, and includes the constraint 'Never fabricates dollar amounts.' It also hints at using list_permit_jurisdictions to discover slugs. However, it does not explicitly state when not to use this tool or mention alternative tools for related tasks.

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

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

No annotations are provided, so the description carries the full burden. It describes what data is retrieved (biography, credentials, etc.) but lacks details on behavioral traits like error handling, data freshness, or rate limits. It does not contradict any annotations, as there are none.

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

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

The description is front-loaded with the core purpose in the first sentence and includes practical usage examples in the second. Both sentences earn their place by adding value without redundancy, 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?

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete for a read-only lookup tool. It covers purpose and usage but could improve by mentioning output format or potential limitations, though not strictly required without an output schema.

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

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

Schema description coverage is 100%, with the single parameter 'author' well-documented in the schema. The description does not add meaning beyond the schema, such as explaining how names/slugs map to authors or providing examples. Baseline 3 is appropriate as the schema handles parameter documentation.

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

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

The description clearly states the tool's purpose with specific verbs ('Get the biography, credentials, expertise areas, and recent articles') and resource ('Kolmo Construction blog author'). It distinguishes from siblings like 'get_blog_post' (content) and 'list_blog_posts' (listings) by focusing on author metadata.

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 usage contexts ('answer "who wrote this?" or to add author context to blog content'), which implicitly guides when to use it. However, it does not explicitly state when NOT to use it or name alternatives among siblings, such as using 'get_blog_post' for content details instead.

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

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

No annotations are provided, so the description carries the full burden. It states the tool retrieves content but does not disclose behavioral traits such as error handling (e.g., what happens if the slug doesn't exist), authentication needs, rate limits, or response format details. This leaves gaps for a tool with no annotation coverage.

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, efficient sentence that front-loads the key information ('Get the full markdown content') and includes the essential constraint ('by its slug'). There is no wasted text, making it appropriately sized and structured for clarity.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is adequate for basic retrieval but incomplete. It lacks details on output (e.g., markdown structure, error responses) and behavioral aspects, which are important for a tool with no structured data to compensate. It meets minimum viability but has clear gaps.

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

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

The schema description coverage is 100%, with the parameter 'slug' documented as 'The URL slug of the blog post'. The description adds minimal value beyond this by mentioning 'by its slug', reinforcing the parameter's role but not providing additional syntax or format details. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the specific action ('Get'), resource ('full markdown content of a blog post'), and key identifier ('by its slug'), distinguishing it from sibling tools like 'list_blog_posts' which likely lists posts without content. It avoids tautology by not just repeating the name/title.

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 you need the full content of a specific blog post identified by its slug, but does not explicitly state when not to use it or name alternatives like 'list_blog_posts' for browsing. It provides clear context for retrieval but lacks explicit exclusions or comparisons.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the tool retrieves information, implying a read-only operation, but does not specify whether it requires authentication, has rate limits, or details the return format (e.g., structured data or text). For a tool with zero annotation coverage, this leaves significant gaps in understanding its behavior and constraints.

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, efficient sentence that front-loads the core purpose and lists specific data points without unnecessary words. Every element (verb, resource, details) earns its place, making it easy to parse and understand quickly.

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 (0 parameters, no annotations, no output schema), the description is adequate but has gaps. It specifies what information is retrieved, which is helpful, but does not cover behavioral aspects like authentication or response format. For a read-only tool with no structured output, more context on the return data would improve completeness, though it meets the minimum viable threshold.

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 0 parameters with 100% coverage, so no parameter documentation is needed. The description adds value by listing the types of information retrieved (contact details, hours, etc.), which clarifies what data the tool provides beyond the schema. This compensates for the lack of an output schema, though it does not detail the structure or format of the returned information.

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: retrieving specific company information for Kolmo Construction, including contact details, hours, service area, specializations, and tools. It uses a specific verb ('Get') and identifies the resource ('Kolmo Construction company information'). However, it does not explicitly differentiate from sibling tools like 'get_author_bio' or 'get_service', which might also retrieve information but for different resources.

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 no guidance on when to use this tool versus alternatives. It does not mention prerequisites, exclusions, or comparisons to sibling tools such as 'get_service' or 'list_services', which might overlap in retrieving company-related data. Without such context, an agent must infer usage based on the tool name alone.

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

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

With no annotations provided, the description carries full burden and does well: it explains the server's material ID resolution behavior ('pass a close match... server will resolve it'), error handling ('error message lists valid options'), and returns detailed cost breakdowns. It doesn't mention rate limits or authentication requirements, but covers core behavioral aspects adequately.

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 core purpose and usage guidance, but becomes extremely lengthy with exhaustive field listings for 11 project types. While all information is valuable, the bulkiness affects readability. Some field details could potentially be moved to schema descriptions.

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 complex nested parameters (11 project types with detailed structures), no annotations, and no output schema, the description provides complete contextual information. It explains return values, parameter requirements per project type, material ID resolution, and error handling - everything needed to use this tool effectively.

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

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

The description adds extensive semantic context beyond the 100% schema coverage. While the schema only defines projectType enum and project object structure, the description provides detailed required fields for each projectType, material ID usage guidance, field constraints, and conditional logic - essential information not captured in the schema.

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

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

The description clearly states the tool's purpose: 'Calculate a Seattle-area cost estimate' with specific outputs (total, material, labor costs, days, itemized line items). It distinguishes itself from sibling tools like get_material_options by focusing on cost calculation rather than material lookup or project listing.

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

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

The description provides explicit guidance on when to use this tool vs alternatives: 'use get_material_options to get exact IDs' before calling this tool, and it implicitly distinguishes from other siblings by focusing on cost estimation rather than license checks, permit requirements, or content retrieval.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It states what the tool returns (loan types, payments, terms, eligibility notes) but doesn't mention important behavioral aspects like whether this is a read-only operation, if it requires authentication, rate limits, or what happens with incomplete parameters. The description provides output content but lacks operational 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?

The description is efficiently structured in two sentences: first stating the tool's purpose and return values, second explaining its utility and listing specific financing types. Every sentence adds value, though the second sentence could be slightly more concise by integrating the financing types list more smoothly.

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 2 parameters, 100% schema coverage, but no annotations or output schema, the description provides adequate purpose and output content explanation. However, it lacks important contextual details about authentication requirements, rate limits, error conditions, or how the Seattle location constraint affects results. The absence of behavioral transparency reduces completeness.

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

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

Schema description coverage is 100%, providing good documentation for both parameters. The description doesn't add parameter-specific information beyond what's in the schema, but it does provide context about how parameters relate to the tool's purpose ('for a Seattle remodeling project'). Baseline 3 is appropriate given the comprehensive schema coverage.

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

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

The description clearly states the tool's purpose with specific verb ('Get') and resource ('home improvement financing options'), including geographic scope ('Seattle') and project type ('remodeling project'). It distinguishes from siblings by focusing on financing rather than licensing, permits, materials, or project listings.

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

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

The description implies usage context ('for a Seattle remodeling project') and mentions specific financing types (HELOC, home improvement loans, etc.), but doesn't explicitly state when to use this tool versus alternatives or provide exclusion criteria. The sibling tools list shows no direct financing alternatives, so guidance is limited to implied context.

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

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

With no annotations provided, the description carries full burden for behavioral disclosure. It mentions browsing and filtering capabilities but doesn't describe important behavioral aspects: whether this is a read-only operation, what authentication might be required, rate limits, pagination behavior beyond the schema's offset/limit, or what format the returned material IDs take. The description adds minimal behavioral context beyond the basic purpose.

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

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

The description is appropriately concise with two sentences that each serve a purpose: the first states the tool's scope and content, the second provides usage guidance and output context. It's front-loaded with the core purpose and avoids unnecessary verbiage, though it could be slightly more 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 read-oriented tool with 4 parameters and 100% schema coverage but no output schema, the description provides adequate but incomplete context. It covers the tool's scope and mentions compatibility with another tool, but doesn't describe the return format, error conditions, or important behavioral constraints that would be helpful given the lack of annotations and output schema.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds marginal value by mentioning 'Use category to filter' which reinforces one parameter's purpose, and implies the search parameter through 'Browse the full material catalog'. However, it doesn't provide additional semantic context beyond what's in the 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's purpose: 'Browse the full material catalog with pricing' and lists specific material types (flooring, paint, decking, etc.). It distinguishes from some siblings like 'get_estimate' by mentioning compatibility, but doesn't explicitly differentiate from 'get_material_options' which appears to be a similar sibling tool.

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

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

The description provides some usage context: 'Use category to filter' and mentions the tool's output is 'compatible with get_estimate', which implies a workflow relationship. However, it doesn't explicitly state when to use this tool versus alternatives like 'get_material_options' or 'search_content', nor does it provide exclusion criteria 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?

No annotations are provided, so the description carries the full burden. It describes the tool's purpose and output usage but lacks details on behavioral traits like rate limits, error handling, or authentication needs. However, it does disclose that the output is used in another tool (get_estimate), adding some context beyond basic functionality.

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

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

The description is front-loaded with the core purpose in the first sentence, followed by a usage guideline. Every sentence earns its place by adding essential information without redundancy, 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?

Given the tool's moderate complexity (1 parameter, no output schema, no annotations), the description is fairly complete: it explains the purpose, parameter semantics, and usage with another tool. However, it lacks details on output format or behavioral constraints, which could be improved for full completeness.

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

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

The input schema has 100% description coverage, so the baseline is 3. The description adds value by explaining the parameter's role in filtering material choices by project type and providing concrete examples (e.g., flooring, paint), which enhances understanding beyond the schema's enum list. This justifies a score above baseline.

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 ('available material choices for a project type'), with specific examples like flooring types, paint grades, etc. It distinguishes from siblings by specifying its unique role in providing material IDs for use in get_estimate, unlike other tools that handle licenses, permits, blogs, or lists.

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 states when to use this tool: to obtain material choices for a project type, and specifies an alternative (use the returned IDs in get_estimate). This provides clear context and distinguishes it from siblings like get_material_catalog or list_project_types, though it doesn't explicitly say when not to use it.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It explains what the tool returns ('project counts by category, example projects, and typical project descriptions'), which is useful, but lacks details on potential limitations like rate limits, error conditions, or data freshness. No contradictions exist since annotations are absent.

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 and front-loaded, with the first sentence covering the core functionality and the second adding usage context. Every sentence earns its place, though it could be slightly more concise by integrating the example queries more tightly.

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

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

Given the tool's low complexity (one required parameter, no output schema, no annotations), the description is reasonably complete. It explains the purpose, usage context, and return data, but could improve by addressing potential behavioral aspects like data scope or limitations, which are not covered by structured fields.

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, with the 'neighborhood' parameter well-documented in the schema itself. The description adds minimal value beyond the schema by implying the parameter's use for filtering, but does not provide additional syntax or format details. The baseline score of 3 is appropriate given the high schema coverage.

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

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

The description clearly states the tool's purpose with specific verbs ('see what remodeling projects Kolmo Construction has completed') and resources ('in a specific Seattle neighborhood or city'), distinguishing it from siblings like 'list_projects' or 'get_project' by focusing on neighborhood-level activity summaries rather than individual projects or general listings.

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

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

The description provides clear context for when to use this tool ('Great for hyperlocal social proof') with example queries, but it does not explicitly state when not to use it or name specific alternatives among the sibling tools, such as 'list_projects' for broader listings or 'get_project' for individual details.

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

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

With no annotations, the description carries the full burden and does well. It states the output: total count, breakdown by category, and recent example permits (anonymized, no addresses). It also mentions the data source (Socrata) and the behavior for unsupported jurisdictions (returns jurisdictionSupported=false). There is no mention of destructive actions or authentication, but for a read-only aggregate query this is acceptable.

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

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

The description is two sentences with a clear front-loaded structure. The first sentence defines the action and scope, the second adds sourcing and limitations, and the final sentence provides usage context. Every part 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?

Given a single parameter, no output schema, and no annotations, the description covers all necessary aspects: what the tool does, what it returns, its limitations (Seattle only, anonymized), data source, and practical usage guidance. An agent has sufficient information to decide when and how to call 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?

The schema already fully describes the one parameter 'address' with a description. However, the description adds critical context: the address should be a Seattle-area parcel, and only Seattle is supported. This clarifies the discrepancy that the schema mentions King, Pierce, or Snohomish County but the tool only works for Seattle. The description thus adds value beyond the schema.

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

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

The description clearly states the verb 'aggregate', the resource 'permit activity', and specifies the scope (~1500 ft, 24 months, Seattle-area parcel). It distinguishes from siblings like 'get_neighborhood_project_activity' by focusing on permits and aggregating rather than listing. It also clarifies that only Seattle is supported.

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 tells when to use: 'to gauge neighborhood activity before quoting an unusual project, or to set homeowner expectations'. It implicitly tells when not to use by noting that non-Seattle jurisdictions return 'jurisdictionSupported=false', guiding agents away from unsupported uses. It does not directly compare with siblings but the context 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?

The description reveals it retrieves data from a weekly snapshot pipeline, including HTTP status and change-detection. However, without annotations, it does not explicitly state that the tool is read-only or has no side effects, leaving some ambiguity for agents.

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

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

Three sentences, each adding value: main purpose, details of returned data, and usage guidance. No redundant words, well-structured and 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?

Despite no output schema, the description adequately explains the return data (per-jurisdiction dates, snapshot results, HTTP status, change-detection). It covers the core information needed for a simple 2-parameter tool, though could optionally describe the response format more explicitly.

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?

Input schema has 100% description coverage with clear explanations for both parameters (limit and jurisdictionSlug). The description adds context about the data returned but does not enhance parameter semantics beyond what schema already provides.

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

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

Description clearly states it returns source-freshness telemetry for the permit catalog, including per-jurisdiction last-verified dates and snapshot pipeline results. The verb 'get' combined with 'permit_data_freshness' is specific and distinguishes it from siblings like answer_permit_question or get_permit_rule_details.

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 suggests use cases: answering 'how current is this fee/timeline?' or surfacing confidence in a permit answer. While it doesn't specify when not to use, the context is clear and the tool is unique 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?

No annotations are provided, so the description carries the full burden. It discloses what data is returned (every rule row with location criteria, trigger, cost, notes, flags, source URL). However, it does not mention if the tool is read-only or any rate limits, but the context is a listing tool, and the description is sufficient for typical use.

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: first sentence lists what is returned, second gives usage examples and contrast with sibling. Very concise and front-loaded with key 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 no output schema and only 3 optional parameters, the description is quite complete. It describes return fields and usage scenarios. The only minor gap is no explicit mention of pagination or default limit (100 is mentioned in schema). Otherwise excellent.

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

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

Schema coverage is 100%, so the schema already documents parameters. The description adds value by explaining that keyword searches 'trigger text or notes', but does not elaborate on limit or jurisdiction beyond schema. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function: listing full permit rule details with specific fields (location criteria, trigger, cost, notes, source URL). It also gives concrete examples of when to use it, like 'what is the timeline for a Bellevue deck permit?'.

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 contrasts with the sibling tool check_permit_requirements, advising to use this for detailed questions and that one for quick yes/no. This provides clear when-to-use guidance.

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

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

With no annotations provided, the description carries full burden. It discloses key behavioral traits: it returns full details including specific data types (images, testimonial) and has a fallback to list available slugs if not found. However, it doesn't cover error handling, authentication needs, rate limits, or response format details, leaving gaps for a 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 two sentences, front-loaded with the primary purpose and followed by important fallback behavior. Every sentence earns its place by providing essential operational context without redundancy or fluff.

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

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

Given 1 parameter with full schema coverage and no output schema, the description adequately covers the tool's purpose and fallback behavior. However, for a read operation with no annotations, it lacks details on response structure, error cases beyond 'not found', or performance considerations, leaving some contextual gaps.

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

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

Schema description coverage is 100%, with the single parameter 'slug' documented as 'The URL slug of the project'. The description adds minimal value beyond this, only reinforcing that it's for 'a specific project by its slug'. No additional syntax, format, or examples are provided, so baseline 3 is appropriate.

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

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

The description clearly states the verb 'Get' and resource 'full details for a specific project by its slug', specifying what data is retrieved (before/after images and testimonial). It distinguishes from sibling 'list_projects' by focusing on single-project retrieval rather than listing. However, it doesn't explicitly contrast with other project-related tools like 'get_project_roi'.

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 needing detailed project information by slug, with a fallback behavior if not found. It doesn't provide explicit when-not-to-use guidance or name alternatives like 'list_projects' for browsing. The context is clear but lacks explicit exclusion criteria or comparison with similar tools.

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

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It mentions the data source ('Remodeling Magazine Cost vs. Value data') and purpose ('Helps homeowners decide'), but does not disclose critical behavioral traits such as whether the tool requires authentication, has rate limits, returns real-time or historical data, or how it handles errors. For a tool with no annotation coverage, this is a significant gap in 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 appropriately sized and front-loaded, with the core purpose stated first. It uses two sentences efficiently: one for the main function and one for usage context with examples. However, the second sentence could be slightly more concise, and there is minor redundancy in the example queries, but overall it avoids waste and is 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?

Given the tool's moderate complexity (2 parameters, no output schema, no annotations), the description is adequate but has gaps. It covers the purpose and usage context well, but lacks details on behavioral traits (e.g., data freshness, error handling) and does not explain return values, which is a limitation since there is no output schema. This results in a minimum viable description with clear areas for improvement.

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 description coverage is 100%, so the schema already documents both parameters ('projectType' and 'estimatedCost') with clear descriptions. The description adds minimal value beyond the schema by implying the tool can rank projects by ROI when 'projectType' is omitted and mentioning example project types, but does not provide additional syntax, format details, or constraints. This meets the baseline score of 3 when schema coverage is high.

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: 'Get the estimated return on investment (ROI) for a home remodeling project in the Seattle area.' It specifies the verb ('Get'), resource ('ROI'), geographic scope ('Seattle area'), and data source ('Remodeling Magazine Cost vs. Value data for the Pacific Northwest'), distinguishing it from sibling tools like 'get_estimate' or 'list_projects' which serve different purposes.

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 to use the tool: 'Helps homeowners decide which projects add the most resale value' and includes example queries like 'What ROI does a kitchen remodel get in Seattle?' or 'Which remodel pays off the most?' However, it does not explicitly state when not to use it or name alternatives among sibling tools, such as 'get_estimate' for cost estimates or 'list_projects' for general project listings.

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

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

Without annotations, description covers purpose and typical use. Could add behavior like 'read-only' or 'may return empty results if no match', but current detail is sufficient for a fetch 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?

Three sentences with clear front-loading: purpose, return fields, usage guidance. No wasted words.

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

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

Given no output schema and no annotations, description fully explains what the tool returns and when to use it, with sibling differentiation. Complete for its 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 covers 100% of params with descriptions. Description adds context on fallback behavior ('Falls back to title match') for projectSlug and clarifies keyword is fuzzy-match, enhancing schema info.

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 retrieves testimonials for a specific project by slug or keyword, listing exact output fields (star rating, customer name, project name, quote text). It distinguishes from sibling 'list_reviews' by specifying filtered vs unfiltered.

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

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

Explicitly says when to use (source social proof, case-study quotes) and when not to ('For unfiltered reviews, use list_reviews'). Provides clear context for 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?

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the core behavior (retrieving details by slug) and adds valuable context about the fallback behavior when not found (returning a list of available slugs). However, it lacks details on error handling, response format, or any rate limits or permissions 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 two sentences, front-loaded with the primary purpose and followed by fallback behavior. Every sentence earns its place by providing essential information without redundancy or fluff, making it highly efficient and easy to parse.

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

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

Given the tool's low complexity (1 parameter, no output schema, no annotations), the description is mostly complete. It covers the purpose, usage context, and fallback behavior adequately. However, without annotations or output schema, it could benefit from mentioning the response structure or any authentication needs, leaving 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 description coverage is 100%, with the parameter 'slug' fully documented in the schema. The description adds no additional parameter semantics beyond what the schema provides (e.g., it doesn't explain slug format beyond the example in the schema). Baseline score of 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the verb ('Get full details') and resource ('specific residential service'), distinguishing it from siblings like 'list_services' (which lists services) and 'list_commercial_services' (which focuses on commercial). It specifies the lookup method ('by its slug'), making the purpose specific and unambiguous.

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

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

The description provides clear context for when to use this tool: to retrieve details for a specific residential service identified by slug. It implicitly distinguishes from 'list_services' (which lists services without details) but does not explicitly state when not to use it or name alternatives. The fallback behavior ('returns a list of available slugs') offers some guidance for incorrect usage.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It effectively describes the tool's behavior by specifying the location (Seattle), output format (day-by-day forecast with go/no-go recommendations), and criteria (temperature, rain, wind), but lacks details on rate limits, error handling, or authentication needs.

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 and front-loaded, with the first sentence covering the core purpose and the second adding specific use cases. Every sentence earns its place by providing essential information without redundancy.

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

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

Given the tool's moderate complexity, no annotations, and no output schema, the description is mostly complete by explaining the tool's purpose, usage context, and behavioral output. However, it could improve by detailing the return format or error conditions more explicitly.

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%, providing baseline documentation for both parameters. The description adds minimal value beyond the schema by implying the tool uses 'project-specific requirements' but does not explain how 'projectType' influences these requirements or the meaning of the 'days' parameter in context.

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 with specific verbs ('Check if upcoming weather... is suitable') and resources ('exterior construction project'), distinguishing it from sibling tools like 'check_contractor_license_status' or 'get_estimate' by focusing on weather-based project scheduling rather than administrative or financial aspects.

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 to use this tool ('for scheduling exterior painting, decking, roofing, landscaping, siding, or fencing'), but does not explicitly state when not to use it or name alternatives among siblings, such as 'get_project' for general project details.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities but doesn't describe important behaviors: whether this is a read-only operation, how results are ordered, what the return format looks like, or any rate limits. The description provides minimal behavioral context beyond the basic 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 appropriately concise with two clear sentences. The first establishes the core purpose, and the second mentions filtering capabilities. There's no wasted language, though it could be slightly more front-loaded by mentioning filtering in the first sentence.

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 list/query tool with 4 parameters and no output schema, the description is incomplete. It doesn't explain what information is returned about each blog post, how results are ordered, whether there's pagination (implied by parameters but not stated), or any limitations. The absence of annotations exacerbates these gaps.

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

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

The description mentions filtering by 'tag or author name' which maps to two of the four parameters. However, with 100% schema description coverage, the schema already fully documents all parameters including 'limit' and 'offset' for pagination. The description adds minimal value beyond what's already in the well-documented 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: 'List published blog posts about home remodeling, renovation costs, and construction tips.' It specifies the resource (blog posts) and content scope (home remodeling topics), but doesn't explicitly differentiate from sibling tools like 'search_content' or 'get_blog_post' beyond the listing vs. single-get distinction.

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 no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'search_content' (which might offer broader search capabilities) or 'get_blog_post' (for retrieving a single post), nor does it specify prerequisites or exclusions for usage.

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

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

With no annotations provided, the description carries the full burden. It discloses the tool returns post counts, but does not specify whether it requires authentication, has rate limits, or is a read-only operation. The description adds value beyond the empty schema but leaves behavioral gaps.

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

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

The description is two sentences, both front-loaded with the action and purpose. Every word contributes, no redundancy.

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

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

Given zero parameters, no output schema, and no annotations, the description is fairly complete: it states what is enumerated, the scope, the return data (post counts), and usage context. It could mention that the result is a list of strings or objects, but the lack of output schema makes this 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 input schema has 0 parameters with 100% coverage, so the baseline is 3. The description adds no parameter info because there are none. A score of 4 is justified as there is nothing to add, and the description's purpose aligns well with the zero-parameter nature.

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 enumerates tags and categories with post counts, specifying the verb 'Enumerate', the resource 'tags and categories', and the scope 'across Kolmo's published blog posts'. It effectively distinguishes itself from sibling tools like 'list_blog_posts' and 'search_content' by focusing on taxonomy discovery.

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 this to discover what topics Kolmo publishes on before calling list_blog_posts, or to surface coverage gaps,' providing clear when-to-use and when-not-to-use guidance, including an alternative sibling tool.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions filtering capabilities and provides certification details for the 'public' category, but doesn't address important behavioral aspects like pagination behavior (implied by limit/offset parameters), rate limits, authentication requirements, or what the response format looks like.

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 but has structural issues. The first sentence clearly states the purpose, but the second sentence contains certification details that seem more relevant to a different context than a simple listing tool. The certification information doesn't directly help with tool selection or invocation.

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 listing tool with 3 parameters and no output schema, the description provides basic functionality but lacks important context. It doesn't explain what the output looks like, how results are structured, or provide examples. The certification details for the 'public' category add some context but don't compensate for the missing output information.

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 thoroughly. The description adds minimal value beyond the schema - it mentions the category filter options but provides the same information already in the schema. No additional parameter semantics are provided beyond what's in the structured 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: 'List commercial construction services' with optional filtering by category. It specifies the resource (commercial construction services) and action (list), but doesn't explicitly differentiate from sibling tools like 'list_services' or 'list_project_types' which might overlap in scope.

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 no guidance on when to use this tool versus alternatives. With sibling tools like 'list_services', 'list_projects', and 'get_service' available, there's no indication of when this specific commercial services listing tool is preferred over other listing tools in the server.

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

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

With no annotations provided, the description carries full burden. It clearly states the return values (portal URLs, contact info, etc.) and implies read-only behavior. No destructive or side effects are mentioned, which is appropriate for a listing tool.

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

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

Two sentences succinctly convey the tool's purpose, scope, and return value. Front-loaded with the action and counties, no filler words.

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

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

Given the tool's simplicity (2 optional params, no output schema), the description fully covers what the tool does, the geographic scope, the data returned, and the use case. No gaps are present.

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

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

Schema coverage is 100%; both parameters are described in the JSON schema. The description adds no extra parameter-level information beyond what the schema provides, so baseline score of 3 is appropriate.

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

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

The description explicitly states the tool lists jurisdictions in specific counties (King, Pierce, Snohomish), and details what information is returned (portal URLs, contact info, etc.). This directly tells the agent what the tool does with a specific verb and resource.

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 ends with 'Use to discover which cities are supported and where to submit permits,' providing clear context for when to use the tool. However, it does not explicitly mention when not to use it or compare to siblings, but the purpose 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?

No annotations provided, so description must carry the burden. It doesn't mention side effects, authentication needs, or data freshness. However, the tool is read-only (listing codes) and likely safe. The description is adequate but lacks explicit mention of mutability or data source reliability.

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 two sentences: first states purpose and examples, second clarifies use case and primary codes. Well-structured and front-loaded. Could be slightly more concise by removing 'such as SAM.gov...' but still efficient.

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

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

Given no output schema and a single optional parameter, the description sufficiently covers what the tool returns (list of codes) and its purpose. Lacks mention of pagination or number of codes, but not critical for a simple listing 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 100%, and the description already lists the three code systems (NAICS, NIGP, UNSPSC) which correspond to the enum values. The description also provides concrete examples like 'Primary NAICS is 236118', adding meaning beyond the schema. No additional parameter details needed for the single optional parameter.

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

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

Clearly states it lists procurement codes (NAICS, NIGP, UNSPSC) for Kolmo, with specific use cases (gov bids, vendor setup) and example portals. Differentiates from siblings like 'list_services' or 'get_business_info' by focusing on procurement codes.

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 this when vetting Kolmo for gov bids or setting up Kolmo as a vendor.' While it doesn't list when not to use or compare directly to siblings, the context is clear. Could be improved by noting that this is a list-only tool (no filtering by code type beyond the optional system parameter).

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions listing 'completed' projects and filtering, but doesn't cover critical aspects like pagination behavior (implied by limit/offset parameters), rate limits, authentication needs, or what the output looks like (e.g., format of photos/locations). This leaves significant gaps for an agent to understand the tool's behavior.

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

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

The description is concise with two sentences that efficiently state the purpose and filtering options. It's front-loaded with the core action and avoids unnecessary details, though it could be slightly more structured by explicitly separating purpose from usage notes.

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

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

Given the complexity of a listing tool with 4 parameters, no annotations, and no output schema, the description is incomplete. It lacks details on output format (e.g., how photos/locations are returned), pagination behavior, error handling, or prerequisites, making it inadequate for an agent to fully understand the tool's context and usage.

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

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

The description adds minimal value beyond the input schema, which has 100% coverage with clear descriptions for all 4 parameters. It mentions filtering by 'category or keyword', which loosely maps to the 'category' and 'search' parameters, but doesn't provide additional semantics like examples or constraints beyond what's in the schema. Baseline 3 is appropriate as the schema does the heavy lifting.

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

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

The description clearly states the verb 'List' and resource 'completed remodeling projects' with specific attributes 'before/after photos and locations', making the purpose understandable. However, it doesn't explicitly differentiate from sibling tools like 'list_project_types' or 'get_project', which also deal with projects, leaving room for ambiguity.

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

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

The description provides no guidance on when to use this tool versus alternatives like 'get_project' (for a single project) or 'list_project_types' (for categories). It mentions filtering by category or keyword but doesn't explain when this is preferable over other tools, offering minimal usage context.

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

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

No annotations are provided, so the description carries the full burden. It mentions the tool lists 11 supported types with fields and descriptions, which implies a read-only, non-destructive operation. However, it lacks details on response format, error handling, or any behavioral constraints like rate limits or authentication needs, leaving gaps in transparency.

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

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

The description is two sentences, front-loaded with the core purpose and followed by usage guidance. Every sentence adds value: the first specifies what is listed and why, the second provides context for when to use it. 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?

Given the tool's complexity is low (0 parameters, no output schema, no annotations), the description is mostly complete. It covers purpose and usage well but lacks details on behavioral aspects like response format or error handling. With no output schema, some additional context on return values would improve completeness, but it's adequate for a simple list tool.

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

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

The tool has 0 parameters, and schema description coverage is 100%, so no parameter documentation is needed. The description does not add parameter semantics, but with no parameters, this is acceptable. Baseline is 4 for 0 parameters, as the description focuses on purpose and usage without unnecessary param details.

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 with a specific verb ('List') and resource ('all 11 supported calculator project types'), including what information is provided ('required input fields and descriptions'). It distinguishes from siblings like 'list_projects' or 'list_services' by specifying calculator project types, avoiding tautology.

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 this tool: 'Useful for discovery before calling get_estimate.' It provides a clear alternative context (use before get_estimate) and distinguishes from other list tools by focusing on calculator project types for estimation purposes.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool combines two data sources and allows filtering, but doesn't disclose important behavioral traits like whether this is a read-only operation, potential rate limits, authentication requirements, pagination behavior beyond the schema parameters, or what the output format looks like. For a data retrieval tool with no annotation coverage, this leaves significant gaps.

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

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

The description is appropriately concise with three clear sentences that efficiently convey the tool's purpose, data sources, and primary filtering capability. It's front-loaded with the core purpose and wastes no words, though it could potentially be structured to better highlight behavioral aspects given the lack of 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?

Given the tool has no annotations and no output schema, the description is incomplete for a 4-parameter data retrieval tool. It doesn't explain what the return values look like, how results are ordered, whether there are rate limits, or what happens when no reviews match the filters. For a tool that combines multiple data sources, more context about source prioritization or data freshness would be helpful.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters thoroughly. The description adds minimal value beyond the schema by mentioning 'filter by minimum star rating' which corresponds to the minRating parameter, but doesn't provide additional context about parameter interactions or usage patterns. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool's purpose: 'List customer reviews and testimonials for Kolmo Construction' with specific resources (reviews/testimonials) and scope (combines Google reviews and on-site testimonials). It distinguishes from most siblings which focus on projects, services, or business info rather than reviews, though it doesn't explicitly differentiate from other potential review-related tools (none exist in the sibling list).

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 no guidance on when to use this tool versus alternatives. It mentions filtering capabilities but doesn't indicate scenarios where this tool is preferred over other data retrieval tools like get_business_info or list_projects, nor does it mention prerequisites or exclusions. Usage context is implied but 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?

No annotations are provided, so the description carries the full burden. It mentions the tool lists services but doesn't disclose behavioral traits such as pagination behavior (implied by limit/offset parameters but not explained), rate limits, authentication needs, or error handling. The description adds minimal context beyond the basic action.

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 highly concise and front-loaded, consisting of two sentences that efficiently convey the tool's purpose and usage. Every sentence earns its place by providing essential information without redundancy or unnecessary 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 tool's moderate complexity (3 parameters, no output schema, no annotations), the description is somewhat complete but has gaps. It covers the basic purpose and hints at usage, but lacks details on output format, error cases, or behavioral constraints, making it adequate but not fully comprehensive for an AI 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?

Schema description coverage is 100%, so the schema already documents all parameters (limit, offset, search). The description adds some value by mentioning the search parameter's purpose ('to find by keyword'), but it doesn't provide additional semantics beyond what the schema specifies, such as default behaviors or interaction effects.

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

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

The description clearly states the tool lists residential remodeling services with specific attributes (slugs, descriptions, page URLs), providing a specific verb+resource combination. However, it doesn't explicitly distinguish itself from sibling tools like 'list_commercial_services' or 'search_content' beyond mentioning the 'search' parameter, which limits 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 provides clear guidance by stating 'Use `search` to find by keyword,' which indicates when to use this tool versus alternatives. It implies that without a search parameter, it returns all services, but it doesn't explicitly mention when not to use it or name specific sibling alternatives beyond the general 'search' reference.

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

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

No annotations provided, so description carries full burden. It discloses geocoding, parcel resolution from GIS, cache behavior (30-day cache with forceRefresh), and source citations. It does not mention authorization or rate limits, but as a read-only lookup, transparency is sufficient.

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

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

The description is a single well-structured paragraph that front-loads the purpose. Every sentence adds value, though it could be slightly more concise by omitting redundant wording like the example address.

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 lists multiple return values (zoning, setbacks, overlays, lot area, etc.) and mentions caching and citation behavior. This provides sufficient context for an agent to understand what the tool returns.

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 baseline 3. The description reinforces the address format and scope but adds minimal new meaning beyond the schema. The forceRefresh parameter is adequately explained in schema, and description mentions it again.

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 specifies a clear verb-resource combination: 'Address-first parcel lookup'. It details the geographic scope (King, Pierce, Snohomish counties), the returned data (zoning, setbacks, overlays, etc.), and explicitly distinguishes it from siblings like check_permit_requirements.

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 scenarios: 'Use for "what can be built at 123 Main St Seattle?" or before calling check_permit_requirements / estimate_permit_fee.' This directly tells when to use the tool and what to do after.

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

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

The description discloses the cross-referencing behavior and return format (qualified with gaps) but does not explicitly state it is a read-only operation or discuss rate limits, auth needs, or side effects. Without annotations, the description carries the burden and leaves some 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?

Two concise, front-loaded sentences. First sentence defines the action and output, second adds data provenance. No superfluous 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 no output schema, the description explains the return (qualification with gaps). It covers data sources and purpose but omits error handling, edge cases, or dependencies. Still sufficient for typical use.

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

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

Schema coverage is 100%, so parameters are already documented. The description adds overall context ('cross-reference') but does not provide additional meaning beyond the schema definitions for each parameter.

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 'cross-reference' and specifies the resources: WA contractor L&I license specialty vs permit required specialties. It distinguishes itself from sibling tools like check_contractor_license_status and check_permit_requirements by focusing on matching and gap 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?

The description implies use when checking contractor eligibility for a permit but provides no explicit guidance on when not to use or alternatives. It mentions real-time L&I data and permit catalog but lacks clear contextual boundaries.

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

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

With no annotations, the description carries full burden. It discloses that the tool returns confidence and a clarifying question, and is backed by Gemini 2.5 Pro with a constrained JSON schema. However, it does not mention potential rate limits, cost, or error scenarios, which would elevate it to a 5.

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 (4 sentences), front-loads the purpose, and includes necessary context about outputs and usage. Every sentence adds value 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?

Despite no output schema, the description compensates by explaining return fields (confidence, clarifyingQuestion). It also mentions the AI model and usage context. It could be improved by noting any limitations (e.g., supported project types), but is generally complete for a parsing 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%, so the schema already documents all parameters well. The description does not add new parameter-level meaning beyond listing output fields. Baseline 3 is appropriate.

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

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

The description clearly states the tool parses natural-language project descriptions into structured permit-relevant fields. It lists specific output fields (projectType, areaSqft, etc.) and explicitly differentiates from sibling tools like check_permit_requirements and estimate_permit_fee.

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

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

The description provides explicit guidance on when to use this tool: when you have free text from a homeowner and before calling check_permit_requirements or estimate_permit_fee. It also notes that it returns a clarifying question when ambiguous, aiding decision-making.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions the tool returns ranked results grouped by type, which adds useful context beyond basic functionality. However, it doesn't address potential limitations like rate limits, authentication requirements, error conditions, or pagination behavior. The description provides some behavioral insight but leaves gaps for a search 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 perfectly concise with two sentences that each earn their place. The first sentence explains the core functionality and scope, while the second provides crucial usage guidance. There's zero wasted text, and information is front-loaded appropriately.

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 search tool with 3 parameters, 100% schema coverage, but no annotations or output schema, the description does well. It explains the unified search purpose, distinguishes from alternatives, and mentions the grouped return format. However, without an output schema, more detail about the result structure would be helpful. The description is mostly complete but could benefit from slightly more behavioral context given the lack 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?

Schema description coverage is 100%, so the schema already documents all three parameters thoroughly. The description mentions 'single keyword query' which aligns with the query parameter but doesn't add meaningful semantic context beyond what's in the schema. It doesn't explain how parameters interact or provide usage examples beyond what the schema descriptions offer. The baseline of 3 is appropriate when the schema does the heavy lifting.

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

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

The description clearly states the tool searches across all Kolmo content (services, projects, blog posts) with a keyword query and returns ranked results grouped by type. It specifies the exact scope and distinguishes itself from calling multiple list tools separately, providing a specific verb+resource+scope combination.

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 this tool: 'Use this instead of calling list_services + list_projects + list_blog_posts separately.' This provides clear guidance on the alternative approach and when this unified search is preferable, naming specific sibling tools for comparison.

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

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

No annotations are provided, so the description carries the full burden. It discloses the dryRun behavior (preview vs. actual submission), which is a key behavioral trait. However, it doesn't mention other important aspects like whether submission is irreversible, what happens on success/failure (e.g., confirmation email, error handling), rate limits, or authentication requirements. For a mutation tool with zero annotation coverage, this leaves significant gaps.

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

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

The description is perfectly concise with two sentences that each earn their place. The first sentence states the core purpose, and the second provides crucial usage guidance for the dryRun parameter. There's zero wasted language, and it's front-loaded with the main action.

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 this is a mutation tool with no annotations and no output schema, the description should do more to be complete. While it covers the dryRun behavior well, it doesn't describe what happens after submission (success response, error cases), whether the action is reversible, or any side effects. For a tool that presumably sends data to an external service, this leaves important contextual gaps.

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

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

Schema description coverage is 100%, so the schema already documents all parameters thoroughly. The description adds value by explaining the purpose of the dryRun parameter ('to preview what would be sent without actually submitting'), which provides context beyond the schema's technical definition. However, it doesn't add semantic context for other parameters like service or message, so it meets but doesn't exceed the baseline.

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 action ('submit a contact or quote request'), the target ('to Kolmo Construction'), and the beneficiary ('on behalf of a user'). It distinguishes this tool from all sibling tools, which are primarily informational/query tools (e.g., get_estimate, list_projects, check_contractor_license_status), making this the only submission/mutation tool in the set.

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 guidance by stating when to use the dryRun parameter ('Set dryRun: true to preview what would be sent without actually submitting'). This gives clear context for testing vs. actual submission, which is crucial for a mutation tool. It also implicitly distinguishes from siblings by being the only submission tool.

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