LocalProof

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the heavy lifting is done. The description adds genuinely useful non-annotation context by disclosing the $0.25 USD cost, but it does not explain what 'reconcile' means operationally (merging multiple sources? conflict resolution?) or any auth/quota 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?

Two short sentences with zero filler, and the paid-cost caveat is front-loaded so an agent sees the pricing implication before invoking. It is arguably too terse, but nothing in it 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?

An output schema exists so return values need not be documented, but the description still leaves the core operation vague: what a 'reconciliation' of code-enforcement and complaint records actually yields, and how coverage differs from sibling checks, is unstated. For a paid, open-world lookup in a dense sibling set, this is under-specified.

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% across 4 parameters, so the description must compensate and it largely does not. The phrase 'for a property' only gestures at the required address parameter; city, unit, and state are left entirely to the (undescribed) schema, offering no format, normalization, or optionality 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 ('Reconcile') and resource ('code-enforcement and complaint records for a property'), which distinguishes it from siblings like check_permits, check_zoning_context, and check_planning_activity by domain. It stops short of explicitly naming those siblings or describing what 'reconcile' produces, but the resource boundary is 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?

There is no statement of when to use this tool versus check_permits, check_property_changes, or any of the other localproof check_* siblings. The only implied usage is 'for a property,' which nearly every sibling shares, so an agent gets no 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 declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description adds genuinely new behavioral context: the $0.05 USD cost and the fact that it scans for 'material' changes relative to a caller-supplied timestamp. It stops short of explaining what 'material' filters or what happens on an invalid/unresolved address.

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, with the cost front-loaded and the functional scope stated immediately. No filler or redundancy.

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

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

The output schema exists, so return-shape explanation is not required. Still, for a paid, open-world lookup with 5 undocumented parameters the description leaves gaps around the resolution prerequisite, what qualifies as a material change, and failure modes.

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% across 5 parameters, so the description must carry the load. It only clarifies the meaning of 'since' as a caller-supplied timestamp and hints at the address scope; city, state, unit, and validation constraints (maxLength/minLength) are left entirely to the raw 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 a clear verb ('Find') and a specific resource ('material local permit-record changes') with scope ('for a resolved property since a caller-supplied timestamp'). However, it never distinguishes itself from the near-identical sibling 'localproof.check_property_changes', so the agent must guess which of the two to pick.

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

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

The phrase 'for a resolved property' strongly implies that jurisdiction resolution must happen first, but this prerequisite is never stated explicitly nor tied to a sibling tool. There is no when-not guidance or mention of the alternative change-detection tool.

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 read-only, idempotent, open-world, and non-destructive traits, so the bar is lower. The description adds two pieces of context annotations cannot: a $0.10 USD cost and the constraint that results are only available for jurisdictions with a supported parcel source.

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 front-loaded sentence that leads with the price and then the payload. No wasted clauses, though the trailing jurisdiction caveat is slightly buried.

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. However, with zero parameter documentation and no routing guidance among many similar siblings, the definition leaves the agent short on the information needed to invoke this correctly rather than a neighbouring 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 0% across 4 parameters, and the description never mentions address, city, unit, or state. Only the conventional naming of the fields provides any hint; the description does not compensate for the total lack of schema 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?

States a specific verb ('Return') and resource ('privacy-minimized official parcel context record') and enumerates the attribute classes it bundles (land-use, physical-property, zoning, assessor). This implicitly distinguishes it from narrower siblings like check_zoning_context or check_property, though no sibling is named explicitly.

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?

No guidance on when to use this versus the 15 sibling check_* tools, nor on prerequisites beyond the vague 'jurisdictions with a supported parcel source' qualifier. The agent must infer selection from the attribute list alone.

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

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

Annotations already cover the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely useful context beyond them: a specific $0.25 USD paid cost and the SF-jurisdiction limitation. It does not mention auth or rate limits, keeping it 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?

