LocalProof

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

Annotations declare the mutation/safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=true). The description adds context annotations cannot carry: a $2.95 charge, that billing is gated so unsupported/held jurisdictions fail before payment, and that repeat-polling is guided via check_property_changes.

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?

Front-loads price, then purpose, then the alternative and the failure condition in three sentences with no filler. The middle sentence is a dense enumeration, but every clause carries distinct information.

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

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

An output schema exists, so return-value documentation is not required, and the description covers pricing, failure semantics, alternative selection, and follow-up polling. Nothing an agent needs to invoke 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 description coverage is 100%, so the schema already documents city, unit, state, and address. The description adds jurisdiction context (San Francisco / California) but no syntax or routing detail beyond the schema, so the baseline 3 applies.

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

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

States a specific verb ('Build') plus resource ('deepest released San Francisco development evidence package') and enumerates the package contents (chronology, attention items, completeness, source gaps, provenance). It explicitly names the sibling build_property_intelligence_pack as the lighter alternative, so an agent can differentiate without opening schemas.

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?

Gives an explicit when-to-use ('Use this for development due diligence') tied to a named alternative with its own selection condition ('a lighter current snapshot'). It also states a precondition failure mode ('Unsupported or held jurisdictions fail before payment'), leaving no inference needed.

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=false, idempotentHint=false and openWorldHint=true, and the description corroborates the write/charge profile by disclosing a $0.25 cost and the billing boundary (jurisdiction failures occur before payment). That is real value beyond the annotations, though it stops short of covering repeat-call cost behavior or whether a held jurisdiction can later be retried.

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 short sentences with the price front-loaded and the decision rule immediately after the capability statement. Slightly dense jargon ('broad released multi-source property package', 'repeat-poll guidance') costs a little readability, but nothing is redundant.

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?

An output schema exists, so return-value documentation is unnecessary; the description instead covers cost, jurisdiction gating, and sibling selection. The one remaining gap is what happens on repeat calls or partial-source coverage, but that is minor for a well-annotated paid tool.

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

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

Schema description coverage is 100% and every parameter is documented inline, including the California-only jurisdiction constraint on 'state', so the baseline is 3. The description adds no address-format or disambiguation detail beyond what the schema fields already say.

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?

Specific verb ('Build') plus a precisely scoped resource ('broad released multi-source property package') and an enumeration of what the package contains (completeness, source gaps, provenance, repeat-poll guidance). It also names the sibling family it differs from ('focused check_* tools'), so an agent can place it without opening another schema.

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 routing: 'Use this for a comprehensive current property view; use focused check_* tools when only one evidence class is needed.' It also states a precondition failure mode ('Unsupported or held jurisdictions fail before payment'), which is actionable guidance rather than boilerplate.

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 mark this non-read-only, non-idempotent, open-world, so the safety profile is partly covered, and the description adds genuinely non-derivable behavior: the $0.25 charge and the guarantee that unsupported jurisdictions fail before payment. It stops short of describing auth requirements or what 'held' means operationally, so it is strong 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?

Three short sentences with zero filler, front-loading the price so the agent sees the cost implication first, then purpose, then the sibling alternative. 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?

An output schema exists, so return values need no explanation, and the description covers cost, failure behavior, and the alternative tool. The only minor gap is that it does not clarify the meaning of 'released' versus 'held' jurisdictions or expected latency, but it is sufficient to invoke correctly.

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

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

Schema coverage is 100%, so all four parameters (address, city, unit, state) are already documented in the schema, including the California-only jurisdiction note. The description adds no format or syntax guidance beyond that, so the baseline 3 applies.

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

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

States a specific verb ('reconcile') and resource ('released code-enforcement and complaint records') scoped to one property, and explicitly distinguishes itself from build_property_intelligence_pack. An agent can tell what it returns without opening the schema.

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?

Gives an explicit alternative ('use build_property_intelligence_pack for a broader package') with the condition that selects it, and adds a routing constraint that unsupported/held jurisdictions fail before payment. Nothing about when to pick this tool is left to inference.

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=false, openWorldHint=true, idempotentHint=false and destructiveHint=false, but the description adds material context the annotations do not: a fixed $0.06 cost, privacy-minimized output, and that unsupported/held jurisdictions fail before any charge. The cost and billing-failure behavior are exactly the kind of side-effect disclosure that matters for a paid call; only a little more (e.g. caching/rate behavior) is left implicit.

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 the cost front-loaded, then purpose, then alternatives, then failure semantics. No filler and no repetition of name or title.

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?

