kolmo-mcp-server

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

With no annotations, the description carries full burden and delivers: it discloses the fallback behavior ('falls back to "I don't have that on file"'), the grounding sources (parcel, jurisdiction rules, neighbor activity, municipal code), and the honesty constraint ('NEVER fabricates fees or thresholds'). It goes beyond the minimal verb+object.

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

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

Two sentences, front-loaded with the core purpose, followed by the behavioral guarantee and concrete usage examples. Every sentence earns its place; no filler.

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

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

The tool is complex (multi-source grounding, citation, fallback) with no output schema. The description covers purpose, inputs, behavior, and usage examples, but could go slightly further by describing the output format or confidence, though not strictly necessary.

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

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

Schema coverage is 100% with each parameter already described. The description adds semantic value by clarifying the question type ('natural-language permit questions like...') and the address scope via examples, complementing rather than repeating the schema.

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

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

The description opens with 'Grounded permit Q&A for a specific Seattle-area address,' immediately establishing a specific verb (answers) and resource (permit questions), and distinguishes itself from sibling tools like lookup_parcel_by_address or estimate_permit_fee by emphasizing a cited, grounding-based Q&A behavior.

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 it: 'Use for natural-language permit questions like...' with concrete examples. It does not explicitly name alternatives or exclusion criteria, but the examples and grounded behavior clearly differentiate it from structured sibling tools.

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

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

With no annotations, the description carries the full burden and adds meaningful context: it specifies the data source (public L&I data), update frequency (updated daily), and the exact checks performed (licensed, bonded, insured). It implicitly signals a read-only operation via 'Look up' and 'public data', with no contradictions.

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

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

The description is concise and front-loaded, but the final sentence partially repeats 'licensed, bonded, and insured' from the first sentence, introducing slight redundancy. Overall it is efficient and each sentence contributes to context or usage.

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

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

Given the simplicity of the tool (one parameter, no output schema, no annotations), the description provides sufficient context: action, use case, data source, update frequency, and scope. It omits return structure and error handling but that is acceptable for this straightforward lookup.

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

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

The input schema already provides a complete description of the 'query' parameter with examples and coverage at 100%. The tool description adds no additional parameter-level details, so the baseline of 3 applies.

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

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

The description uses a specific verb ('Look up') and identifies a clear resource ('Washington State contractor's license, bond, and insurance status'), distinguishing it from sibling tools like check_permit_requirements or get_business_info. The scope ('Works for Kolmo or any competitor') further clarifies its broad applicability.

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 an explicit use case: 'Great for verifying a contractor before hiring.' It clearly implies when to use the tool but does not name alternatives or explicitly state when not to use it, so it falls shy of a 5.

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

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

With no annotations, the description carries the full burden. It discloses return components, jurisdictional fidelity ('Seattle is full SDCI fidelity, other 9 verified cities are wa-baseline-stub'), and the address parameter's behavioral effect. This is substantial transparency, though it doesn't mention side effects or auth.

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 dense paragraph, front-loaded with the main purpose and outputs, followed by usage examples and a technical note. Every sentence adds value, though it is slightly long due to the fidelity detail.

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

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

With no output schema, the description lists the output categories (timeline, fee notes, inspection sequence, submittals, source URL) and the submittals_v2 variant. It lacks a detailed return schema, but the description is sufficient for a permit-checking tool with these parameters.

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

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

All 7 parameters have detailed schema descriptions, so the baseline is 3. The description adds meaning by explaining the `address` parameter's side effect (returns submittals_v2) and its override of `location` for jurisdiction routing, which is beyond the schema.

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

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

The description opens with a specific verb and resource: 'Check whether a residential construction project... requires a permit.' It lists the outputs (timeline, fee notes, inspection sequence, submittals, source URL), which clearly distinguishes it from sibling tools like estimate_permit_fee 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?

Concrete example queries ('Do I need a permit to build a deck in Seattle?') establish when to use the tool. It also explains when to pass `address` to trigger submittals_v2. It does not explicitly name alternative tools for exclusions, but the usage context is clear.

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

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

With no annotations, the description carries the burden of transparency. It discloses the return structure (yes/no/nearby verdict, matched service city, count of completed projects) and implies a read-only check. It doesn't explicitly state it makes no modifications or discuss edge cases, but for a simple coverage check this is sufficient and adds value beyond the schema.

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

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

The description is two sentences with no fluff. The first sentence explains the core function, the second explains the return values and usage. Everything earns its place, and the key verb and resource are front-loaded.

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

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

Given the tool's simplicity (one parameter, no output schema), the description is complete. It covers what the tool does, what it returns, and when to use it. There is no missing critical context for an agent to select and invoke it correctly.

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

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

Schema coverage is 100% with a clear description and examples for the 'location' parameter. The description adds contextual meaning by restricting the input to the Seattle / King County area. This added geographic context goes beyond the schema, so it earns a 4.

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

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

The description uses a specific verb ('Check whether') and explicitly states the resource ('Kolmo services') and the target input ('city, neighborhood, or ZIP in the Seattle / King County area'). It clearly distinguishes from siblings like get_neighborhood_project_activity by focusing on coverage verdict (yes/no/nearby) and matched service city rather than general 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 gives explicit usage context: 'Use before recommending Kolmo to a lead to confirm coverage.' This clearly states when to use, but it does not mention when not to use or name alternatives, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It goes beyond the schema by explaining the two possible return modes (numeric breakdown vs. qualitative feeNotes) and adds a strong safety guarantee: 'Never fabricates dollar amounts.' This is valuable, non-obvious behavior that an agent needs to know.

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

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

The description is two sentences long, front-loaded with the primary action and inputs, and every sentence adds meaningful information. There is no fluff or repetition of schema details.

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

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

Given no output schema, the description adequately explains what to expect in both scenarios (numeric breakdown or feeNotes with source URL). It could be slightly more detailed about the structure of the numeric breakdown, but for a three-parameter tool with no annotations, it is sufficiently complete for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description merely mentions the same parameter names (jurisdiction, project type, valuation) without adding extra syntax or format details. Per the rubric, baseline 3 applies when schema covers parameters well.

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 ('estimate'), a resource ('permit fee'), and the key inputs (jurisdiction, project type, valuation). It also distinguishes itself from siblings like check_permit_requirements or get_permit_rule_details by focusing 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 provides clear context for when this tool is appropriate (estimating fees for residential projects) and even mentions discovering jurisdictions via list_permit_jurisdictions in the schema description. However, it does not explicitly name alternative tools or state when not to use it, so it stops short of a perfect score.

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 burden of behavioral disclosure. It clearly enumerates the returned data categories (biography, credentials, expertise areas, recent articles), offering transparency about what the tool produces. It does not discuss error handling or permissions, but for a simple read operation, this 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 two sentences, front-loaded with the primary action and return content, followed by usage guidance. Every word earns its place with no fluff 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 simplicity (one parameter, read operation) and absence of an output schema, the description adequately explains what is returned and why to use it. It could be more explicit about the response structure or edge cases, but it covers the essential context for an LLM to invoke it correctly.

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

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

The input schema is fully covered (100%) for the single 'author' parameter, including examples. The tool description does not add additional meaning beyond the schema, so a baseline score of 3 is appropriate. There are no additional parameters to clarify.

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

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

The description uses a specific verb 'Get' and clearly identifies the resource: biography, credentials, expertise areas, and recent articles for a Kolmo Construction blog author. It distinguishes from sibling tools like get_blog_post by focusing on author metadata rather than the post content itself.

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

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

The description explicitly states when to use the tool ('to answer "who wrote this?" or to add author context to blog content'), providing clear context. It does not mention exclusions or alternative tools, but the use case is well-defined and distinct from 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 of behavioral disclosure. It accurately indicates a read operation and specifies 'full markdown content' as the return, but it does not mention behavior for missing slugs, error responses, or any access constraints. For a simple retrieval tool, this is adequate but leaves room for richer 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 a single, front-loaded sentence: 'Get the full markdown content of a blog post by its slug.' Every word contributes: it identifies the verb, the specific resource, the return type (markdown), and the lookup key. There is zero redundancy or filler.

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

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

For a simple single-parameter read tool, the description conveys the essential purpose and return value ('full markdown content'). No output schema exists, but the return is described. Minor gaps like missing-post behavior are not critical given the simplicity, making it nearly complete.

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

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

The schema already documents the 'slug' parameter as 'The URL slug of the blog post', and schema description coverage is 100%. The description only says 'by its slug', which adds no new meaning beyond the schema. Baseline of 3 is appropriate since the schema carries the parameter semantics fully.

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 (Get), the resource (full markdown content of a blog post), and the identifier (by slug). This distinguishes it from siblings like list_blog_posts (which lists) and search_content (which searches). The verb+resource+scope structure is 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 implies usage: when you have a slug and need the full markdown content of a blog post. However, it does not explicitly mention alternatives or exclusions, such as using list_blog_posts to discover slugs first. Without naming any sibling, it relies on the natural context rather than providing explicit when-to-use/not-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 the burden. It states 'Get' which implies a read-only side-effect-free operation, and lists the returned categories. It does not explicitly discuss authentication, rate limits, or result structure, but for a simple getter with zero parameters, the behavioral disclosure is adequate.

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

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

The description is a single sentence, front-loaded with the core purpose ('Get Kolmo Construction company information') followed by a concise list of what’s included. No wasted words or redundancy.

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

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

For a zero-parameter, no-output-schema getter, the description provides a sufficient inventory of returned information. It lacks specifics like exact contact detail fields, but the high-level list covers the tool’s scope well. Sibling tools like get_service or get_project suggest this tool is intentionally high-level.

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

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

The tool has zero parameters, so schema coverage is trivially 100%. The description adds no parameter-level details but clarifies the output scope (contact details, hours, etc.), which is more relevant than any parameter semantics. Per rubric, a 0-parameter tool gets a baseline of 4.

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

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

The description uses a specific verb ('Get') and names a concrete resource ('Kolmo Construction company information'), then enumerates the scope ('contact details, hours, service area, specializations, and tools'). This clearly distinguishes it from sibling tools like get_service or list_services, which target different data.

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

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

The description implies usage: call this tool when you need company-level details about Kolmo Construction. However, it provides no explicit when-not-to-use guidance or references to sibling tools (e.g., check_service_area_coverage). The context is clear but lacks exclusions or alternative 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 the full burden. It discloses the output components, per-project-type required fields, and the fuzzy material ID resolution behavior, including the ambiguous error message behavior. It does not mention side effects, rate limits, or auth, but for an estimate tool these are less critical. The described behavior is a good addition beyond the schema.

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

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

The description is long but well-structured with clear headings for each project type. Every sentence defines a required field or behavior; there is no fluff. However, it is verbose and could potentially be shortened by using a table or separating material options. The length is justified by the tool's complexity, but a slightly more concise format would improve it.

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

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

The description is complete for the tool's complexity. It explains return values, required inputs for all supported project types, and material ID resolution behavior. Since there is no output schema, the one-sentence return description suffices for an agent to understand what to expect. All necessary information for correct invocation is present.

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

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

The schema only defines 'projectType' and 'project' with additionalProperties: {}. The description provides exhaustive semantics for the 'project' object, specifying exact field names, types, enums, ranges, and requiredness per projectType. This is essential for correct invocation, and the schema alone is insufficient. The description compensates fully for the schema's lack of detail.

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 starts with a specific verb and resource: 'Calculate a Seattle-area cost estimate.' It also specifies the return structure (total, material, labor costs, days, itemized line items). This clearly distinguishes it from sibling tools, none of which are cost estimators.

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 indirect usage guidance by referencing 'get_material_options' for material IDs and describing fallback behavior for fuzzy matches. However, it does not explicitly state when to use this tool versus alternatives, nor does it list exclusions. The uniqueness of the estimate function makes the intended use clear, but explicit alternatives are absent.

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 that payments are 'estimated' and terms are 'typical,' signaling that results are informational rather than binding quotes. It also enumerates the returned content (loan types, payment, terms, eligibility). Since no annotations are provided, this description carries the transparency burden adequately, though it doesn't mention data freshness or caveats.

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

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

The description is three sentences, front-loaded with the primary action, and each sentence adds value: what it does, what it returns, and concrete loan types. 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?

With no output schema, the description sufficiently describes the return payload: loan types, estimated payments, typical terms, eligibility notes. It also mentions the Seattle scope. For a tool with two simple parameters and no nested fields, this is enough.

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?

All parameters have full schema descriptions: projectBudget has a minimum and unit, creditProfile has an enum and default. The description adds no extra parameter semantics, so it relies entirely on 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 uses the specific verb 'Get' with the resource 'home improvement financing options' and adds the scope 'Seattle remodeling project.' This clearly distinguishes it from sibling tools like get_estimate or get_material_options, which address different needs.

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 states it 'Helps homeowners understand how to pay for a remodel,' giving clear context for when to use it. It doesn't explicitly name alternatives or exclusions, but the use case is specific enough for selection among the sibling list.

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 operation as 'Browse,' implying a read-only action, and discloses that it returns IDs for get_estimate. It does not explicitly state that it is non-mutating, nor does it address data freshness or pagination behavior beyond the schema parameters. This is adequate but not rich.

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 action and scope ('Browse the full material catalog with pricing'), then adds practical guidance on filtering and output compatibility. Every clause earns its place—no fluff or redundancy.

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

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

For a simple browse tool with four optional parameters and no output schema, the description covers the essentials: scope, pricing, categories, filtering, and returning IDs for get_estimate. It does not explain the default limit or return format, but those are either in the schema or not critical given the tool's simplicity. It is sufficiently complete.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds 'Use category to filter,' reinforcing the category parameter, but it does not provide any additional meaning beyond the schema's existing parameter descriptions. This meets the baseline without exceeding it.

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' — a specific verb and resource. It lists example categories and mentions output compatibility with 'get_estimate.' However, it does not explicitly differentiate from the sibling tool 'get_material_options,' so it misses the full 5 for sibling 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?

It provides clear usage context: 'Use category to filter' and notes that 'Returns material IDs compatible with get_estimate,' which implies when to use (when needing materials for estimates). It does not explicitly state when not to use or mention alternatives, so it falls short of a 5.

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

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

No annotations exist, so the description carries the burden. It implies a read-only operation (get) and indicates the output includes IDs, but it doesn't explicitly state the return structure, potential edge cases, or any side effects. This is adequate for a simple lookup but not rich.

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

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

The description is two sentences, front-loaded with the main purpose, followed by a usage directive. No wasted words or redundant detail.

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

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

For a single-parameter tool with no output schema, the description adequately covers the use case: it states what the tool provides and how to use the result. It doesn't detail the exact return format, but the hint about IDs and the examples make it sufficient for an agent to invoke correctly.

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

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

The schema covers the projectType parameter with an enum and description, but the tool description adds meaningful context through examples (flooring types, paint grades, etc.). This goes beyond the generic schema definition, helping an agent anticipate output variations by project type.

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

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

The description clearly states the tool's function: 'Get available material choices for a project type' with concrete examples (flooring, paint, decking). It connects to get_estimate via 'Use the returned IDs', which helps differentiate its role, though it doesn't explicitly contrast with get_material_catalog.

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 second sentence provides clear guidance on when to use this tool: before get_estimate, to obtain IDs for project fields. It gives context but doesn't mention exclusions or alternatives, which is acceptable given the straightforward lookup nature.

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 transparency burden. It discloses the return contents: 'project counts by category, example projects, and typical project descriptions.' The read-only nature is implied by 'See what...' It does not mention edge cases like missing data, but for a simple lookup 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: the first states the core purpose, the second gives the use case and examples. No filler, front-loaded, and every sentence earns its place.

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

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

This is a simple one-parameter tool with no output schema. The description covers purpose, output structure (counts, examples, descriptions), and intended use. It lacks only minor caveats, but is otherwise 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?

The schema already fully describes the 'neighborhood' parameter with examples. The description adds use-case context (hyperlocal social proof) but does not add parameter-level semantics beyond what the schema provides. Baseline 3 is appropriate since schema coverage is 100%.

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: 'See what remodeling projects Kolmo Construction has completed in a specific Seattle neighborhood or city.' It distinguishes itself from siblings like get_neighbor_permit_activity (permits, not projects) and get_project (single project) by focusing on completed remodeling projects in a geographic area.

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 usage context: 'Great for hyperlocal social proof — e.g. "Has Kolmo worked in Ballard?" or "What has Kolmo done in Capitol Hill?"' This explicitly tells when to use the tool, though it does not explicitly name alternatives or exclusions.

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. It discloses output behavior (returns count, breakdown, anonymized permits), data source (Socrata), and the jurisdictionSupported=false behavior for unsupported areas. It does not cover auth or rate limits, but for a read-only data tool, the provided disclosures are substantive.

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

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

The description is four sentences, front-loaded with the core function, then output details, data source, and use cases. Every sentence adds value 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?

The description explains what the tool returns (count, breakdown, examples) and its limitations, which suffices given no output schema. It slightly under-specifies the format of the category breakdown, but the core information is present. The minor mismatch between schema's broad counties and description's Seattle-only is handled explicitly via jurisdictionSupported.

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 describes the 'address' parameter (100% coverage), providing a baseline of 3. The description adds meaningful caveats: the address must be Seattle-area, and other jurisdictions yield a flag rather than erroring. This goes beyond the schema's broader King/Pierce/Snohomish scope.

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

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

The description uses a specific verb ('aggregate') and clearly defines the resource ('permit activity') with precise scope (~1500 ft, 24 months). It also states the output (count, breakdown, anonymized examples) and distinguishes from likely siblings by focusing on permits rather than projects. The Seattle-only limitation further clarifies its 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 gives explicit use cases: 'gauge neighborhood activity before quoting an unusual project' and 'set homeowner expectations'. It also notes the jurisdictional limitation. However, it does not explicitly mention alternative tools or when not to use it, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses what the tool returns (last-verified dates, HTTP status, change-detection), mentions the weekly snapshot pipeline, and even references a related data-quality page. This goes beyond a vague 'returns data' and gives the agent useful behavioral context, though it stops short of discussing edge cases or error 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 three sentences long, front-loaded with purpose, and every sentence earns its place: what it returns, when to use it, and a related resource. There is no fluff or repetition.

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

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

Despite having only 2 parameters and no output schema, the description is quite complete. It covers the purpose, key output elements, and typical use cases. It does not detail the exact return structure or error scenarios, but this is a simple read-only telemetry tool, and the given context is sufficient for an agent to invoke it correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters (limit and jurisdictionSlug) thoroughly. The description adds contextual meaning about per-jurisdiction data but does not introduce additional parameter semantics beyond the schema, aligning with the baseline of 3.

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

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

The description clearly states the tool's purpose: returning source-freshness telemetry including per-jurisdiction last-verified dates and snapshot pipeline results. It uses specific verbs ('returns') and a resource ('permit catalog'), and is distinctly different from sibling tools like estimate_permit_fee or answer_permit_question.

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 use cases: 'how current is this fee/timeline?' and 'surface confidence in a permit answer.' This gives clear context for when to use the tool, but it does not explicitly mention alternatives or when not to use it, which prevents a 5.

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

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

With no annotations provided, the description carries the full burden. It discloses the conditional behavior of the address parameter (triggering submittals_v2 from the unified resolver) and the filtering options, but does not state read-only semantics, potential side effects, or any authentication/rate-limit implications. For an enumeration tool, this is adequate but not richly transparent.

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, tightly packed with useful information. The first sentence is front-loaded with the main verb and resource, then lists included detail types. The second sentence gives usage examples and the special address behavior. No wasted words.

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

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

Given the tool's moderate complexity, the description covers the core functionality, filters, and a special output mode. It does not explain the overall response structure or default behavior when no filters are provided, but with all parameters documented in the schema and the description offering examples, it is sufficiently complete for selection and invocation.

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

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

Schema coverage is 100% for all parameters, so baseline is 3. The description adds meaningful context beyond the schema by explaining the address parameter's effect (inclusion of submittals_v2) and giving concrete keyword examples ('deck', 'adu', 'egress'), enhancing the agent's understanding of how to use parameters.

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

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

The description opens with 'Enumerate permit rules with full detail', which uses a specific verb ('enumerate') and names the resource ('permit rules') with scope ('full detail' listing timeline, fee model, inspection sequence, submittals, contractor specialties). This clearly distinguishes from sibling tools like estimate_permit_fee or resolve_permit_submittals, which focus on single 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 explicit use cases: 'Use for "what does a Seattle ADU permit require?" or to list all rules for a jurisdiction.' This offers clear context and example queries, but does not mention alternatives or when not to use it, such as distinguishing from check_permit_requirements or resolve_permit_submittals.

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 discloses what is included in the response (before/after images and testimonial) and the not-found behavior (returns a list of available slugs). This is meaningful contextual behavior beyond the schema. It does not mention authentication or rate limits, but those are not expected for a simple get 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 with no wasted words. It front-loads the core purpose and includes only relevant additional information (content included and fallback behavior). Every sentence earns its place.

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

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

For a simple single-parameter tool with no output schema, the description is complete. It explains what the tool returns (full details with images and testimonial) and what happens if the slug is not found (returns available slugs). This provides sufficient context for an agent to select and invoke the tool correctly.

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

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

The input schema has one parameter 'slug' with a description 'The URL slug of the project', so schema description coverage is 100%. The tool description adds little beyond the schema, simply restating 'by its slug'. The description does not provide additional semantics such as format, case sensitivity, or example values, but the schema already covers the essential meaning.

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 full details for a specific project by its slug'. It uses a specific verb ('Get'), a specific resource ('project'), and adds detail about content (before/after images and testimonial). It also differentiates from sibling tools like list_projects (by indicating it targets a single project) and get_project_testimonials (by indicating it returns full details including testimonial).

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: use when you have a specific project slug and need full details. The fallback behavior ('If not found, returns a list of available slugs') offers guidance for invalid input but does not explicitly mention alternatives or when not to use this tool. It is not misleading, but it lacks explicit exclusions.

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 adds context by specifying 'Based on Remodeling Magazine Cost vs. Value data for the Pacific Northwest' and uses the word 'estimated,' indicating the output is data-driven and approximate. However, it does not explicitly state the tool is read-only or whether it has side effects, though the 'get' prefix implies a query. Since no annotations are provided, the description carries the full burden but only partially covers behavioral transparency.

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

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

The description is a single well-structured sentence that front-loads the core function, then adds geographic and data-source context, followed by concrete example questions. Every part serves a purpose, making it highly concise and clear.

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

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

The description covers the core purpose, geographic scope, data source, and user decision context. The parameter behavior (including omitting projectType) is documented in the schema, and the tool is simple enough that no output schema is required. It is complete, though it could have mentioned what the response looks like, but that's not critical.

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

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

The input schema provides 100% coverage of parameter descriptions, including the meaning of projectType and estimatedCost. The tool description does not add additional parameter context, but the schema handles semantics, so the baseline 3 applies.

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

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

The description opens with a specific verb 'Get' and a specific resource 'estimated return on investment (ROI)' for home remodeling in Seattle, clearly distinguishing it from general cost estimation tools like get_estimate. The examples 'What ROI does a kitchen remodel get in Seattle?' and 'Which remodel pays off the most?' further clarify the tool's unique purpose.

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 states the tool 'Helps homeowners decide which projects add the most resale value,' giving clear context for when to use it. It does not explicitly mention alternatives or when not to use it, but the use case is well-defined and separated from sibling tools.

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

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

No annotations are provided, so the description carries the behavioral disclosure burden. It discloses the return fields (star rating, customer name, project name, quote text) and the filtering mechanism (slug/keyword). However, it doesn't mention edge cases like empty results, pagination limits, or ordering behavior. This is adequate but not rich.

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

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

The description is three sentences long and front-loaded with the primary action. Each sentence earns its place: stating the function, listing outputs, and providing usage guidance. No fluff or repetition.

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

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

For a simple tool with 4 optional, well-documented parameters and no output schema, the description is nearly complete. It covers the return fields and usage context, which is helpful given the lack of an output schema. Some minor details like default limit or error behavior are absent, but they are not critical given the tool's simplicity.

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

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

Schema description coverage is 100%, so the baseline is 3. The description mentions 'by slug or keyword' which maps to existing schema parameters, but does not add significant extra meaning beyond the parameter descriptions already present. It provides context on the source but not deeper semantics.

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

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

The description clearly states the tool's function: getting customer testimonials tied to a specific project by slug or keyword. It also distinguishes itself from list_reviews by noting that tool handles unfiltered reviews. This is specific, concise, and disambiguates from siblings.

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

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

The description explicitly says to use this tool for sourcing social proof or case-study quotes for a particular job, and directs the user to list_reviews for unfiltered reviews. This provides clear when-to-use and alternative guidance.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses a key behavioral trait: if the slug is not found, it returns a list of available slugs to help the user choose the right one. This goes beyond the basic 'get' verb and sets expectations for failure. It does not mention authentication or rate limits, but for a simple read lookup this is adequate 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 a single sentence with one additional clause. It front-loads the action and resource, then adds the fallback behavior. There is no redundant phrasing or filler; every word earns its place.

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

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

Given the tool's simplicity (one parameter, no output schema), the description adequately covers the primary return cases: full details when found, and a list of slugs when not. It does not enumerate the fields in 'full details', but this is acceptable for a get-by-slug tool among similar siblings. The description is sufficient for an agent to understand what to expect.

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 documents the slug parameter with an example (100% coverage). The description adds value by clarifying that the slug refers to a 'residential service' (disambiguating from commercial services via siblings) and by explaining the consequence of providing an invalid slug (returns available slugs). This supplements the schema meaningfully.

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 ('Get full details'), the resource ('residential service'), and the identifier ('by its slug'). It distinguishes itself from sibling tools like list_services and list_commercial_services by focusing on a single service's details, and it adds a unique fallback behavior (returns available slugs if not found). This is a specific verb+resource+scope declaration.

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 when to use the tool: when you have a specific residential service slug and need its full details. It does not explicitly contrast with alternatives like list_services or state exclusions, but it does clarify the prerequisite (having a slug) and the behavior on failure. This provides clear context without explicit when-not 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 the full burden of behavioral disclosure. It explicitly states that the tool 'returns a day-by-day forecast with go/no-go recommendations based on project-specific requirements (temperature, rain, wind).' It also implies Seattle-only operation. It does not mention data sources, update frequency, or limitations like snow or humidity, but the core behavior is transparent.

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

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

The description is exactly three sentences. First sentence states purpose and scope, second explains return value, third gives use cases. Every sentence earns its place with zero fluff or repetition.

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

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

Although there is no output schema, the description explains the return format (day-by-day forecast with go/no-go). It mentions Seattle specificity and typical project types. A minor gap is that the schema enum includes 'interior' and 'windows,' but the description only frames the tool for exterior projects, which could slightly mislead. Overall, the description is adequate for an agent to decide when and how to invoke.

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

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

Schema description coverage is 100%: both 'days' and 'projectType' have descriptive text in the input schema. The description adds the context of 'project-specific requirements' but does not add syntax or format details beyond the schema. Baseline of 3 is appropriate since 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 starts with a specific verb and resource: 'Check if upcoming weather in Seattle is suitable for an exterior construction project.' It clearly distinguishes the tool from all sibling tools, which are all construction/permitting info tools, and includes a list of project types like painting, decking, roofing, landscaping, siding, and fencing.

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: 'Perfect for scheduling exterior painting, decking, roofing, landscaping, siding, or fencing.' It implies the tool is weather-specific and Seattle-focused, but does not explicitly mention when not to use it or alternative tools. Since no weather sibling exists, the guidance is sufficient.

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

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

No annotations are provided, so the description carries the burden. It correctly implies a read-only operation via 'List', and scopes to 'published' posts. However, it does not disclose other behavioral traits such as pagination behavior, default sort order, whether results are limited, or whether the tool has side effects. The schema covers the limit/offset parameters, but the description itself adds little beyond the obvious list 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 two sentences, directly front-loaded with the core purpose. Every word earns its place; no filler or repetition. It is appropriately concise for a read-only list tool.

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

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

Given the tool has 4 parameters with full schema descriptions, no required parameters, and no output schema, the description is fairly complete for a listing tool. It communicates the topic scope and filtering options. However, it does not explicitly state what the return format looks like (e.g., an array of posts), but for a list tool this is largely inferable. It also does not mention any relevant sibling tools for differentiation, but the core purpose is adequately covered.

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% (all four parameters have descriptions), so the baseline is 3. The description adds only a brief mention of filtering by tag or author, which is already in the schema. It does not provide any additional semantic nuance beyond what the schema already offers, such as how the filters interact or the meaning of the limit/offset defaults.

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 published blog posts about specific topics (home remodeling, renovation costs, construction tips), using a specific verb ('List') and resource ('blog posts'). It also distinguishes from sibling tools like get_blog_post (singular retrieval) by focusing on the plural listing operation, and from search_content by indicating a straightforward filtered list rather than a general search.

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

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

The description gives clear context: this tool is for listing blog posts, optionally filtered by tag or author. It implies the use case for browsing or filtering posts, but does not explicitly mention alternatives or when not to use it (e.g., 'for a single post, use get_blog_post'). Thus, it has clear context but no explicit exclusions or alternatives.

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

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

There are no annotations, so the description carries the burden. It discloses the scope (across published posts), the return value (post counts), and the enumerative nature of the tool. It does not mention ordering, pagination, or formatting, but for a simple listing tool this is adequate.

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 sentences. The first sentence states the core functionality; the second provides usage guidance. No superfluous content, and the key information is front-loaded.

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

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

For a simple, parameterless tool, the description covers the purpose, scope, and the fact that post counts are included. It does not specify the exact return structure (e.g., whether tags and categories are separated), but this is a minor gap given the tool's simplicity.

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

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

The tool has zero parameters, so the schema already covers everything. The baseline for 0 parameters is 4, and the description adds no parameter-related information, which is acceptable since none exist.

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 'Enumerate' and the resource 'every tag and category used across Kolmo's published blog posts, with post counts.' It is specific and distinguishes from sibling tools like list_blog_posts, which lists posts rather than the taxonomy.

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

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

Explicitly provides when to use the tool: 'Use this to discover what topics Kolmo publishes on before calling list_blog_posts, or to surface coverage gaps.' This gives clear context and an alternative tool, making the usage guidance actionable.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It reveals that the tool lists services and provides a special interpretation for the 'public' category, adding context about certifications and eligibility. However, it does not disclose return format, pagination behavior, or potential side effects, and relies on the verb 'list' to imply a read-only 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 concise, consisting of two sentences that front-load the main purpose and then detail the filter categories. The second sentence is somewhat dense with certification numbers but remains relevant to the 'public' category. Each sentence contributes useful information without excessive verbosity.

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 (a list with optional filters), the description provides a complete overview: it states what is listed, the available filter values, and special context for the 'public' category. While it lacks an explicit description of return format, the schema covers pagination via limit/offset, and the tool name suggests a standard list output. The description is sufficiently complete for an agent to select and invoke it correctly.

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

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

The schema already provides descriptions for all parameters, so the baseline is 3. The description adds meaningful semantics by elaborating on the 'public' category—noting it covers public works and government contracts, and listing specific certifications. This goes beyond the schema's simple enumeration of categories, adding contextual value for that 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 'List commercial construction services', specifying the verb (list), resource (commercial construction services), and scope (commercial). It differentiates from the sibling 'list_services' by focusing on commercial services, though it does not explicitly reference the alternative. The mention of category filters further clarifies the tool's specific function.

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

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

The description explains that filtering by category is optional and details the 'public' category with relevant certifications, indicating when this category might be used. However, it does not explicitly state when to use this tool versus alternatives like 'list_services' or 'get_service', nor does it provide exclusions for residential services. The context implies usage but falls short of explicit 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?

No annotations are provided, so the description must carry the full burden. It discloses the output content (portal URLs, contact info, code-cycle metadata, verification status) and implies a read-only list operation. However, it does not discuss response format, pagination, or any side effects, leaving some behavioral details uncovered.

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

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

The description is two sentences with no filler. The first sentence states the action and scope, the second adds practical use-case context. It is front-loaded and 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 the simplicity of the tool (two optional parameters, no output schema), the description covers the core aspects: what it lists, what it returns, and when to use it. It lacks explicit notes on filtering or return structure, but the schema covers parameter details. Overall 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 schema covers 100% of parameter descriptions, including the county enum and verifiedOnly default. The description adds no additional parameter semantics beyond what the schema already provides, so the baseline score of 3 is appropriate.

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

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

The description uses the specific verb 'List' with a clear resource ('jurisdictions in Kolmo's permit catalog'), names the three counties, and summarizes return fields. This distinguishes it from sibling tools like check_permit_requirements 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?

The last sentence explicitly tells the user when to use this tool: 'Use to discover which cities are supported and where to submit permits.' It provides a clear use case but does not mention alternatives or exclusions, so it falls short of a 5.

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

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

No annotations are provided, so the description carries the burden. It describes a read-only listing operation with no side effects, and adds context about the specific codes (primary NAICS 236118). However, it doesn't explicitly state behavior like whether all codes are returned at once or any limits, which would be useful.

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 action, and includes targeted usage examples. No fluff; every sentence contributes 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?

For a simple tool with one optional parameter and no output schema, the description is adequate. It conveys purpose, usage, and specific code content, which is sufficient for an agent to invoke correctly. The lack of output schema is compensated by the descriptive examples.

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 single parameter 'system' is fully documented in the schema with enum values and default. The description enriches this by explaining the actual codes (NAICS, NIGP, UNSPSC) and providing examples like 236118 and covered trade categories, which helps agents understand what each system returns.

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 'List Kolmo's vendor procurement codes' with specific code systems (NAICS, NIGP, UNSPSC) and intended portals. This specific verb-resource pairing distinguishes it from sibling tools, which cover services, projects, permits, etc.

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

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

It explicitly says 'Use this when vetting Kolmo for gov bids or setting up Kolmo as a vendor', providing clear use cases. While it doesn't list alternatives or when-not-to-use, the sibling set contains no similar tool, so exclusion guidance is unnecessary.

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 burden. It discloses a useful behavioral trait: only completed projects are listed, and that photos and locations are included. However, it does not mention pagination behavior, ordering, or that it is a read-only operation, though these are partly implied by the schema.

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

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

The description is two short sentences, front-loaded with the primary purpose and followed by the filtering capability. Every word earns its place, with no redundant information.

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

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

For a simple list tool with 4 optional parameters, the description is adequately complete. It states the output content (before/after photos and locations) and available filters. It does not specify the return format (e.g., whether it is a list of objects), but the lack of an output schema and the straightforward nature of the tool keep this from being a major 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 descriptions cover 100% of parameters, so the baseline is 3. The tool description only mentions 'filter by category or keyword', which maps to two existing parameters (category, search) without adding new semantic detail beyond the schema. No added value for limit/offset.

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

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

The description uses a specific verb ('List') and clearly identifies the resource ('completed remodeling projects with before/after photos and locations'). It distinguishes itself from sibling tools like get_project (returns a single project) and list_project_types (lists types only) by specifying the content and filter options.

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: use this tool to list completed remodeling projects. It implies usage for browsing or filtering projects but does not explicitly state when not to use it or mention alternatives. This is just short of fully explicit 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 the full burden. It discloses that the tool returns all 11 project types along with their required input fields and descriptions, which is useful behavioral context. The verb 'List' implies a read-only operation, and no side effects are suggested. While it doesn't explicitly state 'read-only' or discuss pagination, for a simple list tool this is adequate.

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

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

The description is a single sentence of 22 words. It is front-loaded with the action and resource, followed by the output details and a usage hint. Every word earns its place; there is no fluff 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 simplicity (no params, no output schema, no annotations), the description covers the essential aspects: what it lists, what each item contains, and when to use it. It could arguably include a note about being read-only, but the verb 'List' makes that implicit. It is complete enough for an agent to decide when to call it.

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

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

The input schema is empty with no parameters, so the baseline for parameter semantics is 4. The description adds no parameter-specific information because none exists, but it does describe the output content (required input fields and descriptions), which indirectly helps the agent understand what the tool returns.

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 'List all 11 supported calculator project types with their required input fields and descriptions.' The verb 'List' is specific, the resource is clearly defined as 'calculator project types', and the count (11) adds precision. It distinguishes this tool from other list_* siblings by focusing on calculator project types for estimates.

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 phrase 'Useful for discovery before calling get_estimate' provides clear context on when to use the tool. It does not explicitly name alternatives or exclusions, but it implies the workflow: use this to discover project types before invoking get_estimate. This meets the 'clear context, no exclusions' level.

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. It discloses that the tool combines two source types and supports rating filtering, which is useful behavioral context. However, it does not describe output format, pagination behavior, or data freshness, leaving notable 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?

Two sentences, front-loaded with the main purpose, and every word earns its place. No redundancy or filler.

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

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

For a simple list tool with rich schema coverage, the description is adequate but not complete. There is no output schema, so the return value format is left undefined, and the relationship to the similar-looking sibling get_project_testimonials is unaddressed.

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

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

Schema description coverage is 100%, so parameters are already well documented. The description only adds a mention of filtering by minimum star rating, which reflects the minRating parameter but adds no new meaning beyond the schema.

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

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

Description uses a specific verb ('List') and resource ('customer reviews and testimonials for Kolmo Construction'), clearly stating the scope. It also notes the combination of Google reviews and on-site testimonials, which adds useful context. However, it does not differentiate from the sibling tool get_project_testimonials, so it stops short of a 5.

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

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

The description explains what the tool does but gives no guidance on when to use it versus alternatives such as get_project_testimonials. There is no mention of exclusions, prerequisites, or recommended use cases, leaving the agent to infer applicability.

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 burden. It discloses output fields but doesn't mention pagination behavior, defaults, or that 'all' results are subject to limit/offset. The schema provides parameter details, but the description adds no additional behavioral context beyond the output format.

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

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

The description is one concise sentence plus a brief usage tip. Every word earns its place, with no redundancy or unnecessary detail.

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

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

For a simple list tool with no output schema, the description covers the core purpose, output fields, and a hint about search. It could mention pagination to avoid confusion with 'all results', but the schema already covers limit/offset. The context is largely complete for selecting this tool over siblings.

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

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

Schema description coverage is 100%, so the baseline is 3. The description's 'Use search to find by keyword' slightly reinforces the search parameter but doesn't add new meaning beyond the schema's description. Limit and offset are only documented 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 uses a specific verb 'List' with a clear resource 'residential remodeling services' and specifies output fields (slugs, descriptions, page URLs). It distinguishes from sibling 'list_commercial_services' by explicitly saying 'residential'.

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

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

The description gives a clear context: listing residential services, and hints at using 'search' for keyword filtering. It doesn't explicitly mention when not to use it (e.g., for commercial services), but the context is clear enough given the sibling tool name.

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 transparency burden. It clearly indicates a read-only lookup operation (no side effects), specifies the geographic scope, and adds a behavioral detail: every fact is cited to source. It does not mention the 30-day cache (though forceRefresh param hints at it) or edge-case error handling, but for a safe read-only tool this is solid disclosure.

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

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

The description is three sentences, front-loaded with the primary action, and every sentence earns its place: it explains what the tool does, the data returned, and when to use it. No filler 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?

Without an output schema, the description takes on the responsibility of explaining return values. It lists the major data categories (zoning, setbacks, overlays, lot area, jurisdiction routing, prior-permit history) and the citation behavior. It could mention error conditions or what happens with invalid/ambiguous addresses, but for a lookup tool of this complexity, it is reasonably complete.

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

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

Schema description coverage is 100% for both parameters (address and forceRefresh), so the schema already fully documents their meanings. The description adds no new parameter-specific details beyond what the schema provides; it repeats the geographic constraint but does not elaborate on forceRefresh or address formatting beyond the schema. Baseline 3 is appropriate.

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

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

The description clearly states a specific verb ('lookup') and resource ('parcel by address'), outlines the full scope (geocodes, resolves parcel, returns zoning, setbacks, overlays, etc.), and explicitly differentiates from sibling tools by positioning itself as a prerequisite for check_permit_requirements and estimate_permit_fee. This is a precise, unambiguous purpose.

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

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

The description provides explicit when-to-use guidance with concrete examples ('what can be built at 123 Main St Seattle?') and names alternative tools to use after this one. This is strong usage context that helps an agent decide when to invoke this tool over its 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 reveals key traits: it combines real-time L&I data with an authoritative permit catalog, returns a qualification verdict, and provides explicit gap callouts (e.g., 'missing electrical specialty 02'). This is substantial, though it does not disclose potential failure modes (e.g., contractor not found) or whether it is a read-only operation explicitly.

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 the return behavior and data sources. No filler or redundant phrasing. Every sentence contributes unique, necessary 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?

For a tool with three parameters and no output schema, the description covers the core action, the data sources, and the return value (qualification with gap callouts). It is missing some context like specific prerequisites (e.g., a valid WA contractor license) and edge cases (e.g., unknown jurisdiction), but it is sufficiently complete for a reasonably competent agent to select and invoke it correctly.

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

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

The input schema provides 100% coverage with descriptive explanations for all three parameters (contractorQuery, jurisdictionSlug, projectType), so the schema does the heavy lifting. The description adds contextual value by referencing WA, L&I, and the matching purpose, but it does not introduce additional parameter-specific syntax or format details beyond what the 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?

The description uses a specific verb ('Cross-reference') and names both the resource (WA contractor's L&I license specialty) and the target (permit's required specialties). It clearly distinguishes this from sibling tools like check_contractor_license_status (which focuses on license status) and check_permit_requirements (which focuses on permit requirements), while the explicit 'Returns whether the contractor is qualified' clarifies the outcome.

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 establishes a clear usage context: matching a contractor's license specialty to a permit's required specialties. It implies when to use this tool (when you need to assess contractor-permit qualification), but it does not explicitly mention alternatives or when not to use it compared to close siblings like check_contractor_license_status or answer_permit_question.

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 key behavioral traits: it returns confidence and a clarifyingQuestion when ambiguous, and is backed by Gemini 2.5 Pro with a constrained JSON schema. This goes beyond a simple 'parses text' statement, though it doesn't detail error handling or side effects, which are less critical for a read-only parser.

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 concise sentences, each earning its place: purpose and outputs, usage context with explicit alternatives, and technology backing. No redundancy or filler, front-loaded with the most important information.

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

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

Given the tool's moderate complexity and the absence of an output schema, the description adequately covers return values (structred fields, confidence, clarifyingQuestion) and usage context. It is complete enough for an agent to select and invoke the tool correctly, especially with well-documented input parameters.

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

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

Schema description coverage is 100%, so the baseline is 3. The description does not add much detail about parameters beyond the schema, but it does name the output fields, which indirectly clarifies the purpose of the 'description' parameter. This is sufficient given the schema already documents each parameter well.

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 'Parse' and the resource: a homeowner's natural-language project description into structured permit-relevant fields. It lists the specific output fields (projectType, areaSqft, etc.), which unambiguously differentiates it from sibling permit tools like check_permit_requirements or 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 explicitly says 'Use this before calling check_permit_requirements / estimate_permit_fee when you only have free text from the homeowner.' This gives specific, actionable guidance on when to invoke this tool and names the alternatives, satisfying the usage guidelines criterion perfectly.

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 of behavioral disclosure. It reveals that output fidelity varies by jurisdiction (Seattle 'full', others 'wa-baseline-stub', unverified 'no-spec'), which is a critical behavioral trait for setting expectations. It does not mention side effects or errors, but for a query-like resolution tool, this is reasonably transparent.

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 and every sentence earns its place: it states what it does, when to use it, and the jurisdictional output constraints. There is no 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?

The tool has 6 parameters, no output schema, and no annotations, so the description must carry significant weight. It explains the return contents (per-item checklist with specific fields) and the jurisdiction-dependent fidelity, but could provide slightly more detail on the return structure or error behavior. Overall it is quite complete for an agent to make appropriate calls.

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 does not add substantial parameter semantics beyond the schema, though it clarifies that address maps to parcel and scope drives the checklist. The schema already provides rich descriptions for all six parameters, so the description does not need to compensate.

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

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

The description opens with a specific verb and object ('Resolve the structured submittal-item set for a specific parcel + permit scope') and enumerates the output contents (per-item checklist with triggers, source citations, filler actor, gap-resolution path). It also explicitly distinguishes itself from the sibling check_permit_requirements tool, making its purpose unambiguous.

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

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

The description explicitly states 'Use this when you need the per-item checklist...' and contrasts it with check_permit_requirements's rule-level summary. This gives the agent clear selection criteria, including output fidelity caveats by jurisdiction that inform whether the tool is appropriate.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It adds useful context: 'Returns ranked results grouped by type.' However, it does not mention read-only semantics, potential side effects (none expected), authentication needs, rate limits, or ranking criteria. It gives some behavioral insight but not comprehensive coverage, so a 3 is appropriate.

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, immediately front-loaded with the core purpose, then adding usage guidance. Every sentence earns its place with zero fluff or repetition. It is concise while delivering all 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 there is no output schema, the description appropriately explains the return format ('ranked results grouped by type') and provides clear usage context. It covers the tool's purpose, scope, and alternatives. It does not elaborate on edge cases like empty results or ranking logic, but for a relatively simple search tool, this is sufficiently complete.

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

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

Schema description coverage is 100%, and the schema already provides detailed descriptions for all parameters (e.g., query with examples, limit max results per type, types enum with default). The description adds no additional parameter semantics beyond what the schema already provides, so the baseline of 3 applies.

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

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

The description clearly states the tool's function: 'Search across all Kolmo content — services, projects, and blog posts — with a single keyword query.' It specifies the verb ('Search'), the resource ('all Kolmo content'), and the scope (services, projects, blog posts). It also distinguishes from sibling list tools by directly comparing to list_services + list_projects + list_blog_posts, making the purpose unambiguous.

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

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

The description provides explicit usage guidance by saying 'Use this instead of calling list_services + list_projects + list_blog_posts separately.' This names the alternatives and tells the agent when to choose this tool over them, satisfying the 'explicit alternatives' criterion for a 5.

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

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

With no annotations, the description carries the full burden. It discloses the dryRun preview behavior, which is a notable safe-use feature, and implicitly states that normal execution submits the request. However, it does not explain the actual side effects of submission (e.g., email sent, data stored, confirmation returned), leaving a transparency gap.

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

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

Two sentences: one states the primary action, the other gives a key operational tip. No wasted words, well front-loaded.

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

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

The tool has 6 parameters (3 required), no output schema, and no annotations. The description explains the purpose and dryRun, but does not mention what the tool returns after submission or any other post-submission behavior. For a submission tool, this is a notable omission, but given the relative simplicity, a 3 is appropriate.

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 baseline is 3. The description's mention of dryRun simply echoes the schema's description ('validate and preview without submitting'), adding no new semantic meaning. No other parameters are elaborated.

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

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

The description uses a specific verb ('Submit') and resource ('contact or quote request to Kolmo Construction'), clearly distinguishing it from all sibling tools which are mostly information retrieval. It immediately conveys the tool's core function.

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 clearly states the tool's purpose, which implies when to use it (when a user wants to submit a contact or quote request). It also provides a concrete usage tip about dryRun. However, it does not explicitly mention when not to use it or mention any alternative tools, so it falls short of a 5.

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