ZoningVerdict

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

The description discloses that the tool reports honestly when no published answer exists and lists topics that do have reviewed answers, which is useful behavioral context beyond the annotations. It also states it never generates new answers, a key behavioral constraint. The annotations include openWorldHint=true, which aligns with the description's honest reporting of absence, and readOnlyHint=false, which is consistent with a lookup tool that may have side effects like logging. No contradiction found.

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

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

The description is concise and front-loaded with the core purpose. It uses three sentences efficiently: the first states the function, the second describes the return behavior, and the third provides a critical constraint. 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?

The description is complete for a lookup tool: it explains what it returns, how it handles missing answers, and what it does not do. It does not describe the exact structure of the returned answer or citations, but since there is no output schema, a bit more detail could be helpful. However, the core behavior is well covered, and the annotations provide additional context. A 4 is appropriate.

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

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

Schema description coverage is 100%, so the schema already documents all three parameters. The description adds context about the query being 'plain words' and the municipality being a slug, but these are already in the schema. The description does not add significant new meaning beyond the schema, so a 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: look up a published Q&A for a municipality and topic, returning the reviewed answer with citations. It also explicitly distinguishes itself from generating new answers, which helps an agent understand its exact scope. The verb 'look up' and resource 'published question-and-answer' 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 explicitly says when to use this tool: to retrieve a published answer, and when not to: never generates new answers. It also instructs the agent to confirm with the municipality before acting, which is a clear usage guideline. This is strong guidance that prevents misuse.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, covering the safety profile. The description adds useful context by calling it a 'free preflight' and stating 'Results are for information purposes only,' which reinforces the non-mutating, informational nature. This goes beyond the annotations without contradicting them.

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

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

Three sentences with zero waste. The primary purpose is front-loaded, followed by an explicit exclusion and alternative, then a disclaimer. Every sentence earns its place, making it efficient and 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 preflight tool with no output schema, the description fully specifies the returned data: coverage status, resolve grade, topics, pack version, and last-reviewed date. It also clarifies limitations and the alternative tool. Nothing essential is missing for an agent to call it correctly.

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

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

Schema description coverage is 100%, with each parameter (q, address, municipality) already described in the schema. The description mentions 'address or municipality string' but does not add syntax, format, or precedence details beyond what the schema provides. Baseline 3 is appropriate since the schema handles parameter documentation.

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

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

The description clearly states the tool is a 'coverage preflight' for an address or municipality string, and explicitly distinguishes itself from resolve_parcel_district by stating it does not identify zoning districts. This differentiates it from siblings and gives a specific verb+resource.

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

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

The description explicitly tells when to use this tool versus resolve_parcel_district: 'use resolve_parcel_district only when the district determination is needed and the grade is not unreliable.' It also adds 'Results are for information purposes only,' clarifying the informational nature and setting expectations.

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 minimal annotations (readOnlyHint=false, destructiveHint=false), the description carries the behavioral burden and handles it well. It discloses the $3 USDC pricing, the 'pack_gap refusals are never charged' refund/billing rule, the narrower coverage vs address resolution, and the presence of durable workflow status and result retrieval. These are operational behaviors not visible in annotations or schema, and they are stated clearly.

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 lead sentence gives the core purpose, the second adds cost and coverage boundary, and the third addresses durability. It is well-scoped and all content earns its place.

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

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

Given the complexity (3 required params, nested intent, payment, async workflow) and the absence of an output schema, the description covers the key decisions: what it produces, its pricing, its coverage, and the need to get preflight_status or retrieve results. It omits details like specific error cases or the overall output format, but the coverage is substantial for a paid async tool. A 4 reflects a near-complete picture without perfect detail.

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

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

Schema coverage is only 33% (only request_id has a description). The tool description maps 'address' and 'structured project intent' to the address and intent parameters but does not explain request_id, the required 'intent' subfields, taxonomy_version, or any parameter constraints. It added partial context by characterizing the intent as 'structured project intent' and mentioning 'pack_gap', but it does not compensate for the low schema coverage enough. A 3 is the minimum viable because it gives high-level orientation without undermining the schema.

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

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