One sentence, cost and scope front-loaded, zero filler. Every clause (paid cost, verb, jurisdiction, resource, precondition) 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 not be explained, and cost/scope are covered. However, with four parameters at 0% schema coverage and no usage routing, an agent still lacks enough to compose a correct call confidently beyond the required address.

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% and all four parameters (address, city, unit, state) are undocumented anywhere. The description compensates only obliquely with 'for a resolved property', giving no format, granularity, or required-vs-optional insight beyond what the schema's type tags already show.

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 ('trace') plus a concrete resource ('building-permit review routing, departments, holds, timing, recorded review results'), which is more than the name's tautology. It implies SF-only scope, distinguishing it somewhat from siblings, but never names the tool it is not (e.g., check_permits or check_planning_activity).

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

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

There is no explicit when-to-use statement or named alternative. The phrase 'for a resolved property' is the only usage signal, hinting that a property must be resolved (likely via resolve_jurisdiction) before calling, which is implied rather than stated.

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), and the description adds genuinely non-structured behavior: a $0.10 USD cost, the "current official" data-freshness guarantee, and the dependency on a resolved property. It still omits what happens on failure or an unresolved address, so not 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?

Two short sentences with the price front-loaded and no filler — well structured for a terse tool card. Slightly under-specified rather than over-long, but nothing 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?

An output schema exists so return values needn't be described, but for a paid, open-world tool with 0% parameter documentation the card leaves real gaps: what "resolved" means and how to achieve it, and no routing to sibling checks. The cost and freshness notes are the only substantive additions.

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% across 4 parameters, so the description must compensate and it largely doesn't. "Resolved property" weakly implies the address is the key input, but it never explains why city/state/unit are separate or their formats.

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?

It names a resource ("official permit records") that is distinguishable from siblings like check_code_enforcement or check_zoning_context, but the verb "Reconcile" is ambiguous — it doesn't clarify whether the tool fetches, verifies, or diffs records. No explicit differentiation from the many other check_* tools is given.

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?

"For a resolved property" hints at a precondition but never states when to use this versus check_permit_routing, check_planning_activity, or the umbrella development_due_diligence. No when-not guidance, no mention of the resolution step the agent must perform first.

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, lowering the disclosure burden. The description adds one genuinely useful behavioral fact — a $0.25 USD charge per call — but says nothing about latency, data sources queried, or coverage limits, which matter for an open-world lookup.

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 with the cost front-loaded, so the agent sees the price before committing. No padding, though the extreme brevity is part of what leaves other dimensions underspecified.

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, but for a paid, open-world property lookup with four undocumented parameters, the description omits jurisdiction prerequisites, expected inputs, and any note about result coverage or confidence.

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% across four parameters, so the description must compensate and does not. It implies an address is the anchor but never explains the address/city/state/unit relationship, formatting expectations, or whether city/state are required for accurate matching.

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 ('planning applications and entitlement activity') scoped to 'a property'. This is reasonably distinguishable from siblings like check_permits or check_zoning_context, though 'reconcile' is a slightly fuzzy operation and the description never explains what reconciled output looks like.

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?

No when-to-use guidance, no conditions distinguishing it from localproof.check_permits, check_zoning_context, or development_due_diligence. The only guidance offered is the price, which tells the agent nothing about when this tool is the right choice.

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, open-world, and non-destructive, so the safety profile is covered. The description adds one genuinely useful non-annotated fact — the $0.25 USD cost — which is valuable for a paid tool, but says nothing about latency, source freshness, or failure modes.

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 with the cost front-loaded and no filler. Efficient, though the second sentence is too compressed to be informative.

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 enumerated, but for a paid, multi-parameter tool in a dense sibling family the description leaves the agent unable to judge scope or routing. It should at least distinguish this from the parcel/zoning context 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 0% across 4 parameters, so the description carries the full burden and provides no parameter meaning at all. It never mentions address, unit, city, or state, or explains that only address is required while the rest refine the match.

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 verb+resource ('resolve a property') and a vague output ('source-backed local-government context snapshot'), but does not say what property attributes or government context are returned. Against siblings like check_parcel_context, check_zoning_context, and check_property_changes, an agent cannot tell which to choose from this text alone.

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?

