Kolmo Construction

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It transparently explains the internal process (looks up parcel, pulls jurisdiction rules, neighbor activity, municipal code), the return behavior (cited answer), and a clear limitation/fallback: 'NEVER fabricates fees or thresholds — falls back to "I don't have that on file" when data is missing.' This is exemplary transparency.

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

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

The description is three sentences, front-loaded with the primary purpose, and includes examples and a critical safety constraint. Every sentence adds value; there is no wasted text.

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

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

Given no output schema and no annotations, the description provides a complete picture: what the tool does, how it works at a high level, what outputs to expect ('cited answer'), failure behavior, and example questions. It is sufficient for an AI agent to select and invoke the tool correctly for address-specific permit questions.

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 both 'address' and 'question' already well-described in the input schema. The description adds usage examples and reinforces the Seattle-area scope, but does not add significant semantic detail beyond what the schema provides. 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 opens with 'Grounded permit Q&A for a specific Seattle-area address', clearly identifying the verb (answer) and resource (permit questions). It further distinguishes from siblings by emphasizing natural-language questions and giving concrete examples like 'do I need a permit for a 6 ft fence at 123 Main St?' This is specific and non-tautological.

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 for natural-language permit questions like...' providing clear usage context. It does not mention when not to use the tool or point to alternatives such as check_permit_requirements or estimate_permit_fee, but the examples and scope make the intended use unambiguous.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses the data source (public L&I data) and update frequency (daily), implying a read-only, safe operation. It does not detail rate limits or error handling, but for a straightforward 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?

Two sentences, front-loaded with the core action and scope, no redundant words. The additional context about competing contractors and the use case is valuable and concise.

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 provides essential details: what it does, data source, update frequency, and intended use. It implies the return will indicate licensing, bonding, and insurance status, but does not specify the exact output structure. This is a minor gap for a simple lookup tool.

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

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

The schema covers 100% of the parameter with examples ('KOLMOL*753JS' or business name). The tool description adds meaning by stating it works for any contractor, not just Kolmo, which broadens the interpretation of the query parameter.

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

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

The description clearly states the tool's function: looking up Washington State contractor license, bond, and insurance status via public L&I data. It explicitly distinguishes itself by noting it works for any contractor, including competitors, setting it apart from sibling tools that might be Kolmo-specific.

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

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

The description provides a clear use case ('Great for verifying a contractor before hiring') and clarifies that it applies to any contractor in Washington. However, it does not explicitly mention when not to use it or reference alternative tools for similar purposes.

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

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

With no annotations, the description carries the transparency burden. It honestly discloses data quality differences ('Seattle is full SDCI fidelity, other 9 verified cities are wa-baseline-stub') and the conditional behavior of returning submittals_v2 only when `address` is provided. It also notes the preference for 'jurisdiction-verified rules.' This is strong for a read-oriented tool, though it doesn't mention potential rate limits or default behavior when no location/address is supplied.

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

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

The description is moderately long (3-4 sentences) but front-loaded with the primary purpose and follows with usage examples and key behavior. Every sentence contributes meaningful information, though the data-quality caveat sentence is slightly dense. It could be tightened, but it's efficient overall.

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 7 optional parameters and no output schema, the description covers the main return contents (timeline, fees, inspections, submittals, source URL), intended use cases, and the conditional submittals_v2 behavior. However, it remains unclear what happens when neither `address` nor `location` is provided, and how jurisdiction is resolved in that default case. This is a notable gap given the county-level scope stated in the purpose.

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 100% coverage with detailed parameter descriptions, so the baseline is 3. The tool description adds value by explaining that passing `address` triggers the inclusion of the `submittals_v2` output, a behavior not obvious from the schema alone. It also reinforces the override relationship between address and location.

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 core function: 'Check whether a residential construction project in King/Pierce/Snohomish counties requires a permit.' It provides specific examples ('Do I need a permit to build a deck in Seattle?') and mentions the range of outputs (timeline, fee notes, inspection sequence, required submittals, source URL), distinguishing 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?

Explicit 'Use for' examples are given, demonstrating typical user queries. The description also clarifies when to pass `address` to receive the SubmittalSet, offering clear guidance on how to adjust usage based on need. While it doesn't explicitly state 'not for X', the examples effectively anchor intended usage and differentiate 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. It discloses the output shape (verdict, matched city, project count) and the 'nearby' concept, which goes beyond a simple verb. It doesn't discuss side effects, but the read-only nature is implied by 'Check' and the tool's purpose.

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

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

Two tight sentences: the first front-loads the action and output, the second gives the usage context. 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?

For a single-parameter tool with no output schema, the description covers the tool's purpose, input, return values, and use case. It also clarifies the geographic scope, making it sufficient for an agent to select and invoke correctly.

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

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

The schema already describes the location parameter with examples, so baseline is 3. The description adds the Seattle/King County constraint and ties the parameter to the output semantics, providing meaningful context 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 uses a specific verb ('Check') and identifies the resource ('service area coverage') with a geographic scope. It clearly distinguishes from siblings by focusing on coverage validation rather than estimates or permit lookups. The first sentence alone fully explains the tool's 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?

Provides an explicit use case: 'Use before recommending Kolmo to a lead to confirm coverage.' It does not mention alternatives or when not to use, but the context is clear and actionable. This meets the threshold for a clear usage guideline.

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

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

With no annotations, the description carries full responsibility. It discloses that results may be numeric or qualitative, includes source URLs, and explicitly states it never fabricates dollar amounts. This is valuable behavioral context beyond the schema. It does not cover all edge cases (e.g., unsupported jurisdiction), but the key behaviors are communicated.

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

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

Three sentences with no fluff. The first sentence states the purpose, the second explains output variants, and the third sets a behavioral guardrail. Every sentence earns its place and the text is front-loaded.

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

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