The description clearly states what the tool does: 'Compile an address and structured project intent into a preliminary zoning verdict, cited conditions, approval path, versioned evidence and EdDSA JWS.' It names the exact inputs (address, intent), the output (preliminary zoning verdict and related artifacts), and the cost model ('$3 USDC on Base'). This goes well beyond a tautology and distinguishes it from siblings like resolve_parcel_district or get_preflight_status.

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 useful usage context: 'Paid Preflight coverage is narrower than address resolution' hints at when to prefer alternative resolution tools. 'pack_gap refusals are never charged' and 'Durable workflow status and result retrieval included' tell the agent about polling behavior and cost boundaries. However, it does not explicitly name alternative tools or give clear 'use this, not that' instructions, so it is strong but not perfectly 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?

The description discloses important behavioral traits beyond annotations: the subscription activates only after Stripe checkout completes, every email includes unsubscribe and billing links, and alerts are reviewed summaries for information purposes. This adds meaningful context about the payment flow and email behavior. However, it does not mention what happens if the municipality is not covered or if the checkout is abandoned, and the annotations already indicate it's a non-read, non-destructive action, so the description adds value but not exhaustive detail.

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

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

The description is concise and front-loaded with the core purpose (start a $49/month watch), then adds key behavioral details (checkout, unsubscribe links, information purposes) and a pointer to list_municipalities. It is a bit dense with multiple clauses, but every sentence earns its place. Slightly long but still efficient.

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

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

Given the tool's complexity (paid subscription, Stripe checkout, email alerts), the description covers the essential context: cost, activation condition, email contents, and coverage check. It lacks an output schema, so it doesn't need to explain return values, but it does mention the Stripe checkout URL. It could be more complete by noting what happens on failure or if the municipality is not covered, but overall it is sufficient for an agent to call it correctly.

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

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

Schema description coverage is 100%, so the schema already documents both parameters. The description adds context by explaining the 'topic' parameter is optional and lists the allowed values in the schema, but it doesn't add much beyond that. The description does clarify that 'municipality' is a slug from list_municipalities, which is already in the schema. Baseline 3 is appropriate since the schema does the heavy lifting.

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

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

The description clearly states the tool's function: starting a $49/month watch on a covered municipality, optionally filtered by topic, with a specific outcome (email alerts on human-reviewed rule changes). It distinguishes itself from siblings by mentioning coverage via list_municipalities and the subscription/checkout flow, which is unique among the listed tools.

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

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

The description provides clear context for when to use the tool: to start a paid watch on a municipality, optionally for one topic. It explicitly directs users to list_municipalities for coverage, which serves as a prerequisite. However, it does not explicitly state when not to use it or name alternatives (e.g., subscribe_to_twin, get_twin_updates), so it falls short of a 5.

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

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

Annotations already provide openWorldHint=true and destructiveHint=false. The description adds meaningful behavior: rules are 'published,' each carries citation/source link/last-reviewed date, and output is summary-level, not legal advice. No contradiction with annotations.

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

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

Four sentences, each carrying a distinct purpose: scope, code sourcing, output characteristics, and legal caveat. The most decision-relevant constraint is placed early, and there is 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 bounded lookup tool with 100% schema coverage, it explains input sources, expected output contents, and limitations even without an output schema. It does not specify error handling for unknown districts or list the full topic taxonomy, but those are minor given the schema.

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

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

The input schema already documents all three parameters at 100% coverage, including the 'do not guess' guidance for district codes. The description reinforces these semantics with topic examples but does not add meaning beyond the schema.

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

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

States an explicit verb ('Get'), a specific resource ('published rules for one zoning district'), and a slicing dimension ('by topic'), with concrete examples. This clearly differentiates it from siblings like ask_zoning_question and resolve_parcel_district.

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

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

Explicitly instructs that district codes must come from list_districts or resolve_parcel_district and warns not to guess them. It gives actionable prerequisites, though it does not explicitly contrast this tool with ask_zoning_question for unstructured zoning questions.

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

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

Annotations already say readOnly/not destructive. The description adds behavioral value by stating the operation is 'Free', requires a workflow access token, is durable, and the signed result becomes available after settlement. This is meaningful context beyond the annotations and helps an agent know what to configure/check before calling.

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?

