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

With no annotations, the description carries the full burden, and it delivers: it explains deterministic spatial evidence, the equirectangular grid and 199 permutations, raw cosine semantic evidence, the lack of a calibrated percentile, and the embedding-failure edge case preserving spatial evidence with semanticDistance.value=null. It also states clearly that the tool never makes a publish decision.

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?

Every sentence carries distinct information: purpose, methodology, sibling distinction, edge-case behavior, and safety boundary. The description is dense but not bloated, and the core purpose is front-loaded.

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

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

For a zero-parameter diagnostic tool with no annotations and no output schema, the description covers what is returned, how it is computed, the key edge case, the relationship to the publishable sibling, and the tool's non-decision authority. Nothing essential 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?

The tool has zero parameters, so parameter ambiguity is not an issue and the baseline is 4. The description reinforces that the tool is intentionally narrow (one pair, one county) rather than a general configurable API.

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 ('Return'), a specific resource ('bounded diagnostic occupied-grid-cell evidence'), and an exact scope ('one exact unordered taxonomy_primary pair in one published county'). It also distinguishes itself from the sibling discoverPlaceColocationCandidates by explicitly stating it is not the publishable source.

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

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

The description clearly implies when this tool is appropriate: for diagnostic, bounded, non-publishable evidence. It explicitly names discoverPlaceColocationCandidates as the publishable Class H source, which provides a strong routing signal, though it stops short of an explicit 'use this when, use that when' formulation.

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

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

With no annotations provided, the description carries the full disclosure burden, and it does so thoroughly. It exposes the fixed 800m universe, the stratified split, the cosine and percentile thresholds, the top-32 cap, the hypergeometric validation, Holm adjustment, and the important caveat that percentile is relative semantic distance and not a publish decision.

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

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

The description is dense and technical, but every sentence contributes specific thresholds, constraints, or caveats. It front-loads the core purpose and then builds into methodology and output, with minimal repetition. It could be slightly streamlined, but the length is justified by the complexity.

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

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

For a single-parameter tool with no annotations and no output schema, the description provides substantial context: it explains the discovery logic, filtering criteria, validation, and the general shape of the response. It stops short of specifying the exact response structure, pagination, or error behavior, which would make it fully complete.

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

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

The only parameter, county, has full schema description coverage with an example and format details. The description adds contextual references like 'county-wide' and 'county only response,' but it does not materially expand on what the county value should be beyond what the schema already 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?

The description opens with a specific action and resource: 'Discover a bounded county-wide family of Overture taxonomy_primary co-location candidates.' It goes well beyond a tautology and includes algorithmically distinctive details, but it does not explicitly contrast this tool with the sibling analyzePlaceColocation, so differentiation is more inferred than stated.

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

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

The description strongly implies the use case: discovering county-wide co-location candidates. However, it never explicitly states when to prefer this tool over alternatives such as analyzePlaceColocation or queryPlaces, nor does it provide any exclusions or when-not-to-use guidance.

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

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

With no annotations, the description carries the full burden and handles it well: it reveals server-side behavior (allowlisting fields/operators/grouping/measures/budgets, compiling identifiers, binding values), explicitly forbids mutations and raw SQL, and enumerates return fields (numerator, denominator, support, null completeness, median, canonical hashes, provenance). It does not cover error behavior or auth requirements, but still provides substantial behavioral transparency.

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

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

Four sentences, each earning its place: core purpose, server-side validation behavior, caller restrictions, and return fields. The most important operational fact is front-loaded, and there is no redundant or vague filler.

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

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

For a complex nested plan with no output schema and no annotations, the description adequately covers behavioral constraints and the return payload. Yet it lacks guidance on constructing a valid plan (required fields, defaults, measure object shapes) and does not connect to related tools such as getDatasetQueryCapabilities or the query schea tools, leaving the agent to infer how to assemble a query plan from scratch.

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

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

Schema description coverage is 0%, so the description must compensate. It does mention plan ingredients—fields, operators, grouping, measures, row/group/time budgets—and clarifies that the server compiles identifiers and bounds values. However, it does not explain the plan object's required properties (contractVersion, dataset, county, measure, budgets), the meaning of scopeFilters, groupBy, or order, or the accepted measure variants. It partially compensates but leaves many semantics to schema inference.

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

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