An output schema exists, so return values need not be described. Between the description (purpose, alternatives, cost, failure) and the schema (all four params fully documented), an agent has everything needed 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?

Schema description coverage is 100%, and the schema already documents address, city, unit and state including the California jurisdiction hint. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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

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

States a specific verb (return) plus a precise resource (privacy-minimized official parcel and land-use attributes) and scopes it to released sources. It explicitly differentiates itself from check_zoning_context and build_property_intelligence_pack, so an agent can route without opening a sibling schema.

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?

Gives an explicit when-to-use rule ('use this for parcel facts') and names the two alternative tools with the condition that selects each (released zoning context, cross-source context). It also states the failure condition ('unsupported or held jurisdictions fail before payment'), which removes the main ambiguity an agent would face.

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?

Adds material behavior beyond annotations: a $0.25 USD charge and the fact that unsupported/held jurisdictions fail before payment, which matters since readOnlyHint=false and idempotentHint=false imply a metered, non-repeatable call. It does not state whether retries are re-charged or how partial results are billed, so it falls short of 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?

Three tight sentences with no filler, and the cost and jurisdiction constraint are front-loaded. The opening price fragment is slightly clipped but functional rather than wasteful.

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?

An output schema exists, so return values need not be described. The description covers cost, jurisdiction support limits, and the sibling alternative, leaving only edge-case billing behavior unspecified for a metered 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?

Schema description coverage is 100% and each property is already documented, so the baseline is 3. The description contributes no additional parameter meaning (e.g., how city/state affect routing outcomes) beyond what the schema states.

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 (trace) and resource (released SF permit review routing, departments, holds, timing, outcomes), and explicitly contrasts itself with the sibling check_permits. An agent can distinguish it from the 13 siblings without opening a schema.

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 routes: 'use this for administrative routing state; use check_permits for permit records', and states the precondition that unsupported or held jurisdictions fail before payment. Both when-to-use and a failure boundary are given.

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 declare readOnlyHint=false, openWorldHint=true, idempotentHint=false, and the description adds genuinely new context: a $0.09 charge, that unsupported or held jurisdictions fail before payment, and that the property must be resolved. It does not discuss idempotency or repeat-call behavior, so it falls short of 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?

Three tight sentences with the cost front-loaded and the routing guidance immediately after the purpose. Efficient, though "Use this for permit detail" is mildly redundant with the opening 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?

An output schema exists so return values need not be explained, and the description covers cost, the resolution prerequisite, and failure behavior. It could say more about what "released coverage" means operationally, but it is sufficient to call 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% and each parameter (address, city, state, unit) is documented in the schema, so the baseline is 3. The description adds only the notion of a "resolved property" and jurisdiction support, not parameter-level syntax or format guidance.

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 ("Reconcile current official permit records") with an explicit scope constraint ("one resolved property where permit coverage is released"). It names the sibling tools it is not (check_permit_routing, build_property_intelligence_pack), so an agent can route without opening schemas.

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?

Gives explicit alternatives with selecting conditions: check_permit_routing for San Francisco routing/holds, build_property_intelligence_pack for cross-source context, this tool for permit detail. Nothing is left to inference.

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 cover readOnly=false, openWorld=true, and idempotent=false, but the description adds genuinely new behavioral context: a fixed $0.25 USD charge and the fact that unsupported jurisdictions fail before any payment occurs. It does not explain why a lookup carries readOnlyHint=false or the result shape, so it is strong 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?

Three tight sentences with no filler: cost is front-loaded, then the operation, then routing alternatives and the failure condition. Every sentence carries 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?

An output schema exists, so return values need not be described. Combined with fully documented parameters, the description supplies the remaining decision-critical context: pricing, jurisdiction support limits, and the routing alternatives.

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 all four parameters (address, city, unit, state) are already documented in the schema, including the California-only jurisdiction note. The description adds no parameter-level syntax or routing detail beyond 'one property', so the baseline 3 applies.

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

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

States a specific verb and resource: 'Reconcile released planning applications and entitlement activity for one property.' It also explicitly names the sibling tools it is not (check_zoning_context, build_property_intelligence_pack), so an agent can distinguish it without reading the schema.

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?

Gives explicit when-to-use guidance ('Use this for planning records') plus two named alternatives with the conditions that select them (current zoning context vs. multi-source context). It also states the pre-condition that unsupported/held jurisdictions fail before payment.

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?

