Kolmo Construction

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 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 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?

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 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 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?

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.