Given no output schema and no annotations, the description explains the two possible return formats and the never-fabricate guarantee. It covers the main scenarios but lacks detail on error handling or unsupported jurisdiction behavior. Overall, it is sufficiently complete 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?

Schema description coverage is 100%, so the baseline is 3. The description repeats parameter names but adds little meaning beyond the schema. It does provide context that the output depends on whether the jurisdiction publishes structured fee inputs or PDFs, which is indirectly linked to jurisdictionSlug, but the schema already contains examples and pointers for discovery.

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 estimates permit fees for residential projects, with specific inputs (jurisdiction, project type, valuation). It distinguishes itself from siblings like get_estimate or check_permit_requirements by focusing narrowly on permit fees and explicitly describing the dual output modes (numeric breakdown vs. qualitative feeNotes).

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 an estimate is needed) and clarifies behavior for different data sources (authoritative rules vs. PDFs). It does not explicitly name alternatives or exclusions, but the unique purpose makes it clear enough. Sibling tools are mostly unrelated, so no confusion.

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. The verb 'Get' implies a read-only operation, but the description does not disclose potential error behavior (e.g., author not found), authentication requirements, or return format. 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 long, front-loads the purpose, and adds a usage context sentence. There is no redundant or irrelevant information, making it highly concise and well-structured.

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

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

For a simple lookup tool with one parameter and no output schema, the description adequately states the return content and when to use it. It does not describe the output structure or error handling, but these are less critical for a basic get operation.

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 for the single 'author' parameter with clear examples. The description does not add further parameter semantics beyond what the schema already provides, falling to the baseline for high schema coverage.

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

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

The description clearly states the tool retrieves biography, credentials, expertise areas, and recent articles for a blog author. It uses a specific verb ('Get') and resource, and distinguishes itself from sibling tools like get_blog_post and list_blog_posts by focusing on author context.

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

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

The description explicitly says to use it to answer 'who wrote this?' or to add author context to blog content, providing clear use cases. It does not explicitly mention alternatives or when not to use it, but the context is clear enough.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It does reveal that the output is the full markdown content, which is useful. However, it does not disclose error behavior (e.g., not found), authentication requirements, or whether unpublished posts are included, leaving some gaps.

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

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

The description is a single, focused sentence that leads with the verb and resource, then specifies the input key. Every word earns its place, with no redundant or filler content.

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

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

For a simple one-parameter getter, the description tells the user exactly what to expect (full markdown content) and how to specify the post (slug). It lacks only minor edge-case details like not-found errors or publication status, but it is sufficiently complete for basic invocation.

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

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

The input schema fully describes the slug parameter with 100% coverage ("The URL slug of the blog post"). The tool description's phrase "by its slug" adds little new meaning, so the baseline score of 3 for high schema coverage 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 'Get the full markdown content of a blog post by its slug.' It uses a specific verb (Get) and resource (blog post's markdown content) and identifies the input (slug). This distinguishes it from siblings like list_blog_posts and search_content, which focus on listing or searching rather than retrieving a single post's content.

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

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

The description implies usage when you have a slug and need the full markdown content, but it does not explicitly state when to avoid this tool or mention alternatives. There is no contrast with list_blog_posts or search_content, but the slug requirement provides some contextual 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 responsibility for behavioral transparency. It communicates that this is a read-only lookup ('Get') and lists the data categories returned, but it does not disclose data freshness, response format, or possible edge cases. 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 a single, well-structured sentence. It front-loads the verb and resource, then uses a colon and list to succinctly enumerate content. 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?

For a zero-parameter info-lookup tool with no output schema, the description is complete: it clearly states the subject and the exact categories of information returned. This is sufficient for an agent to select and invoke the tool correctly, and there are no complex side effects or prerequisites to disclose.

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 provides no input expectations. The description adds meaningful context by enumerating what the returned business information will include, which fully compensates for the empty schema and helps set agent expectations.

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 ('Kolmo Construction company information') with enumerated content categories (contact details, hours, service area, specializations, tools). This distinctively separates it from sibling tools like get_author_bio or list_services.

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 company information is needed, but it provides no explicit guidance on when to choose this tool over alternatives, nor any exclusions or prerequisites. It is a clear context without direct comparison to 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 transparency burden and details return value composition, material ID fuzzy-matching ('pass a close match ... and the server will resolve it'), and error behavior ('If ambiguous, the error message lists valid options'). It also enumerates required fields per project type, but does not state side-effect-free/read-only behavior explicitly, which is expected but not disclosed.

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 opens with the tool's purpose and return values, then uses a clear header ('Required fields by projectType:') to organize a large amount of detailed parameters. While long, the structure makes it usable for an agent; no sentence is redundant, though it could be tightened.

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 still specifies high-level return components ('total, material, labor costs, days, and itemized line items') plus all input structures for eleven project types, including constraints like ranges (e.g., 'height(6-30)'). This is sufficient for an agent to correctly invoke the tool and interpret the response.

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 as a string enum and project as a generic object, with the object description explicitly deferring to the tool description. The description compensates by listing exhaustive per-projectType field requirements (e.g., 'rooms (Array<{id,name,length(ft)...}>)' for interior-painting), providing types, ranges, and enums that make the parameters actionable.

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 opening sentence 'Calculate a Seattle-area cost estimate' clearly identifies the verb and resource, and the return list ('total, material, labor costs, days, and itemized line items') specifies outputs. This distinguishes it from siblings like estimate_permit_fee and get_project_roi, which address different estimate types.

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 specifies this is for Seattle-area cost estimates and directs users to 'use get_material_options to get exact IDs' when selecting materials, providing a concrete companion tool. However, it does not explicitly contrast with alternative estimate tools or state when not to use it, though the purpose is clear enough to imply its usage.

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

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