Discloses the $0.03 charge, the fail-before-payment behavior for unsupported jurisdictions, and the current single-jurisdiction coverage – none of which the annotations convey. It also explains why readOnlyHint is false (the call is billed), which is exactly the kind of context annotations cannot 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?

Roughly fifty words in four sentences, front-loaded with the price and the action, then routing to alternatives and finally the failure semantics. No filler 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?

Given an output schema exists, return values need no explanation, and the description covers cost, coverage, alternatives, and failure modes. The only gap is that 'resolved property' is not explained (whether resolve_jurisdiction must run first), a minor omission for a repeat-polling tool.

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

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

Schema description coverage is 100% and each parameter (address, since, city, unit, state) is documented in the schema, so the description owes little here. It reinforces that 'since' is a lower bound and cannot be in the future, but adds no format or constraint detail 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?

States a specific verb and resource – 'Find timestamped changes after an ISO 8601 since value across released evidence dimensions for a resolved property' – and pins the current scope ('comprehensive in San Francisco'). It also names the siblings it is not (check_permits, build_property_intelligence_pack), so an agent can distinguish it without opening a schema.

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?

Gives an explicit use case ('repeat polling') plus two named alternatives with the condition that selects each ('current permit detail', 'full current snapshot'). It also states a failure precondition – unsupported or held jurisdictions fail before payment – which sets caller expectations before invocation.

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

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

Annotations only declare openWorldHint and non-idempotency; the description adds genuinely new behavioral facts: the call costs $0.01 USD, and unsupported/held jurisdictions fail BEFORE payment so no charge is incurred. That cost and failure semantics are not derivable from the annotations. It falls short of 5 only because terms like 'released' and 'held' jurisdiction are never defined and no coverage-checking guidance is given.

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 short sentences, front-loaded with the cost the agent most needs before invoking, then purpose, then the exclusion and alternative. Every clause carries load with 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?

With an output schema present, return values need not be explained, and the description covers the remaining agent-critical facts: cost, precondition of a resolved property, jurisdictional limits, failure behavior, and the alternative tool. Nothing material to calling 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 description coverage is 100%, so all four parameters (address, city, unit, state) already carry their own documentation, including the California-only note on state. The description only gestures at 'a resolved property' and adds no format, disambiguation, or locality guidance beyond the schema, so the baseline 3 applies.

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

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

The description gives a specific verb and resource ('Return released official zoning context for a resolved property') and explicitly draws the boundary against two other things: proposed-use/legal determinations and the sibling check_parcel_context for parcel attributes. An agent can tell it apart from its siblings without opening any schema.

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

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

It states when to use it ('for zoning evidence'), when NOT to ('not a proposed-use or legal determination'), names the alternative tool for a related-but-different need ('use check_parcel_context for parcel attributes'), and adds a precondition ('for a resolved property', reinforced by the 'unsupported or held jurisdictions fail' note). This is explicit routing 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?

Goes beyond the annotations by disclosing the $0.49 USD charge, the fact that no winner is ranked (output semantics), and that unsupported/held jurisdictions fail before payment, i.e. no charge on rejection. This is meaningful context for a tool whose annotations flag readOnlyHint=false and idempotentHint=false, though it doesn't explain why a comparison is non-idempotent or whether repeat calls re-bill.

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 the cost front-loaded so the agent sees the billing implication first. Every sentence carries information, though the opening price fragment reads as a slightly clipped fragment rather than prose.

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 an output schema present, return-shape details are not needed; the description still covers cost, cardinality, jurisdiction limits, and result semantics (no winner selected). Minor gap: it says "San Francisco" while the schema describes broader California jurisdiction support, leaving the actual supported geography slightly ambiguous.

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

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

Schema description coverage is 100% and the schema already documents the 2-3 item bound, the distinctness requirement, and every nested field. The description adds little beyond restating "distinct candidate sites" and the same-evidence-dimensions constraint, so the baseline 3 applies.

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

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

States a specific verb and resource ("Compare two or three distinct candidate... sites"), bounds the scope (2-3 sites, San Francisco), and explicitly disclaims what it will not do ("without selecting a winner"). It is immediately distinguishable from build_property_intelligence_pack, which it names as the single-site alternative.

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 routing: "Use this for side-by-side site evidence; use build_property_intelligence_pack for one site." It also states an operating precondition (unsupported or held jurisdictions fail before payment), so the agent knows the call can be rejected up front.

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 readOnly, idempotent, openWorld and non-destructive behavior, so the safety profile is covered. The description adds non-annotation context: it is free and it does not touch property records, which is genuinely useful for cost and side-effect reasoning. Return format is left to the output schema, so nothing else is required.

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

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