The description opens with a specific verb and resource: 'Execute one typed, bounded aggregate plan over a county's property or permit query table.' It further distinguishes the tool from siblings by explicitly excluding SQL, URLs, joins, projections, expressions, and raw-row queries, making clear that this is the constrained aggregate-plan executor rather than a general query 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?

There is no explicit statement of when to use this tool versus siblings like queryProperties, queryPermits, or getDatasetQueryCapabilities. The context is implied by 'typed, bounded aggregate plan', and the statement that callers cannot provide raw-row queries implies it is not for raw row retrieval, but no direct alternatives or conditions are named.

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

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

No annotations are present, so the description carries the burden of behavioral disclosure. It reveals that matching is based on centroid inclusion, that it reads a per-county property query table with a fallback to a derived geo index, and that it ignores NOAA/FEMA geometry. These details add meaningful behavioral context beyond the schema, though some edge-case behavior such as error handling or empty results is not covered.

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

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

The description is compact and front-loaded: it states the output and core filtering logic first, then the exclusive-or constraint, then the data-source nuance. Every sentence carries useful information without redundancy.

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

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

Given the tool's moderate complexity, the description covers the main decision points: what is returned, how geometry is interpreted, which data sources are used, and how the two geometry parameters relate. Since there is no output schema, explicitly stating that it returns a set of properties is helpful. It could mention return format or empty-result behavior, but that is a minor gap.

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

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

The schema already has 100% parameter coverage, so the baseline is 3. The description adds useful semantic value by enforcing the mutually exclusive choice between bbox and polygon and clarifying the optional/inferred behavior of county, which goes beyond the raw schema descriptions.

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

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

Description names a specific verb and resource: it returns the set of properties matching a spatial centroid predicate. It also distinguishes itself from sibling tools by emphasizing the bounding-box/polygon filter and by stating that no NOAA/FEMA geometry is used.

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

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

Provides explicit usage instruction: 'Provide exactly one of bbox or polygon.' It also explains the conditional need for the county parameter depending on deployment. It does not explicitly name sibling alternatives or when to prefer this over queryProperties/sumPropertyValueInArea, so it stops short of a 5.

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

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

With no annotations, the description carries the full burden. It discloses key behaviors: returns only allowlisted non-PII metadata, no source rows, no SQL/data URL. This goes beyond a generic 'get capabilities' line and informs the agent about safe, non-row-returning behavior, though it doesn't explicitly state auth, rate limits, or side-effect-freedom.

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 compact sentences. The first sentence front-loads the resource and scope, and the second sentence lists boundary conditions with no filler. Every clause adds useful information.

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

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

For a one-param, no-output-schema tool, the description is nearly complete: it names the input and explains the return categories and rejection behavior. It could be more complete by noting how this relates to the sibling query-schema tools, but it is sufficient for correct invocation.

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

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

Schema description coverage is 100%, and the schema already documents the county param with pattern, length, and example. The description adds the framing that it covers a county's property and permit datasets, but doesn't provide additional parameter semantics beyond what the schema property description already 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?

The description uses a specific verb-resource pair: 'Describe bounded aggregate query capabilities for a county's property and permit datasets.' It also enumerates what is returned (allowlisted non-PII fields, types, operators, measures, null semantics, hard budgets, query-table identity) and explicitly says it returns no source rows and accepts no SQL, which distinguishes it from query-execution and row-returning siblings.

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

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

The description clearly implies when to use: when you need query capability metadata for a county's property/permmit datasets. It also gives a boundary by stating it returns no source rows and accepts no SQL/data URL, which implies other tools handle execution. However, it doesn't explicitly name sibling alternatives or provide when-not-to-use guidance.

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

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

With no annotations to lean on, the description carries full behavioral burden and does so thoroughly. It reveals that propertyCount can be either a catalog-bound count or a live query-table count, that provenance/CID fields appear only on the legacy path, that per-source coverage is conditional, and that coverage-only counties return propertyCount null with propertyDatasetAvailable false. This lets callers interpret partial results correctly.

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

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

The description is front-loaded with the core purpose and then proceeds from common return fields to conditional expansions to the special coverage-only case. Every sentence carries distinct information, and there is no filler or restatement of the tool name.

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

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

Given the absence of an output schema and annotations, the description is remarkably complete: it names the return fields, explains the two computation paths for propertyCount, details the per-source datasets array, and explicitly covers the null-property count edge case. An agent could confidently interpret the response without additional context.

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

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