With no annotations provided, the description carries the full transparency burden. It discloses that the tool returns estimates and eligibility notes, implying a read-only informational query, but it does not mention assumptions (e.g., estimates are not personalized quotes) or limitations (e.g., rates may vary by lender). This is adequate but not exhaustive.

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

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

The description is three concise sentences: first states the primary purpose, second details return values, third gives the practical benefit with specific loan types. No filler or redundant content.

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

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

For a simple read-only query tool, the description covers the purpose, return types, and target audience well. Without an output schema, it explains what to expect. It could mention that estimates are based on typical rates or that eligibility notes are indicative, but overall 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?

The input schema already provides thorough descriptions for both parameters (projectBudget in USD, creditProfile with enumerated categories), so the description adds no additional parameter-level detail. Baseline score of 3 is appropriate given 100% schema coverage.

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

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

The description clearly states 'Get home improvement financing options for a Seattle remodeling project' with a specific verb, resource, and geographic scope. It also enumerates the returned data (loan types, payments, terms, eligibility notes), distinguishing it from sibling tools like get_estimate or get_material_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: it is for homeowners planning a Seattle remodeling project and lists relevant loan products. However, it does not explicitly state when not to use this tool or mention alternatives, leaving some room for ambiguity.

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 disclosing behavior. 'Browse' implies a read-only operation, and the note about IDs compatible with get_estimate adds useful context. However, it does not explicitly state read-only status, permissions, pagination behavior, or any other side effects, leaving some transparency gaps.

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

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

The description is two sentences, front-loaded with the main purpose, and every part adds value. It efficiently conveys the catalog contents, filtering option, and integration with get_estimate without any unnecessary words.

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

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

Given there is no output schema, the description should explain return values. It mentions material IDs compatible with get_estimate but does not describe the full response structure, such as fields like pricing or categories. While the tool is simple with well-documented parameters, the missing output details prevent a higher score.

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

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

The schema covers 100% of the parameters with detailed descriptions, so the description does not need to add much. It does mention using category to filter, but this duplicates the schema. No additional parameter semantics are provided beyond what the schema already offers.

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 browses the full material catalog with pricing and lists specific material types, giving a clear verb and resource. However, it does not explicitly differentiate from the sibling tool 'get_material_options', so it is not fully distinguished.

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 by noting that returned material IDs are compatible with get_estimate, suggesting this tool is used to fetch materials for estimating. However, it does not explicitly mention when to use this tool versus alternatives like get_material_options, nor does it provide 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 burden of behavioral disclosure. It clearly indicates a read-only lookup ('Get') and implies the output is a set of IDs to feed into get_estimate. While it does not detail return format or limitations, the operation is transparent for a simple query tool.

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

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

The description is two sentences, front-loaded with the core purpose, followed by concrete examples and a direct usage instruction. Every word earns its place; 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 single-parameter tool with no output schema, the description is nearly complete: it explains the purpose, provides examples, and tells the agent how to use the result. It lacks explicit comparison to get_material_catalog, but the simplicity of the tool makes this acceptable.

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

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

The schema already fully describes projectType with an enum and description. The description adds semantic context by enumerating what kinds of materials may be returned for each project type, helping the agent understand what 'material choices' means beyond the raw enum.

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' with a clear resource 'available material choices for a project type,' then illustrates with concrete examples (flooring types, paint grades, etc.). This distinguishes it from the sibling get_material_catalog by focusing on project-specific 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: it is for retrieving options by project type before making an estimate, and explicitly says to use the returned IDs in get_estimate. It does not mention alternative tools or exclusions, but the usage context is strong.

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

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

No annotations are provided, so the description carries the full burden. It discloses the output (project counts, example projects, typical descriptions) and scope (completed projects in specific Seattle neighborhoods/cities). It doesn't explicitly state read-only behavior, but it's implied by the phrasing.

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 purpose, and no filler. Every sentence earns its place by covering purpose, output, and example queries.

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 explains input, output (counts, examples, descriptions), and use cases. The agent has enough context 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 schema provides 100% coverage for the single 'neighborhood' parameter with examples. The description reinforces the same examples but adds no new semantic information beyond what the schema already documents.

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

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

The description clearly states a specific verb+resource+scope: 'See what remodeling projects Kolmo Construction has completed in a specific Seattle neighborhood or city.' It distinguishes from sibling tools like get_neighbor_permit_activity by focusing on completed projects for hyperlocal social proof.

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

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

It provides explicit example queries for when to use this tool ('Has Kolmo worked in Ballard?'), making the use case clear. However, it does not explicitly mention alternatives or when not to use it, so it falls short of a 5.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure, and it does so thoroughly. It reveals the distance radius, time window, output shape (total count, breakdown, examples), anonymization, data source, and jurisdiction support limitations. It is transparent about what the tool returns and its constraints.

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

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

The description is three sentences, each earning its place: the first states the core function and scope, the second summarizes output and data source, and the third gives practical use cases. It is front-loaded with the most critical information and contains 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?

For a single-parameter, no-output-schema tool, this description is remarkably complete. It covers what the tool does, what it returns, data provenance, jurisdiction limitations, and when to use it. Nothing essential is missing for an agent to decide whether to invoke this tool.

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

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

The schema already provides 100% coverage for the 'address' parameter, so the baseline is 3. The description adds value by explaining that the address is used to locate a 'Seattle-area parcel' and that the tool aggregates activity 'within ~1500 ft' of it, which enriches the meaning beyond a generic street address.

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 ('Aggregate') and a clear resource ('permit activity'), along with precise scope: within ~1500 ft of a Seattle-area parcel over the last 24 months. It clearly distinguishes itself from sibling tools like get_neighborhood_project_activity by focusing on permits, not projects.

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

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