Two sentences with zero filler; the cost/scope qualifier and the routing purpose come first, and the alternative is deferred to the end. Every clause 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?

With an output schema, full annotation coverage and 100% parameter description coverage, the description only needs to supply purpose, usage routing and cost/side-effect context — all of which it delivers. Nothing an agent needs to invoke 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 description coverage is 100% and each of the three parameters carries its own description, including the California coverage hint, so the schema does the heavy lifting. The description adds no syntax or fallback detail beyond it, making the baseline 3 correct.

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 ('Return released and held jurisdiction and operation coverage') and adds a scope constraint ('without querying property records') that separates it from the property-record siblings. An agent can identify what it returns without opening the schema.

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 names the use case ('use this to plan routing') and the alternative with its selecting condition ('use resolve_jurisdiction when you have a specific address'). This is the when/when-not/alternative pattern done fully.

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 readOnly, idempotent, non-destructive, and open-world, so the safety profile is covered. The description adds meaningfully beyond that: the 'Free' cost signal (not in annotations) and the distinction that this returns static metadata plus freshness expectations rather than live status.

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 short sentences, zero waste. The cost qualifier leads, the resource scope follows, and the sibling disambiguation is last.

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?

An output schema exists, annotations fully cover the safety profile, and params are documented at 100% coverage. For a read-only catalog lookup, the description supplies everything needed to select and 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 all three jurisdiction-selection parameters (city, state, jurisdiction_id) are already well documented in the schema. The description adds only the loose phrase 'for a jurisdiction' and no syntax or precedence guidance beyond what the schema provides, so baseline 3 is correct.

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+resource: 'Return registered authoritative sources and freshness expectations for a jurisdiction.' This is clearly distinct from the sibling get_source_health, which the description itself names as the live-reachability 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 routes the agent: use this to understand evidence sources, use get_source_health for current endpoint reachability. The when-to-use and the alternative are both named, leaving nothing to inference.

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, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered. The description adds genuine value beyond them: the 'Free' cost signal, the fact that no source records are returned, and the semantic caveat 'Reachability is not completeness,' which guards against over-reading the result.

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 short sentences, front-loaded with the cost and purpose, then the routing alternative, then the caveat. No filler; every sentence carries a distinct fact.

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?

An output schema exists, so return-value detail is not required, and the description supplies the cost, non-return semantics, and a caveat on interpretation. Only minor gap is no note on failure behavior when a source is unreachable, which would round out the reachability probe.

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

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

Schema description coverage is 100% and each parameter (city, state, jurisdiction_id) is already documented with its pairing and precedence rules in the schema. The description adds nothing about parameter usage, so the baseline 3 applies.

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

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

States a specific verb and resource ('Probe registered official-source reachability for a jurisdiction') and immediately scopes it ('without returning source records'), which separates it from sibling catalog/coverage tools. The distinction from get_source_catalog is named explicitly, so an agent can route without opening schemas.

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 when-to-use ('Use this for current source availability') paired with a named alternative and its condition ('use get_source_catalog for source identity and freshness expectations'). This is the clearest form of routing 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?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the bar is lower. The description adds genuinely new behavior: it is free, held/unsupported jurisdictions 'fail closed before paid work', and it is a prerequisite step to deeper research — useful operational context not present in structured fields.

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 short sentences, front-loaded with the cost signal ('Free.') and then the purpose, followed by the routing rule and the failure-mode caveat. No filler; every sentence carries distinct information.

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

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

An output schema exists, so return values need not be described, and annotations carry the safety profile. The description covers the remaining agent needs: cost, ordering relative to deeper research, sibling routing, and fail-closed behavior on unsupported jurisdictions.

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

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

Schema description coverage is 100%, so the schema already documents all four parameters including city/state disambiguation and the CA-only constraint. The description adds no parameter-level syntax or format detail beyond what the schema provides; baseline 3 applies.

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

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

States a specific verb+resource: resolving one address or place to a supported jurisdiction and coverage state. It also names the adjacent sibling (get_coverage) and the scope boundary ('before deeper research'), so an agent can distinguish it from the other 13 LocalProof 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?

Explicit when-to-use ('when jurisdiction support is unknown') and explicit alternative with its own condition ('use get_coverage to inspect published coverage without resolving a property'). Nothing is left to inference.

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