There is only one parameter, county, and the schema already describes it including case-insensitivity, so schema coverage is effectively 100%. The description reinforces that output is per-county but does not add new semantic detail about the parameter itself; baseline 3 is appropriate.

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

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

The description states a specific verb and resource: 'Returns dataset-level metadata for a county.' It enumerates the returned fields and conditional variants, making it clearly distinct from sibling tools that retrieve individual properties, schemas, permits, or query plans.

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

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

The description clearly implies it is the tool for county-level dataset metadata and explains conditional behaviors, but it never explicitly says when to use this tool instead of a sibling like getOracleProperty or getPropertySchema. No alternatives or exclusions are named, so usage guidance is only implied.

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

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

No annotations are provided, so the description carries the full behavioral disclosure burden. It does reveal that the tool fetches from IPFS, returns a consolidated JSON, and requires exactly one of three identifiers. But it does not disclose failure modes, not-found behavior, or what happens if the county parameter is omitted or combined with an identifier.

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

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

The description is compact and front-loaded: the primary action and resource appear first, followed by the key invocation rule. Every sentence earns its place with no redundant or filler content.

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

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

For a read-only fetch tool with no output schema, the description names the returned artifact and its composition, and the input schema covers parameter details. The main gap is the lack of explicit error/not-found behavior and clarification of how county interacts with the three identifier options.

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

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

Schema coverage is 100%, so the baseline is 3. The description adds value beyond the schema by stating the mutual-exclusivity rule ('exactly one of parcelIdentifier, propertyId, or cid'), which the schema does not express through required fields or oneOf constraints. It also implies county is optional context.

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

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

The description uses a specific verb ('Fetch') and names a concrete resource ('full consolidated property JSON') with its contents (appraisal, permits, Sunbiz, BBB). This clearly distinguishes it from permit-only siblings like getPropertyPermits, though it does not explicitly name sibling alternatives.

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

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

The description gives an explicit invocation constraint ('Provide exactly one of parcelIdentifier, propertyId, or cid'), which is valuable usage guidance. However, it does not explicitly state when to use this tool versus sibling tools like queryProperties or listOracleProperties, leaving the when-to-use distinction mostly implied by the word 'consolidated'.

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

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

With no annotations provided, the description carries the full burden, and it does well by disclosing the underlying data source, the aggregation behavior, and important caveats about data lag and NULL dates. It does not mention permissions, response shape, or ordering, but for a simple read-only coverage query the key behavioral traits are transparent.

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

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

The description is two sentences with no wasted words. The first sentence front-loads what the tool returns and the second provides valuable usage context. Every sentence earns its place.

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

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

For a one-parameter tool with no output schema, the description is largely complete: it states the input, the output fields, the source table, and the motivating use case. It could be slightly stronger by specifying the exact response structure or how NULL dates are represented, but nothing critical is missing for correct selection and invocation.

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

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

The schema already covers the single 'county' parameter at 100% with a clear example and case-insensitivity note. The description adds no additional parameter-level meaning, so the baseline score of 3 is appropriate.

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

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

The description uses a specific verb ('Returns') and names the exact resource: per-source-system permit coverage for a county from the 'permits' query table. It enumerates the outputs (source_system, permit_count, completion_date range, overall total), which clearly distinguishes it from sibling tools like queryPermits or getPropertyPermits that focus on individual permit records rather than aggregate 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?

The description gives clear context for when to use this tool: when the agent needs to QUALIFY aggregate permit answers, because permit data lags appraisals and some sources may have NULL dates. It does not explicitly name alternatives or state when not to use it, so it falls short of a 5, but the usage context is clear enough for an agent to select it appropriately.

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

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

With no annotations provided, the description carries the behavioral disclosure burden. It discloses the exact return content and adds a useful data-quality caveat that date/value fields are frequently null depending on permit source. It does not discuss error handling or permissions, but for a metadata-read operation this is acceptable.

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

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

Two sentences with no redundancy: the first leads with the action and return contents, the second supplies a relevant caveat. Every sentence earns its place.

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

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

For a single-parameter metadata tool with no output schema, the description is complete: it states the input, the return contents, and a key behavioral caveat. The sibling list includes listPublishedCounties, but omitting that as a prerequisite is a minor gap.

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

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

The only parameter, county, is already fully documented in the schema with minLength, case-insensitivity, and an example. The description reaffirms that county selects the permits query table but adds little semantic value beyond the schema, so the baseline of 3 applies.

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

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