No when-to-use, when-not-to-use, or alternative-tool guidance is given. With 15 sibling tools covering overlapping property topics, the absence of routing guidance is a notable gap.

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, so the safety profile is covered. The description adds genuinely non-covered behavior: a $0.25 USD charge, deterministic change fingerprints, source-snapshot digests, explicit timestamp semantics, disclosed source gaps, and a next-monitoring handoff. That is real behavioral context beyond the 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?

It is a single sentence with no filler, and the cost and core action are front-loaded. However, the long tail of comma-separated feature nouns (fingerprints, digests, observational summaries, timestamp semantics, source gaps, handoff) is dense and hard to parse, reducing scanability.

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, yet the description enumerates outputs anyway while omitting the more important gaps: how to format address/since, and what 'resolved property' means operationally. Adequate for a read-only lookup but incomplete on input handling.

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% across 5 parameters, so the description must compensate and largely does not. It only gestures at 'since' as a caller-supplied timestamp; address, unit, city, and state semantics (e.g., whether unit is required for multi-unit buildings, whether city/state default to SF) are left entirely unexplained.

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 names a specific verb ('Find timestamped changes') and an explicit resource scope (released SF permit, planning, enforcement, and permit-routing records for a resolved property), which separates it from single-domain siblings like check_permits or check_planning_activity. It does not explicitly name the sibling it differs from, so it falls short of a 5.

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

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

'For a resolved property since a caller-supplied timestamp' implies a prior resolution step and a timestamp precondition, but there is no explicit when-to-use vs when-not guidance and no mention of the alternative aggregate tool check_local_changes. Usage is implied rather than stated.

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, idempotent, openWorld, and non-destructive traits, so the bar is lower. The description still adds real value: it discloses a $0.25 USD cost, source provenance from the Planning Department, and boundary limitations the caller should expect.

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 tight sentence with the cost front-loaded and no wasted clauses. Every element (price, scope, provenance, limitations) 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 needn't be explained, and provenance/limitations are noted. However, with 0% schema description coverage on four parameters, the definition leaves a real gap for a tool that costs money per call.

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% across four parameters (address, city, unit, state), so the description must compensate and does not. "Property point" faintly implies an address, but no format, required-combination, or default guidance is given for city/state/unit.

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 (Resolve) and resource (official San Francisco zoning and height-district context for a property point), plus what comes back (provenance, boundary limitations). It implicitly separates itself from neighbors like check_parcel_context or check_property by naming zoning/height districts, though it never explicitly contrasts with them.

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?

There is no when-to-use guidance and no mention of the sibling tools (check_parcel_context, check_property, development_due_diligence) that an agent might otherwise pick. The agent must infer usage entirely from the name.

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

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

Annotations cover the safety profile (readOnly, idempotent, openWorld, non-destructive), and the description adds real context beyond them: the $5.00 USD cost, that output explicitly surfaces completeness and source gaps, a provenance manifest, and interpretation boundaries. This meaningfully tells the agent what kind of result to expect; it does not, however, state payment/auth mechanics or failure 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?

A single sentence with the cost front-loaded, which is the right priority order. However, the remainder is a 40-plus-word noun-phrase pile rather than prose that distinguishes input constraints from output contents, so density substitutes for structure.

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 and the description still usefully characterizes the return package, so return values are covered. What is missing for a paid, complex aggregate is the operational envelope: whether the address must resolve to San Francisco, what happens when sources are unavailable, and how the 'machine-readable continuation calls' should be acted on.

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% across 4 parameters, so the description is the only place parameter meaning could be added, and it contributes nothing. Field names (address, city, state, unit) are largely self-evident, which keeps this above a 1, but there is no format, jurisdiction scope, or required-vs-optional 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 ('Build'), a named deliverable ('expanded San Francisco development due-diligence evidence package') and enumerates its contents, so an agent knows this is the heavy aggregate rather than a single-source check like check_permits. It stops short of naming a sibling to differentiate against, so it is clear but not maximally disambiguating.

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?