A single concise sentence carries the core purpose, a behavioral condition ('after settlement'), and the access requirement, with no filler. The description is front-loaded and each clause adds information an agent needs.

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 a simple shape (two required strings), and the description covers the main lifecycle action (retrieve status, signed result after settlement). However, it does not explain what 'settlement' means, where to obtain the workflow_id, or what the return value might look like. For an agent to actually decide and call this tool, it still needs some contextual assumptions.

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 gives no property documentation (0% coverage), and the description only hints that access_token is a 'workflow access token'. workflow_id is left entirely unexplained, with no format, source, or relationship to the other parameters. This is a clear gap for a tool that arguably could be self-explanatory but still needs parameter-level clarity.

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 ('Retrieve') and clearly names the resource: 'Preflight status' plus 'its signed result'. It also adds the 'durable' qualifier, which makes the object distinct from a one-off query. It does not explicitly differentiate from sibling tools like create_preflight, but the action is clear enough that an agent won't confuse it with creating or watching.

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 a lifecycle ('after settlement' heavily implies waiting for settlement to obtain the signed result), but it does not explicitly state when to prefer this over siblings or how to progress from create_preflight. It includes one practical prerequisite ('requires workflow access token') but no exclusions or alternate-tool routing.

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

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

Annotations already provide readOnlyHint=true and destructiveHint=false, so the description correctly aligns with no contradiction. It adds that the tool is free and requires the original workflow access token, which is useful beyond annotations. However, it does not describe polling behavior in detail, such as how pagination works with the cursor, or what errors might occur.

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

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

The description is a single sentence with essential information, front-loading the main purpose. It is concise and free of unnecessary words, earning a high score for efficiency.

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

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

For a read-only polling tool, the description covers basic prerequisites and purpose, but lacks details on version cursor semantics, response format, and error handling. Given the absence of an output schema and 0% parameter coverage, more context would be helpful, but not critically missing for a simple poll.

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

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

Schema description coverage is 0%, so the description must compensate. It mentions 'version cursor' which suggests the after_version parameter's role, but does not explain workflow_id and access_token beyond the schema names. It adds minimal semantic meaning for the core parameters, leaving the agent to infer from names.

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

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

The description states that the tool polls signed Impact Updates for a purchased machine Preflight with a version cursor, which is a specific action and resource. However, it does not clearly distinguish this from sibling tools like create_watch, subscribe_to_twin, or get_preflight_status, which could overlap in purpose.

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

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

It says 'Free; requires the original workflow access token,' giving some context on prerequisites, but does not explain when to use this tool versus alternatives, or when not to use it. No mention of alternatives or conditions for switching.

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

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

The description discloses key behaviors beyond the annotations: the 100-call monthly quota, one-key-per-network-egress limit, expiration at next UTC month, and the nonce requirement for safe retries. This is strong operational transparency for a key-issuing 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?

Three dense sentences carry all key information: purpose, required parameter generation, quota, expiry, and exclusions. No filler or repetition; front-loaded with the primary action.

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

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

For a simple issuance tool, the description covers the essential behavior: limits, expiration, retry safety, and excluded paid features. It does not explicitly state that the response returns the API key, but the schema and tool name make that reasonably clear.

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

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

The description adds practical meaning to the schema by explaining that client_nonce must be 64 hex chars and retained for safe retries, and it ties accept_terms to the current published terms. Schema coverage already documents the parameters, so this builds on the schema rather than repeating it.

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

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

The description opens with a specific verb and resource — 'Issue a free API key' — and then clarifies it is free-only, distinguishing it from paid workflows and sibling tools. The scope (free tier, no checkout) is unmistakable.

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

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

It clearly states when this tool applies: when a free API key is needed without checkout or wallet. It also gives explicit usage boundaries like one key per network egress per month and a 100-call quota, but it does not explicitly contrast with sibling tools or say when to avoid it.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false. The description adds value by noting the tool is free (like list_municipalities) and that summaries are reviewed but for information purposes only, which sets expectations about data reliability and cost. No contradiction with annotations.

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

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