The description uses the specific verb 'Returns' and precisely specifies the resource: the 'permits' query table's column list, DuckDB types, and one-line descriptions, scoped by county. It also states the intended use ('so queryPermits can be written without guessing'), which distinguishes it from sibling schema tools like getPropertyQuerySchema and getPlaceQuerySchema.

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

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

It explicitly ties the tool to queryPermits, signaling the agent to call this before writing permit queries. It does not list alternatives or exclusions, but the 'for a county' scoping and queryPermits reference provide clear usage context.

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

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

No annotations are provided, so the description carries the full burden. It discloses that this is an introspection/metadata operation, mentions safety limits, license-gate metadata, and even 'honest null completion semantics.' It could add auth/rate-limit details, but for a schema-lookup tool it is notably transparent.

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

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

The description is a single information-dense sentence with the key object front-loaded. The long enumeration of metadata types is slightly run-on, but every listed element contributes to the agent's understanding.

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?

Even without an output schema, the description thoroughly catalogs what will be returned: columns, descriptions, contract, limits, release/provenance, license metadata, and null semantics. The required parameter is fully covered by the schema. Minor gaps like output shape and failure behavior do not undermine selection or invocation.

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

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

The single parameter 'county' is already fully documented in the input schema (format, example, constraints). The description only reinforces 'for a county' without adding new parameter-level meaning, so the baseline score of 3 applies.

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

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

The description opens with a strong verb, 'Returns', and names a highly specific resource: published places parquet columns, field descriptions, the queryPlaces contract, safety limits, and metadata. This clearly distinguishes it from property/permits query-schema siblings.

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

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

The description makes the usage context clear: it is for county-level published places schema information and explicitly ties to the queryPlaces contract. It does not include explicit exclusions or list alternatives, but the resource naming makes when-to-use unambiguous.

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

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

No annotations are provided, so the description carries full responsibility for behavioral disclosure. It does so thoroughly: it discloses caching, the asynchronous harvest enqueing side effect, IPFS storage after completion, and the polling requirement. This is well beyond what the schema or title would imply.

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

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

Three sentences, each carrying distinct value: what it fetches, the caching/async behavior, and the persistence layer. The most important action and condition are front-loaded; 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?

The tool has no output schema, but the description explains both possible outcomes (cached permits versus in-progress status) and gives the timing for polling. This is sufficient for an agent to invoke it and interpret the result without additional hidden assumptions.

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

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

Schema description coverage is 100%, so the schema already explains both parcelId and countyFips with examples and defaults. The description adds only 'by parcel ID' but does not materially extend parameter semantics beyond the schema.

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

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

Starts with a specific verb and resource: 'Fetch permit records for a property by parcel ID.' It clearly defines the scope (property-level) and the primary key (parcel ID), which distinguishes it from sibling query-oriented tools such as queryPermits.

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?

Gves a clear operational contract: returns cached data immediately, otherwise enqueues a harvest job and tells the caller to poll again after ~90 seconds. It does not explicitly contrast with sibling tools like queryPermits or getPermitCoverage, but the intended usage context is clear.

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

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

With no annotations present, the description carries the behavioral burden. It clearly states the operation is read-only ('Returns'), lists what will be returned, and adds a concrete caveat that some coverage-dependent fields may be NULL. It does not detail error handling or prerequisites, but for a simple schema introspection tool this is sufficient.

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

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

Two sentences front-load the return value, state the intended use, and end with a caveat, with no filler or repetition of the name/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?

For a one-parameter, no-output-schema tool, the description covers what is returned, why it should be used, and a relevant nullability caveat. An agent can select and invoke it correctly for its intended purpose without needing additional context.

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

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

The single county parameter is already fully described in the schema, including case-insensitivity and an example; the description adds no new parameter-level detail, so it earns the baseline 3 for high schema coverage.

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

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

The description opens with the specific verb 'Returns' and names the exact resource: column list, DuckDB types, and one-line descriptions for the 'properties' query table per county. It also ties the tool to the sibling queryProperties, so it is clearly distinct from related schema tools like getPropertySchema or getPlaceQuerySchema.

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 'so queryProperties can be written without guessing' is a clear context cue to call this before composing a queryProperties call. It does not, however, name alternatives or explicitly state when not to use it, so it stops short of full 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?