No explicit when-to-use, when-not-to-use, or alternative selection guidance. The $5.00 price is an implicit cost signal that a cheaper single-source sibling might suffice, but the agent receives no statement of the conditions that justify this tool over check_permits or property_intelligence_pack.

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=true, idempotent=true, and non-destructive, so safety is covered. The description adds one genuinely new trait, 'Free', which is cost behavior not captured in annotations. It does not disclose scope of what 'coverage' means or any rate/access 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?

Two short sentences with no filler, and the key differentiator ('Free') is front-loaded. Efficient, though terse enough to leave gaps the agent must fill on its own.

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 tool is a simple read. However, with three callable parameters and zero schema documentation, the description should at least say how city/state and jurisdiction_id relate, which it does not.

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% and the description mentions no parameters at all, so city, state, and jurisdiction_id are entirely undocumented. In particular the interaction between passing city/state versus jurisdiction_id is a real ambiguity with no 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+resource ('Return jurisdiction and source coverage') and frames itself against paid research. An agent can tell it is a free coverage-lookup without opening the schema, though it is not sharply distinguished from the nearby get_source_catalog sibling.

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

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

The phrase 'without running paid research' implies this is the cheap pre-flight option, but no explicit when-to-use or when-not-to-use guidance is given relative to siblings like get_source_catalog or resolve_jurisdiction. Usage is inferable, not stated.

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, so the safety profile is covered. The description adds the cost signal ('Free') and the idea of freshness expectations, but says nothing about pagination, rate limits, or what happens with partial jurisdiction input.

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, front-loaded with the cost qualifier and then the purpose. No padding, though the brevity contributes to the documentation gaps elsewhere.

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, but with three undocumented optional parameters and no guidance on how to supply a jurisdiction, an agent cannot reliably construct a call. The description under-serves the tool's actual input 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?

Schema coverage is 0% and the description never mentions city, state, or jurisdiction_id. It gives no guidance on whether they are alternatives, jointly required, or how to choose between them, leaving all three optional parameters semantically opaque.

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: returns public sources plus freshness expectations, scoped to a jurisdiction. It is reasonably distinguishable from siblings like check_* and get_source_health, though it never explicitly contrasts itself with resolve_jurisdiction or get_coverage.

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?

'Free.' signals cost but not when to call this versus resolve_jurisdiction, get_coverage, or get_source_health. No prerequisites, no exclusions, no alternative routing is 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 already cover read-only, idempotent, open-world, non-destructive semantics, so the bar is lower. The description still adds two pieces of context not in structured fields: the call is free (cost), and the response is a reachability report that deliberately omits source records, which prevents the agent from expecting catalog 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?

One tight sentence with no filler, front-loaded with the cost signal and the key scope constraint. It could still afford a clause on how to identify the jurisdiction given the parameter gap, but nothing 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?

An output schema exists, so return values need not be explained, and annotations carry the safety profile. The gap is the fully undocumented optional parameter set on a tool where the agent must decide how to target a jurisdiction, which the description does not resolve.

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

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

All three parameters have 0% schema description coverage, and the description does not name or explain city, state, or jurisdiction_id. 'For a jurisdiction' only loosely hints that a jurisdiction selector is required, leaving the agent to guess whether to pass city+state or jurisdiction_id and what happens when none are supplied.

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 (probe), resource (currently registered official sources), scope (for a jurisdiction) and output intent (report reachability). It implicitly distinguishes itself from the source-listing sibling by noting it does not return source records, though it never names get_source_catalog or get_coverage directly.

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 leading 'Free.' gives a cost cue and 'without returning source records' implies contrast with a catalog tool, but there is no explicit statement of when to use this versus get_source_catalog, get_coverage, or resolve_jurisdiction. Usage is inferable as a diagnostic probe but not spelled out.

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 read-only, idempotent, open-world, non-destructive behavior, so the safety bar is low. The description adds genuinely non-annotated context: a $1.00 USD cost, the multi-source reconciliation behavior, and that continuation/monitoring handoff calls are produced. It stops short of disclosing auth requirements, rate limits, or what a 'source gap' actually means in output.

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?