The description explicitly states when to use this tool: 'gauge neighborhood activity before quoting an unusual project, or to set homeowner expectations'. It also provides a key exclusionary condition: 'Currently supports Seattle; other jurisdictions return jurisdictionSupported=false.' However, it doesn't name any alternative tools, so it falls short of the highest bar for usage 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 carries the full burden. It discloses the return content (per-jurisdiction dates, HTTP status, change-detection) and the weekly refresh pipeline, giving useful context about the data source and freshness. It does not explicitly mention that it is read-only, but the description implies a simple retrieval operation.

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

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

The description is three sentences, front-loaded with the primary function, followed by use cases and a reference to the equivalent UI page. Every sentence contributes meaningful context without waste.

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 two optional parameters and no output schema, the description provides a solid overview of the tool's purpose and the data it returns. It does not describe the exact return shape, but enough context is given for an agent to know when to call it and 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?

Schema coverage is 100%, so the baseline is 3. The description does not add significant parameter-level details; it mentions 'per-jurisdiction' which aligns with jurisdictionSlug, but the schema already describes both parameters clearly.

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

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

The description clearly states the tool 'Returns per-jurisdiction last-verified dates plus the latest results from the weekly source-of-truth snapshot pipeline' with specific verbs and resource. It distinguishes itself from sibling permit tools by focusing on data freshness rather than answering questions or checking requirements.

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

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

The description provides explicit use cases: 'Use to answer "how current is this fee/timeline?" or to surface confidence in a permit answer.' It does not explicitly name alternatives or exclusions, but the context of when to use it is clear from the use cases.

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

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

No annotations are provided, so the description carries the burden of disclosure. It openly describes the return content (full detail with timeline, fee model, etc.), the filtering behavior (by jurisdiction or keyword), and the special behavior when 'address' is passed (adding submittals_v2 from the unified resolver). This exceeds a basic description, though it omits behavioral nuances like the default for 'onlyAuthoritative' and pagination limits (though those are in the schema).

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

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

The description is three sentences, each earning its place: the first defines what the tool returns, the second gives usage context, and the third explains a key parameter's effect. No fluff or repetition, well-organized.

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

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

Given that there is no output schema, the description does a solid job of explaining what the agent can expect in return (full detail fields, plus submittals_v2 when address is provided). It covers the core functionality and a notable conditional behavior. It omits edge-case behaviors like default limits or the exclusion of legacy rows via 'onlyAuthoritative', but those are documented in the schema, so the description remains 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 meaningful semantics beyond the schema: it clarifies that 'address' triggers an enriched response with structured submittals_v2, and explains how 'jurisdiction' and 'keyword' act as filters. This goes beyond merely restating the schema.

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

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

The description clearly states the tool's purpose with a specific verb ('Enumerate permit rules') and resource ('permit rules'), and lists the exact detail fields (timeline, fee model, inspection sequence, submittals, contractor specialties). This distinguishes it from siblings like 'check_permit_requirements' or 'answer_permit_question' which focus on specific questions or requirements rather than enumerating detailed rules.

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: "Use for 'what does a Seattle ADU permit require?' or to list all rules for a jurisdiction." This tells the agent when to select this tool over alternatives. It also explains the conditional usage of the address parameter for obtaining submittals_v2. However, it does not explicitly mention when NOT to use it or name alternatives, which would be 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 full burden. It discloses the content of the response (full details, before/after images, testimonial) and the fallback behavior ('If not found, returns a list of available slugs'). This is meaningful behavioral transparency for a read-only 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?

Two sentences, front-loaded with the primary purpose, followed by the fallback behavior. No wasted words; every element adds value.

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

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

For a single-parameter get tool with no output schema and no annotations, the description adequately covers the key behaviors: what is returned on success and an alternative response on failure. It does not detail the return format, but this is reasonably complete for the complexity 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?

Schema coverage is 100%: the schema already defines 'slug' as 'The URL slug of the project.' The description only says 'by its slug,' adding no new meaning beyond what the schema provides. The baseline of 3 applies because the schema fully documents the parameter.

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

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

The description clearly states the tool's purpose: 'Get full details for a specific project by its slug.' It specifies the resource (project), the method (get), and the parameter (slug), and distinguishes itself from list and other specific project tools by naming the included details (before/after images, 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. It does not explicitly mention alternatives or when not to use, but the focus on 'a specific project' clearly differentiates from listing tools like list_projects.

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 does disclose that the ROI is 'estimated' and based on 'Remodeling Magazine Cost vs. Value data for the Pacific Northwest', which is useful. However, it does not explicitly state that the tool is read-only or describe any side effects, and it omits behavior regarding optional parameters (e.g., returning a ranked list when projectType is omitted), which is only hinted at in 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 long, front-loaded with the core action, followed by supporting context and illustrative examples. Every sentence serves a purpose, and 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?

For a tool with no output schema and no annotations, the description provides a solid context: geographic scope, data source, and use cases. It clearly explains the purpose and hints at return types ('estimated ROI', 'expected resale value added'). It does not detail the exact return structure, but given the simplicity of the tool, this is 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?

Schema description coverage is 100%, so the baseline is 3. The description adds some contextual meaning by giving example project types and clarifying the output when estimatedCost is provided ('returns expected resale value added'), but this largely mirrors schema descriptions. No significant new parameter semantics are added.

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 the estimated return on investment (ROI) for a home remodeling project in the Seattle area.' This is specific (verb 'get', resource 'ROI', geographic scope) and effectively distinguishes it from siblings like get_estimate or get_project. The examples further clarify the exact use case.

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

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