There are no annotations, so the description carries the full burden for behavioral disclosure. It does communicate that the tool is a read operation returning a full JSON Schema object, but it doesn't mention error handling, case-insensitivity, authorization requirements, or any limitations. This leaves important behavioral context undisclosed.

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

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

The description is a single concise sentence that front-loads the primary behavior. It contains no filler or redundant restatement of the tool name.

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

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

For a simple two-parameter lookup with high schema coverage, the description plus schema is largely sufficient. However, with no output schema and no annotations, the tool doesn't explain failure behavior or how this differs from the similarly named getPropertyQuerySchema. The definition is adequate but leaves some context for an agent to infer.

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

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

The input schema has 100% description coverage, including case-insensitive semantics for both parameters. The description itself adds no parameter-level detail beyond identifying a 'class property,' so it does not improve on the schema. A baseline 3 is appropriate because the schema already documents the parameters well.

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

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

The description states a specific verb and resource: it 'Returns the full JSON Schema object for a class property.' It distinguishes itself from most siblings by emphasizing the returned artifact. However, it doesn't clarify how this relates to similar sibling tools like getPropertyQuerySchema, so it is clear but not fully differentiated.

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 is provided about when to use this tool versus alternatives such as listPropertiesByClassName or getPropertyQuerySchema. The description implies a lookup operation but gives no conditions, prerequisites, or exclusions, which is a meaningful gap given the large sibling tool set.

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

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

No annotations are provided, so the description must carry the full behavioral burden. It only says 'Get most relevant working examples' and does not explain what 'verified' means, how results are ranked, what the response contains, or any limitations.

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

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

The description is one sentence, front-loaded with the core action, and has no filler. It is slightly awkward grammatically, but it is appropriately concise.

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

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

For a simple two-parameter search tool, the description and schema are enough to make a basic call. However, with no output schema and no annotations, the description does not clarify what the returned examples look like, how 'verified' is determined, or how topK affects the retrieval, leaving notable gaps.

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 both 'query' and 'topK' are already documented in the input schema. The tool-level description adds useful context that examples map data to the Elephant schema, but it does not provide deeper parameter semantics beyond the schema.

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

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

The description uses a specific verb ('Get') and resource ('verified script examples') and adds the scoping detail that the code maps data to the Elephant schema. It is clear enough to identify the tool's purpose, though it does not explicitly contrast it with sibling query 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?

There is no guidance on when to use this tool versus the many sibling list/query tools, and no mention of alternatives or exclusions. The agent must infer when this retrieval tool is appropriate.

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

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

No annotations are provided, so the description carries the behavioral burden. The verb 'List' implies a read-only operation and the phrase 'with names and descriptions' discloses the expected output shape. However, the description says nothing about ordering, pagination, error behavior, or what happens for invalid/unknown data groups.

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

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

The description is one sentence, front-loaded with the action and resource, and contains no wasted words. It is efficient, though the singular 'Elephant' jargon could have been defined without harming 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?

For a tool with one required parameter, 100% schema coverage, and no output schema, the description covers the essential invocation and return content. It lacks an example of a valid data group and does not specify error handling, but the operation is simple enough that this is a minor gap.

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

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

The schema already fully describes the only parameter groupName, including its case-insensitive behavior, so schema coverage is 100%. The description adds no parameter-specific meaning beyond reusing the term 'data group'; there are no examples, constraints, or format hints beyond the schema.

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

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

The description uses a specific verb ('List') and resource ('classes for an Elephant data group'), and even indicates the returned content ('names and descriptions'). It does not explicitly contrast itself with sibling list tools like listPropertiesByClassName, but the resource and grouping concept make the core purpose 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?

No guidance is given for when to choose this tool over alternatives such as listPropertiesByClassName, listPublishedCounties, or queryClasses. The intended context can be inferred from the tool name, but the description does not state it or name any exclusions.

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

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

With no annotations, the description carries the behavioral disclosure burden and does disclose pagination, slim vs summary field composition, and a conditional 'query table' behavior. However, it does not explicitly state read-only/side effects or clarify what 'served from the query table' means, leaving some behavioral ambiguity.

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 dense sentences with no filler. The action, scope, output highlights, and alternative tool are all front-loaded and each 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?

For a list tool with no output schema, the description provides enough return-field detail and pagination context to guide invocation. Minor gaps—the meaning of 'query table' and explicit confirmation of read-only behavior—prevent a perfect score.

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

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