It is a single front-loaded sentence that leads with the price, which is good practice, but the trailing clause becomes a comma-spliced list of six deliverables that is dense and hard to scan. Efficient in length, weaker in structure.

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?

Because an output schema exists, return values need not be re-explained, and the description does convey what the package contains. However, for a paid, multi-source tool with four fully undocumented parameters and no routing against fifteen siblings, the definition leaves meaningful gaps an agent must guess at.

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% across four parameters (address, city, unit, state), and the description never references any parameter. It neither explains the required address format nor the role of unit/city/state as disambiguators, so it fails to compensate for the schema gap.

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 names a specific verb and resource ('Create a reconciled multi-source property intelligence package') and enumerates the artifacts it bundles (completeness, source gaps, provenance manifest, continuation calls, monitoring handoff). It is clearly a composite/aggregate tool, which distinguishes it implicitly from the atomic check_* siblings, but it never explicitly contrasts itself with them.

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?

There is no explicit when-to-use, when-not-to-use, or alternative routing. An agent cannot tell from the text whether to call this composite pack or the individual check_property / development_due_diligence tools, nor under what conditions the higher-cost pack is warranted.

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds the 'Free' cost disclosure, which is genuinely useful context beyond the structured fields, but says nothing about latency, coverage-miss behavior, or fallback when a jurisdiction is unresolved.

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 fragments with the cost signal front-loaded and no filler. Efficient, though the terseness is close to under-specification rather than true conciseness.

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 needn't be explained, but with 4 parameters at 0% schema coverage and no usage guidance against a large sibling set, the description is too thin for an agent to invoke it confidently.

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% across 4 parameters, so the description must compensate. It only gestures at 'address or place', leaving city, state, and unit undocumented in both schema and description, so an agent cannot tell how the extra fields interact with the required 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?

States a specific verb+resource ('Resolve ... to a LocalProof jurisdiction') plus the input (address or place) and the output (jurisdiction and coverage state). It is clear what the tool does, though it does not explicitly differentiate itself from the sibling get_coverage, which sounds related.

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?

No guidance on when to use this versus the many check_* siblings or get_coverage. 'Free' hints at cost but not at the decision of choosing this tool, and there are no prerequisites or exclusions stated.

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 openWorld. The description adds real behavioral value on top: a $2.50 USD cost, the 'without selecting a winner' constraint, and the shape of what comes back (completeness metadata, source gaps, provenance manifests). It does not mention auth requirements or rate limits, but the cost and output scope are meaningful additions.

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?

Cost and purpose are front-loaded, which is good, but the single sentence then trails off into a long enumerated list of output artifacts (bounded evidence highlights, completeness metadata, source gaps, provenance manifests, drilldowns) that partly duplicates what the output schema already covers.

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, the heavy output enumeration is largely redundant, while the genuinely missing pieces — how to choose this tool over the single-site siblings and what the input sites must contain — go unaddressed. Adequate but with clear gaps for a paid comparison 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 0%, so the description must carry the load. It conveys the cardinality (two or three sites) and implies SF-only addresses, but adds no format or meaning for the nested address/city/unit/label/state fields beyond their self-evident 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?

States a specific verb (compare) and resource (two or three candidate San Francisco sites) across named evidence dimensions, and adds the crucial scope qualifier 'without selecting a winner'. It is clearly distinct from single-property siblings like check_property, though it never names a sibling or addresses overlap with development_due_diligence or property_intelligence_pack.

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?

No when-to-use conditions, prerequisites, or alternatives are given. The agent is not told when this multi-site comparison is preferable to running the single-site check tools, nor what happens with fewer than two or more than three sites beyond the schema's min/max.

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