The description provides a clear usage context: 'Helps homeowners decide which projects add the most resale value' and shows example queries. It does not explicitly name alternatives or state when not to use it, but the context is distinct enough among sibling tools to guide selection.

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

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

Since no annotations are provided, the description carries full burden. It discloses the return fields (star rating, customer name, project name, quote text) and the filtering method (slug or keyword). It does not explicitly mention read-only behavior, but 'get' implies non-destructive intent. It lacks caveats about empty results or pagination, but for a simple getter, 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 three sentences, all informative, with no filler. It frontloads the core purpose, then adds output details and usage guidance. 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 tool with 4 optional parameters, no output schema, and no annotations, the description adequately conveys purpose, output, and usage guidance. It also points to list_reviews for unfiltered queries. Minor gaps include absence of sorting/pagination behavior, but the limit parameter default is documented in the schema, so the overall context is sufficient.

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

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

The input schema covers 100% of parameters with descriptions, so the baseline is 3. The description adds no new semantic detail beyond naming 'by slug or keyword' as filters, which is already present in the schema (projectSlug and keyword). No further elaboration on parameter syntax or defaults is provided.

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 customer testimonials tied to a specific project (by slug or keyword) from the testimonials table. Returns star rating, customer name, project name, and quote text.' It identifies a specific verb, resource, and scope, and distinguishes itself from list_reviews by explicitly scoping to a specific project.

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 to source social proof or case-study quotes for a particular job. For unfiltered reviews, use list_reviews.' This tells the agent when to use this tool and names an alternative for a different use case (unfiltered reviews).

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 and discloses the not-found fallback behavior (returns available slugs), which is valuable. It doesn't mention auth or side effects, but as a read-only detail retrieval, this is likely 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?

Two sentences, front-loaded with the main purpose, and no wasted words. The fallback behavior is appended efficiently.

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

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

For a simple one-parameter read tool with no output schema, the description is sufficient: it explains the action and the not-found behavior. It could expand on return structure, but given simplicity, this is adequately 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 input schema already fully describes the slug parameter with an example, so baseline is 3. The description's mention of 'residential service' adds slight context but does not significantly expand parameter semantics beyond the schema.

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

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

The description clearly states the tool fetches full details for a residential service by slug, using a specific verb and resource. It differentiates from siblings like list_services and get_project by specifying 'residential service' and 'by slug'.

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

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

Provides clear context: use when you have a specific residential service slug and need full details. It includes fallback guidance for not-found cases, but does not explicitly name alternatives or exclusions relative to 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 burden and does disclose key behavior: returns day-by-day forecast, go/no-go based on temperature, rain, and wind. However, it omits details like the default days value, how 'interior' project type is handled despite the exterior-only framing, and potential data source limitations or update frequency.

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 purpose, and no wasted words. Every sentence contributes value, making it easy to scan.

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

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

For a simple 2-parameter tool without output schema, the description covers location, purpose, and output type. Gaps include the missing mention of the default days value and the contradiction between the exterior-only description and the 'interior' enum value, which leave minor ambiguity.

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

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

Schema coverage is 100%, both parameters have descriptions. The description adds minor context connecting projectType to weather requirements and the forecast timeframe, but does not significantly extend beyond schema. Baseline of 3 is appropriate.

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

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

The description clearly states the tool checks Seattle weather suitability for exterior construction, with a specific verb ('Check') and resource ('upcoming weather in Seattle'). It also describes the output (day-by-day forecast with go/no-go recommendations) and lists example project types, distinguishing it from sibling tools like check_permit_requirements or get_estimate.

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 for use: 'Perfect for scheduling exterior painting, decking, roofing, landscaping, siding, or fencing.' It implies when to use it for construction scheduling but does not explicitly exclude alternatives or mention the 'interior' project type in the schema, which is a minor inconsistency.

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 must fully disclose behavior. It reveals that only published posts are listed and that filtering by tag/author is possible, but it omits pagination behavior, default limit (though present in schema), ordering, and whether returned data includes full content or summaries. These gaps limit 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 sentence starting with the main action, followed by scope and filter options. It contains no redundant details or filler, making it efficient 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?

As a simple list tool with no output schema, the description covers the core operation and filters but does not clarify the return format (summaries vs full content) or pagination defaults beyond schema. It is adequate yet leaves some context-dependent gaps for an AI agent.

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

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

Schema coverage is 100%, with descriptive text for all four parameters. The description's reference to 'tag or author' mirrors the schema's parameter descriptions and adds no extra meaning. Limit and offset are not mentioned beyond schema, so baseline score 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 action 'List published blog posts' and specifies the content domain ('home remodeling, renovation costs, and construction tips'). It mentions filtering options, distinguishing it from single-post retrieval tools like get_blog_post, though it does not explicitly name alternatives.

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

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

The description implies usage when a filtered list of published blog posts is needed, but it does not explicitly contrast with sibling tools such as search_content or get_blog_post. No exclusions or decision criteria are provided.

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

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

With no annotations, the description carries the burden. It clearly discloses the scope (all tags/categories, published posts, post counts) and implies a non-mutating operation. It does not explicitly state read-only behavior or output format, but for a zero-param enumeration tool 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?

Two sentences, front-loaded with the core purpose and immediately followed by usage context. 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 zero-parameter, no-output-schema tool, the description fully explains what it does, why it's useful, and how it fits within the broader toolset. There are no gaps in required context.

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

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

The tool has zero parameters, which receives a baseline of 4. There is no parameter info needed since none exist, and the description adequately explains 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 clearly states the tool enumerates every tag and category used across Kolmo's published blog posts, with post counts. It distinguishes itself from siblings like list_blog_posts by focusing on taxonomy rather than individual posts.

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

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