The description is compact yet packed with useful guidance: the action, the return contents, the dependency on get_district_rules, an alternative for address inputs, and a cost/reliability note. Every sentence earns its place and the primary action 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 list tool with one parameter and no output schema, the description fully covers what it returns, how to use it, and when to prefer alternatives. Nothing an agent needs to call it correctly is missing.

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 description already states 'Municipality slug from list_municipalities.' The tool description adds minimal new meaning—just that it applies to a single municipality. Since the schema covers the parameter, a 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?

States a specific verb and resource: 'List the zoning district codes for one municipality' and specifies the returned fields (name, category, summary). It clearly differentiates from siblings by naming get_district_rules and resolve_parcel_district, so an agent can distinguish when to use this 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 instructs to use the codes with get_district_rules and warns against guessing codes. It also tells agents to use resolve_parcel_district when a street address is available, directly routing to the correct sibling based on context.

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

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds meaningful context: the coverage is 'reviewed summaries of public zoning ordinances' and is 'for information purposes only,' which helps an agent understand the nature and limitations of the data.

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

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

Three sentences, each earning its place: the first states what is listed, the second clarifies the data's nature, and the third gives routing guidance. The key information is front-loaded and there is 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 parameterless, read-only listing tool with no output schema, the description is complete. It names the returned fields, explains the data's purpose, and routes the agent to the correct alternative when an address is available.

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

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

The input schema is empty with 0 parameters, so the description carries no parameter burden and the baseline is 4. The description adds no parameter details because none exist, which is appropriate.

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

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

The description uses a specific verb ('List') and resource ('municipalities ZoningVerdict covers'), and states the exact fields returned: pack version, last-reviewed date, and resolve grade. It also distinguishes itself from check_coverage by explicitly framing this as the address-less starting point, so an agent can separate it from siblings.

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

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

The description gives explicit routing guidance: 'Start here when you do not have a street address; with an address, start with check_coverage.' This clearly states when to use this tool and which sibling to use instead, leaving no 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?

Description adds meaningful behavior beyond annotations: refusal when municipality is unreliable, disclosure of how the district was identified, and an edge-case warning about parcel/zoning boundary disagreements. No contradiction with readOnlyHint=false or destructiveHint=false.

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

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

Four sentences with every sentence earning its place: core operation, precondition, downstream routing, and caveat. The most important scoping information is front-loaded, and there is zero 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 one-parameter tool with no output schema, it fully covers preconditions (coverage check), conditional output (district may or may not be returned), downstream usage, and reliability caveats. The only missing item is precise return structure, which is minor here.

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

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

Schema coverage is 100% for the single address parameter, so the baseline applies. The description reaffirms 'street address' but adds no new syntax, format, or parameter-specific semantics beyond what the schema already provides.

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

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

The description states a specific verb ('Resolve') and resource: a street address to its municipality and, conditionally, its zoning district. It differentiates from siblings by referencing the coverage check and the downstream get_district_rules flow, making the tool's unique role 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?

Explicit workflow guidance is provided: 'Check coverage first' and 'When a district is returned, pass it to get_district_rules.' It also specifies that unreliable municipalities cause refusal before payment, giving concrete preconditions and a clear sequencing context.

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

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

Considering annotations only mark it as non-read-only and non-destructive, the description usefully discloses the cost, duration, absence of automatic renewal, and signed/versioned update polling. This adds real behavioral context beyond what annotations already provide.

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

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

Three tight sentences with no filler. The most important facts (cost, duration, applicability) are front-loaded, and retrieval behavior is stated in the second sentence.

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

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

The description covers payment, duration, renewal behavior, and update retrieval. However, with no output schema and no per-parameter descriptions, the missing explanation of request_id and what the response includes leaves gaps for correct invocation.

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

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

Schema description coverage is 0%, so the description must explain all three parameters. It explains workflow_id and access_token indirectly, but says nothing about request_id, its purpose, or constraints. The mapping from 'original workflow access token' to the access_token parameter is also implicit.

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

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

The description clearly states that the tool attaches 30 days of Impact Updates to a purchased Preflight for a fee. It names a specific verb, resource, duration, and payment mechanism, making it easy to distinguish from sibling tools like get_twin_updates or create_preflight.

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 implies the prerequisite of a purchased machine Preflight and explains the polling workflow with the original access token. It does not explicitly say when NOT to use it or name alternatives, but the context is enough for an agent to infer the right moment.

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