Schema description coverage is 100%, with defaults and constraints already documented for limit, county, and offset. The description adds contextual emphasis on county filtering and pagination but no new parameter-level meaning beyond the schema, so 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+resource scope: paginated discovery of properties for a county. It also names the output content and explicitly contrasts with getOracleProperty, making the tool readily distinguishable from its sibling get-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?

Clearly tells the agent to use getOracleProperty when full consolidated data for a specific entry is needed, which is an explicit routing instruction. It does not discuss broader listing/query siblings like queryProperties, but the primary alternative is well covered.

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

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

With no annotations, the description carries the behavioral disclosure burden. It adds a meaningful detail ('excludes source_http_request') and signals a read-only list operation via 'Lists'. However, it doesn't describe behavior for nonexistent classes, ordering, or the exact response format.

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

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

A single sentence that front-loads the action and object, with the key exclusion parenthetically appended. Every word earns its place and there is 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?

For a simple listing tool with no output schema, the description conveys the core return value and a key exception. However, absent annotations, it doesn't cover edge-case behavior (e.g., unknown class names) or explicitly describe the response shape beyond 'property names', leaving some gaps.

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

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

The input schema fully documents the single parameter (className: string, minLength 1, case-insensitive), so schema description coverage is 100%. The description adds no extra parameter meaning beyond what the schema already 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?

The description uses a specific verb ('Lists'), identifies the exact resource ('JSON Schema property names for an Elephant class'), and explicitly notes an exclusion ('excludes source_http_request'). This clearly distinguishes it from sibling tools like listClassesByDataGroup or getPropertySchema.

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

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

The description implies the tool is used when you need property names for an Elephant class, but it does not explicitly state when to prefer it over alternatives or when not to use it. The context is clear, but no alternatives or exclusions are mentioned.

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

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool returns every county, identifies the catalog as canonical, lists the included fields, and notes that placesTableUrl is nullable. This is strong transparency for a zero-parameter read-only list operation, though it does not mention sorting, pagination, or response size.

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

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

The description is two sentences and every sentence earns its place. The first sentence states what the tool returns; the second sentence gives usage guidance. It is front-loaded with the core behavior and contains no filler.

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

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

For a zero-parameter, no-output-schema list tool, the description is complete. It explains what the returned data contains, mentions nullable fields, and provides a concrete use case. No additional context is needed for an agent to invoke this tool correctly.

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

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

There are zero parameters, and schema coverage is 100% with no properties. The baseline for zero parameters is 4, and the description appropriately adds no parameter-specific semantics because none exist.

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

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

The description clearly states the tool returns every county in Oracle's canonical published-county catalog, enumerating the contained fields. It distinguishes itself from sibling tools by focusing specifically on the published-county catalog list, which none of the siblings do.

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

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

The description explicitly says to use this tool to discover newly published counties and places availability instead of maintaining a hard-coded list. This gives the agent a clear decision rule for when this tool is appropriate, even though no sibling tool is named as an alternative.

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

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

With no annotations, the description carries the full burden, and it does so thoroughly: it discloses read-only behavior, allows a leading WITH/CTE, lists rejected mutating and file/extension keywords, and states the 1000-row result cap. This gives the agent a clear safety envelope before calling.

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

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

The description is compact and front-loaded: purpose first, then companion tools, then safety rules. Every sentence earns its place, and the safety constraints are grouped in a single clearly labeled sentence rather than buried in 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?

For a SQL tool with no annotations and no output schema, this is complete: it explains the data source, tells the agent how to learn the columns, warns about aggregates/source qualification, and fully specifies the allowed SQL envelope and row cap. The agent has everything needed to call and interpret results correctly.

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

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

The schema already documents all three parameters at 100% coverage, so the baseline is 3. The description adds value beyond the schema by defining the SQL constraint surface (single SELECT, WITH allowed, prohibited keywords) and pointing to getPermitQuerySchema for available columns, which enriches the meaning of the sql and limit parameters.

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

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

The description states a specific verb and resource: run a read-only SQL SELECT against a county's permits view backed by embedded DuckDB. It also clarifies the data grain (one row per building permit) and names the relevant companion tools, so it is unmistakably distinct from property/place query siblings.

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

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

It clearly tells the agent to call getPermitQuerySchema first to discover columns and getPermitCoverage to qualify aggregate answers, which is practical usage context. It does not explicitly state when NOT to use this tool versus queryProperties/queryPlaces, but the purpose and preconditions are strong enough to route correctly.

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

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