Explicitly says to use this tool before calling list_blog_posts to discover topics, or to surface coverage gaps. This provides clear when-to-use guidance and distinguishes it from alternative listing 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 burden. It discloses the listing nature and adds valuable context about the 'public' category, including certifications and Small Works Roster eligibility. However, it does not mention pagination behavior, default ordering, or error handling, which could affect agent expectations.

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

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

The description is front-loaded with the main purpose and then provides focused details on the category filter. The second sentence is dense but relevant, explaining the 'public' category's special meaning. It could be slightly more concise, but no sentence is wasted.

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 only 3 parameters, all fully described in the schema, and no output schema, the description provides enough context for an agent to understand the tool's scope and the meaning of the category filter. It lacks explicit output format details, but those are not required for a simple list operation.

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 descriptions for all three parameters, so baseline is 3. The description adds significant depth to the 'category' parameter by explaining that 'public' encompasses public works and government contracts, including specific certifications and project thresholds, which goes well beyond the schema's one-line description.

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

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

The description clearly states 'List commercial construction services', providing a specific verb and resource. It distinguishes itself from sibling tools like 'list_services' by narrowing to commercial construction and mentions optional category filters, making the purpose immediately clear.

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

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

Usage is implied: use this tool to list commercial services, optionally filtered by category. However, it does not explicitly contrast with sibling tools such as 'list_services' or provide when-not-to-use guidance, so it falls short of explicit alternatives.

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

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

No annotations are provided, so the description carries the full burden. It mentions return fields (portal URLs, contact info, code-cycle metadata, verification status) but omits details like pagination, sorting, or data freshness. The filtering behavior is implied by the county parameter but not described in the tool text.

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

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

The description is two concise sentences, front-loaded with the action and scope. No redundant information or filler is present.

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 two optional filters and no output schema, the description covers the main return fields and use case. Some behavioral details are missing, but the overall purpose and scope are well 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%, so the baseline is 3. The description adds context by listing the three counties and mentioning verification status, but it does not provide additional semantics beyond what the schema already documents for the county and verifiedOnly parameters.

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

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

The description clearly states it lists jurisdictions in Kolmo's permit catalog, specifying the exact counties covered and the types of data returned. This distinguishes it from sibling tools that focus on permit requirements or submittals.

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

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

Explicitly says 'Use to discover which cities are supported and where to submit permits,' giving a clear use case. It does not mention when not to use it or name alternatives, but the stated context is sufficient for tool selection.

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

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

With no annotations provided, the description carries the full transparency burden. It clearly indicates this is a read-only operation listing codes and provides valuable context about primary/secondary NAICS categories. While it does not explicitly state 'read-only' or describe response format, the nature of the tool makes side effects unlikely.

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: the first states the core purpose, the second gives usage context, and the third adds valuable detail about the actual codes. Every sentence earns its place, and 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 tool with one optional parameter and no output schema, the description is nearly complete. It covers what the tool lists, why to use it, and gives a concrete example of the primary code. Minor omission is the lack of any note about output format or limits, but these are not critical for this simple listing tool.

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

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

Schema coverage is 100% and the parameter 'system' is already well documented with an enum and default value. The description adds useful context by referencing the code systems (NAICS, NIGP, UNSPSC) and giving an example NAICS code, but does not substantially go 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: 'List Kolmo's vendor procurement codes', naming three code systems (NAICS, NIGP, UNSPSC). This clearly distinguishes it from sibling listing tools and states the exact scope of the tool.

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

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

Explicitly states when to use the tool: 'when vetting Kolmo for gov bids or setting up Kolmo as a vendor'. This gives actionable context and implies it is not for general procurement/contractor queries.

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

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

With no annotations provided, the description carries the burden of behavioral disclosure. It specifies that projects are 'completed' and include 'before/after photos and locations', which adds useful context. However, it does not mention pagination, default limits, or return format, leaving some behavioral traits undisclosed.

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 contains no redundant information. The second sentence efficiently covers the filter options. It is maximally concise while conveying necessary scope.

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 required parameters and no output schema, the description is nearly complete. It states the result content (photos/locations) and filtering options. Pagination defaults are not mentioned, but the schema covers limit/offset parameters, so the description remains sufficient.

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

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

Schema description coverage is 100%, so baseline is 3. The description briefly mentions filtering by 'category or keyword' but adds no additional meaning beyond the schema. Parameters like limit and offset are not described in the tool description, but the schema descriptions for all parameters are complete.

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 completed remodeling projects with before/after photos and locations. This distinguishes it from siblings like 'get_project' (single project) and 'list_project_types' (project types). The verb 'list' and resource 'completed remodeling projects' are 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 by mentioning filtering by category or keyword, but it does not explicitly state when to use this tool versus alternatives like 'get_project' or 'list_project_types'. No exclusions or alternative tools are named, so guidance is implied rather than explicit.

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

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

With no annotations provided, the description carries full burden of behavioral disclosure. It clearly states what the tool does (lists exactly 11 project types) and what it returns (required input fields and descriptions), giving complete transparency for a read-only list 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 exactly two sentences: the first states the purpose, the second provides usage guidance. Every word earns its place, with no redundancy or filler.

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

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

For a simple discovery tool with no parameters and no output schema, the description fully covers what the tool does, the exact count of items, and what information is returned. It is sufficiently complete 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 tool has zero parameters, so baseline per rubric is 4. The description adds value by explaining the output includes input fields, though it does not need to compensate for any parameter schema gaps.

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

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

The description uses a specific verb 'List' with a clearly defined resource 'all 11 supported calculator project types', and additionally states that it includes required input fields and descriptions. This distinguishes it from sibling tools like get_estimate or get_material_options by focusing on discovery of project types.

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 advises that this tool is useful for discovery before calling get_estimate, providing a clear use case. However, it does not explicitly mention when not to use it or offer alternative tools beyond this implied relationship.

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 behavioral disclosure burden. It does disclose that the tool combines verified Google reviews and on-site testimonials, and offers filtering by rating. However, it omits other behavioral traits like ordering, default sorting behavior, or what happens when no reviews match, which would be important for an agent to predict the tool's behavior.

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

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

The description is concise, delivering the core purpose in two sentences. It front-loads the main action ('List') and immediately specifies the resource and scope. No unnecessary details or repetition of schema information are present, making it efficient and well-structured.

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

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

For a simple list tool with no output schema, the description covers the essential aspects: what it lists, for whom, the sources combined, and a filtering capability. The schema handles parameter defaults, so the description does not need to repeat them. It could mention sorting or return fields, but the absence of an output schema raises the burden slightly; nevertheless, the description is largely complete for its purpose.

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

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

The schema provides 100% coverage with descriptions for all four parameters (limit, offset, source, minRating). The description adds value by explicitly stating the filter on minimum star rating, which aligns with minRating, and implies the source combination. However, since the schema already explains parameter meanings, the description's marginal addition is moderate, supporting a baseline score of 3.

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

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

The description clearly states the tool's function: listing customer reviews and testimonials for Kolmo Construction. It specifies the resource (reviews/testimonials) and the scope (company-wide), distinguishing it from sibling tools like get_project_testimonials which likely return project-specific testimonials.

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 does not provide explicit guidance on when to use this tool versus alternatives such as get_project_testimonials. It mentions the filter by minimum star rating but does not specify when this tool is preferred, prerequisites, or exclusions. The usage context is only implied through the company-level scope.

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 adds context by listing the fields returned, but does not disclose pagination behavior (beyond schema defaults), rate limits, or result ordering. This is a minor gap for a list tool.

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

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

Two concise sentences. The first states purpose and scope, the second gives a usage tip. No wasted words.

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

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

For a simple list tool with 3 optional parameters and no output schema, the description adequately conveys what is returned and how to search. It could mention default pagination, but the schema already documents defaults. The 'residential' qualifier provides important context relative to 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 baseline is 3. The description's mention of `search` adds a usage hint but is largely redundant with the schema's 'Filter by keyword' description. No additional meaning is provided for limit or 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 clearly states the tool lists all residential remodeling services and specifies the returned fields (slugs, descriptions, page URLs). The word 'residential' distinguishes it from sibling tools like list_commercial_services.

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

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

Provides a direct usage guideline: 'Use `search` to find by keyword.' This gives clear context for a common scenario. It doesn't explicitly state when not to use the tool, but the 'residential' qualifier and sibling tool names imply alternative choices.

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. It discloses key behaviors: geocoding, county GIS resolution, data returned, and the citation of every fact. It does not mention potential failure modes, latency, or caching behavior, but the description does include external dependency context (county GIS) and the citation trait. This is above average for a lookup tool.

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

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

The description is compact and front-loaded with the core purpose. Four sentences convey the purpose, return data, and usage guidance. It is slightly longer than necessary but every sentence provides distinct value. There is no repetition or filler.

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

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

The tool has no output schema and no annotations, so the description must be self-sufficient. It covers the input, process, output data, and usage context. It does not describe the exact return format or error cases, but for a lookup/geocoding tool, it gives enough for an agent to understand when and why to invoke it.

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

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

Schema description coverage is 100%, so the baseline is 3. The description adds context for the 'address' parameter by implying the geographic scope ('Seattle-area' and the three counties) and provides an example use, but it does not add significant meaning beyond what the schema already defines. It barely mentions forceRefresh.

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 action ('Address-first parcel lookup'), identifies the resource (parcel by address), and lists exactly what it returns (zoning, setbacks, overlays, lot area, etc.). It also distinguishes itself from sibling tools by positioning itself as the preliminary lookup before 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?

Provides explicit when-to-use guidance with a real example ('what can be built at 123 Main St Seattle?') and even names the alternative/next-step tools ('before calling check_permit_requirements / estimate_permit_fee'). This makes it clear the tool is the address-first entry point.

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 behavioral context: the tool uses 'real-time L&I data' and 'Kolmo's authoritative permit catalog,' and it returns explicit gap callouts with an example. This goes beyond a generic 'matches' statement and informs the user about data sources and output style. However, it does not discuss error handling or edge cases (e.g., missing contractor/permit), which prevents a 5.

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

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

The description is two sentences, front-loaded with the primary action in the first sentence and a specific example in the second. Every clause earns its place: it states what it does, what it returns, an example of gaps, and the data sources. 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?

The tool has three required parameters, no output schema, and no annotations. The description explains the return behavior (qualified or not, with gap callouts) and gives an example, which largely compensates for the missing output schema. It does not specify exact output format or error handling, but the core functionality is clear. This is complete enough for a matching tool with this complexity.

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

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

The input schema already has 100% coverage with descriptions for all three parameters (contractorQuery, jurisdictionSlug, projectType). The description adds a bit of context (e.g., 'WA contractor's L&I license' clarifies the contractor license type, and 'permit's required specialties' connects projectType to permit requirements), but this is marginal beyond the schema. Per the baseline rule for high schema coverage, a 3 is appropriate.

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

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