With no annotations provided, the description carries the behavioral burden and does so well: it state read-only, catalog-authorized scope, deterministic paging with totalCount, count-only mode, grouped aggregates, the prohibition on raw SQL/data URLs, and the 1000-row cap. These are genuine behavioral disclosures beyond the schema.

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

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

The description is front-loaded with the primary purpose and then compresses many capabilities into one dense sentence. Every sentence contributes: purpose, feature summary, prerequisite, and constraints. It is concise but the long capability list is dense enough that it could be slightly easier to scan.

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

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

Given a complex query tool with no output schema and no annotations, the description covers modes, filter dimensions, count/aggregate behaviors, paging determinism, sequencing, and hard limits. It does not spell out the row return shape, but with 86% schema coverage and the feature summary this is still adequately complete.

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

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

Schema description coverage is 86%, and the schema already gives per-parameter descriptions, enums, defaults, and constraints. The description summarizes capabilities (category filters, hierarchy roll-ups, modes) but does not add per-parameter semantics beyond schema; 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?

Description opens with a clear verb + resource: 'Run a structured read-only query over a county's catalog-authorized Overture places parquet.' This distinguishes queryPlaces from property/permit query siblings by resource and read-only intent. The title and first sentence align with no ambiguity.

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 gives explicit sequencing guidance ('Call getPlaceQuerySchema first') and clear constraints ('Callers cannot provide SQL or data URLs; results are capped at 1000'). It does not explicitly name sibling alternatives or say when not to use this tool, but the Overture places resource makes the intended use case evident alongside queryProperties/queryPermits.

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

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

With no annotations provided, the description fully discloses the safety behavior: only single SELECT statements are accepted, leading WITH/CTE is allowed, mutating and file/extension keywords are rejected, and results are capped at 1000 rows. This gives an agent strong grounding for safe invocation.

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

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

The description is compact and front-loaded with the core purpose, followed by a clearly labeled SAFETY section. Every sentence earns its place, and the keyword list is necessary for correct use of a SQL query tool.

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

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

Despite having no output schema, the description tells the agent what table to query, how to discover columns, what SQL is permitted, and the hard row limit. This is sufficient for an agent to select and invoke the tool correctly without additional documentation.

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

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

The input schema already covers all parameters at 100%, so the baseline is 3. The description adds meaningful semantic detail about the sql parameter's allowed statement form and rejection keywords, and reinforces the limit parameter's enforced cap, going slightly beyond the schema.

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

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

The description clearly states the tool runs a read-only SQL SELECT against a county's 'properties' view, backed by embedded DuckDB. It names the specific resource and includes a pointer to getPropertyQuerySchema for columns, helping distinguish it from sibling query tools like queryPlaces and queryPermits.

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

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

It provides a clear prerequisite: use getPropertyQuerySchema first to see available columns. It also establishes the scope of use by restricting queries to a single read-only SELECT over the properties table, though it does not explicitly enumerate when to prefer sibling tools.

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

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

With no annotations available, the description carries the full behavioral disclosure burden. It adds meaningful traits beyond the schema: null valuations are treated as 0, the result includes a count, and the tool reads from a per-county property query table with a fallback to a derived geo index. It does not detail error behavior or output type, but the core behavioral expectations are covered.

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

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

The description is two senences with no filler, front-loading the core return value and geometry contract. The null-handling and data-source notes are useful and compactly stated.

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

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

Given no output schema, the description adequately states what is returned: the sum and the in-area count. It also covers key input constraints, null behavior, and fallback behavior. It does not mention edge cases such as empty result sets or invalid polygons, but the core information needed for correct invocation is present.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds non-obvious parameter semantics: exactly one of bbox or polygon must be used, and the geometry filter is based on centroid fallback rather than arbitrary overlap. It also clarifies that the county parameter may be inferred in single-county deployments.

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 and resource: it returns the exact sum of avm_value over properties whose centroid falls inside a user-supplied bounding box or polygon, plus the in-area count. This clearly separates it from sibling tools like findPropertiesInArea or queryProperties, which are oriented toward finding or listing properties rather than aggregating values.

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

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

The description explicitly instructs the agent to provide exactly one of bbox or polygon, which is essential for correct use. It also clarifies the centroid-containment rule and the read path. It does not explicitly name alternatives or state when not to use this tool, but the aggregation purpose makes the intended context reasonably clear.

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