The description clearly states the tool's function: cross-referencing a contractor's L&I license specialty against a permit's required specialties and returning qualification status with explicit gap callouts. It uses specific verbs like 'Cross-reference' and 'Returns,' and distinguishes itself from sibling tools like check_contractor_license_status (which only checks license status) and check_permit_requirements (which likely checks requirements without contractor matching).

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 the use case: when you need to determine if a contractor is qualified for a specific permit given a project type and jurisdiction. It provides clear context (WA contractor, permit, gap callouts) but does not explicitly name alternatives or state when not to use this tool. Since context is clear and no exclusions are needed beyond the obvious, this is a 4.

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 the return behavior (confidence score + a single clarifyingQuestion for ambiguous parses), which is a key behavioral trait. It also reveals the underlying model (Gemini 2.5 Pro) and constrained JSON schema, giving the agent a realistic expectation of output reliability and format. While it doesn't address every edge case or potential failure, it provides substantial context beyond basic operation.

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

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

The description is three sentences long, with each sentence serving a distinct purpose: (1) defining the parse task and output, (2) explaining the return behavior and ambiguity handling, and (3) providing usage instruction and model context. There is no redundant or filler 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 tool with 4 parameters and no output schema, the description covers the essential context: what it does, when to use it, what it returns, and how ambiguity is handled. It also names the downstream tools to call next, which helps the agent understand the larger workflow. The only minor gap is that optional parameters (cityName, zoningCode, jurisdictionSlug) are not explained outside the schema, but the schema covers them adequately.

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 four parameters (100% coverage), so the baseline is 3. The tool description does not add additional parameter-level details beyond what the schema states; however, it does reinforce that 'description' is the primary free-text input and clarifies its role in the permit workflow. It neither harms nor significantly enhances parameter understanding beyond the schema.

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

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

The description clearly identifies a specific verb ('Parse') and resource ('homeowner's natural-language project description'), and enumerates the output fields (projectType, areaSqft, heightClass, etc.), making the tool's purpose unmistakable. It distinguishes itself from sibling tools like check_permit_requirements by focusing on interpreting free text rather than evaluating permit rules.

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

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

The description explicitly states when to use the tool: 'Use this before calling check_permit_requirements / estimate_permit_fee when you only have free text from the homeowner.' It names specific downstream tools and includes a clear condition ('when you only have free text') that implies when not to use it. This gives the agent actionable sequencing and alternatives.

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

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

With no annotations provided, the description fully carries the behavioral disclosure burden. It reveals the unified permit-engine pipeline, the specific output components (triggers, citations, filler actor, gap-resolution), and per-jurisdiction fidelity levels including the no-spec fallback for unverified jurisdictions.

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

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

Four concise sentences, each serving a distinct purpose: operational definition, usage guidance, fidelity explanation, and edge-case handling. No redundant information, and the most important points 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?

Despite having no output schema and no annotations, the description provides sufficient context about the output composition, jurisdiction-dependent behavior, and how it differs from related tools. It also points to external documentation for deeper detail, making it complete for an agent to decide and invoke correctly.

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

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

The input schema already provides detailed descriptions for all 6 parameters (100% coverage). The description only ties 'parcel + permit scope' to the address/scope parameters but adds no deeper semantic meaning 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 the tool resolves a structured submittal-item set for a parcel and permit scope, using a specific verb ('resolve') and resource. It explicitly contrasts with check_permit_requirements, which makes the purpose distinct 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?

It explicitly says 'Use this when you need the per-item checklist...' and distinguishes it from the rule-level summary returned by check_permit_requirements. It also provides jurisdiction-based output caveats that inform appropriate use cases.

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

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

No annotations are provided, so the description carries the full burden. It discloses that results are 'ranked results grouped by type,' which is a basic behavioral trait. However, it does not explain ranking criteria, pagination, default limits, or possible response structure beyond grouping. This is minimal but not misleading.

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 scope, followed by usage guidance. Every word earns its place with no redundancy or filler.

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

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

For a search tool with a simple schema and no output schema, the description is adequately complete. It states scope, result grouping, and when to use. It could mention that 'types' restricts results, but the schema already covers that. Minor gap: it doesn't describe the exact result shape beyond grouping, but that's not essential for usage.

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

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

The input schema has 100% description coverage for all three parameters (query, limit, types). The description adds only 'single keyword query' which aligns with the query parameter, but no additional semantics for limit or types. Baseline of 3 applies since the schema already documents the parameters.

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

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

The description clearly states the tool's purpose: searching across all Kolmo content (services, projects, blog posts) with a keyword query. It uses a specific verb ('Search') and resource ('all Kolmo content'), and distinguishes itself from sibling tools by explicitly naming the alternative of calling three separate list functions.

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: 'Use this instead of calling list_services + list_projects + list_blog_posts separately.' This clearly tells the agent when to choose this tool over its alternatives, satisfying the criterion for explicit when-to-use guidance.

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

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

With no annotations provided, the description carries the full burden. It discloses the dryRun behavior (preview vs actual submission), which is a useful behavioral trait. However, it omits details about permissions, side effects of the actual submission (e.g., email sent, record created), and response format. This is only partially 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, front-loaded with the primary function, then a targeted dryRun tip. No redundant information or filler. Highly 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?

The description is adequate for a straightforward submission tool: it states the action, the target, and preview mode. Since the schema fully documents parameters, the main gap is unspecified behavior after submission (e.g., confirmation/response). With no output schema, a bit more detail on return value would improve completeness, but overall it's 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 coverage is 100%, so the schema fully describes all six parameters. The description adds specific guidance for dryRun, reinforcing the schema's meaning, but does not enrich other parameters beyond what the schema provides. Baseline 3 is appropriate.

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

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

The description clearly states the tool's function with a specific verb ('Submit') and resource ('a contact or quote request to Kolmo Construction'), and distinguishes it from sibling read/list tools. The 'on behalf of a user' adds context about the action's scope.

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

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

The description provides clear context for when to use the tool—when a user needs to submit a contact or quote request. It does not explicitly name alternatives or exclusions, but the purpose is self-evident given the sibling set is mostly lookup/read operations. The dryRun note gives usage guidance for preview mode.

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