SENTINEL Washington Real Estate

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

Annotations declare readOnlyHint=true and openWorldHint=false, which the description is consistent with. Beyond that it discloses real behavioral context an agent can't get from annotations: business-day counting excludes weekends and RCW 1.16.050 holidays, dates are form DEFAULTS derived from public rules rather than NWMLS data, results flag non-business-day landings, and both the attributions array and the professional-advice disclaimer must be passed through to users.

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

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

Front-loaded with the core computation and the covered forms, then the business-day rule, then caveats. Dense but every sentence carries operational weight (jurisdiction, defaults, pass-through requirements); a slightly tighter phrasing of the attributions/disclaimer directive would earn a 5.

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 structure needn't be spelled out, yet the description still calls out the two user-facing pass-through obligations (attributions, professional-advice disclaimer). For a rules-based read-only calculator, nothing an agent needs to invoke or relay results correctly is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented in the schema and that sets the baseline at 3. The description adds conceptual context (defaults vs. executed-contract terms, business-day arithmetic) but no per-parameter detail beyond what the schema supplies.

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 ('Compute') and a clearly defined resource (the standard NWMLS deadline set from a mutual-acceptance date), and enumerates the exact forms covered (21, 17, 22T, 35, 22A, 22E). No sibling tool computes deadlines, so it is unambiguous against the wa_* analytics 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?

Gives a clear applicability boundary ('Washington/NWMLS transactions only') and a methodological directive ('never plain calendar arithmetic'), which tells the agent when this tool rather than generic date math is appropriate. It stops short of naming alternatives or enumerating when-not-to-use beyond the jurisdiction limit.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds real value beyond that: it discloses the analytical stance (no auto-recommendation, no closing prediction) and mandates pass-through of the 'attributions' array and professional-advice disclaimer — the kind of downstream obligation an agent would otherwise miss.

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 compact sentences, front-loaded with the action and its inputs, followed by behavioral guardrails and the output obligation. No filler; each sentence carries a distinct load.

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 explanation is largely unnecessary, and the description correctly flags the attributions/disclaimer pass-through. However, for a computation tool with six top-level parameters at 17% schema coverage, the absence of any guidance on county, HOA flag, or multi-offer limits leaves real 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 only 17%, so the description carries a heavier burden. It maps conceptually onto concessions, financing_type and contingencies and gestures at seller proceeds (implying mortgageBalance, commissionRate, propertyTaxProration), but never explains county, hasHoa, earnest_money, or the 2–5 offer cardinality constraint.

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?

Names a specific verb and resource ("Compare buyer offers") and enumerates the comparison basis: seller proceeds, concessions, financing and contingency terms. It is readily distinguishable from wa_compare_seller_scenarios by scope, though the description never names that sibling 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?

The description sets useful interpretive limits — do not treat highest price as an automatic recommendation, do not predict closing — which tells the agent how to frame the output. But it gives no explicit when-to-use/when-not and does not route to any alternative (e.g. wa_compare_seller_scenarios or wa_net_sheet) despite 16 siblings.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds valuable behavioral detail beyond annotations: it returns an 'attributions' array and a professional-advice disclaimer, and instructs that both must be passed through to end users.

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, front-loaded with the core purpose and return behavior. The disambiguation and compliance sentences each add useful information; no filler is present.

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

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

Because an output schema exists, the description need not explain return values in detail, but it still highlights the attributions and disclaimer requirements. The main gap is parameter guidance for county and scenarios, though the schema itself supplies structure and nested field constraints.

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?

Top-level schema description coverage is 0%: neither 'county' nor 'scenarios' is explained in the description. The description vaguely references 'explicit seller cost assumptions' but does not clarify what county should contain or how scenario fields relate, leaving the reader to rely entirely on 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 ('Compare') and resource ('multiple proposed sale prices' / seller scenarios), and says it returns itemized proceeds plus the difference between scenarios. It distinguishes itself from valuation tools by stating 'Prices are supplied scenarios, not valuations,' though it does not explicitly contrast with sibling tools like wa_net_sheet or wa_compare_offers.

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 a clear usage context: compare proposed sale prices under explicit seller cost assumptions. It adds a helpful exclusion ('not valuations'), but does not name alternative tools or say when another sibling would be more 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?

Goes far beyond the readOnly/openWorld annotations: discloses the county coverage boundary, that Snohomish has no size/beds and month-level dates, that King condos may lack size and location, that statistics are not an appraisal, that a miss is not charged, and that attributions and a disclaimer must be passed through. That is exactly the operational context an agent needs 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?

Front-loads the search modes and the result contents before the caveats and pass-through instructions, so the essentials come first. It is dense and semi-colon heavy, with mild redundancy between the '(chart.points, chart.monthly_median) and chart.image_url' listing and the later 'draw it from the series, or link chart.image_url' instruction, but nearly every sentence carries information given the tool's 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?

An output schema exists, yet the description still summarizes what comes back (sales, medians/quartiles, half-over-half trend, price band, chart series and image URL), and it covers the data-quality caveats and attribution obligations the schema cannot express. Nothing an agent needs to call and present results correctly is missing.

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

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

With only 33% schema coverage across 21 params, the description compensates well: it defines the four area modes (address+radius, latitude/longitude point, polygon of [lat, lon], ZIP), the 1-36 month window, the filter set (beds, baths, sq ft, year built, price, property type) and the purpose of subjectSqft for the price band. It leaves limit, county and the radiusMiles default to the schema, which already documents them.

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?

Opens with a specific verb+resource (find recorded home sales) and enumerates the three ways to define the search area. It clearly distinguishes itself from siblings like wa_sale_history or wa_market_snapshot by centering on comps around a subject property plus a chart for a pricing conversation.

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

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

Gives concrete use cases ('what did 3 bed homes near this street sell for in the last year', 'what should we list at') and instructs the agent to show the chart and quote numbers exactly. It does not explicitly name a sibling tool to use instead when the agent wants raw history or a market-wide trend, so routing 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 establish readOnlyHint=true and openWorldHint=false, so the safety bar is low; the description still adds real context: sources have independent coverage, timestamps and required attributions, which warns the agent about mixed provenance and licensing obligations. It also flags interpretation limits (no attendance, quality or walking time). Missing details like result caps or per-source failure behavior keep it at 4.

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

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

Roughly 90 words with the three data domains front-loaded and no filler sentences. The middle is heavily packed into comma-chained clauses, which costs some scannability but every sentence carries 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 10-parameter, multi-source tool with an output schema present, the description covers what is fetched, the geography selector, the pairing constraint, filter logic, provenance caveats and explicit non-goals. Return-value explanation is not needed given the output schema. 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 only 30%, so the description carries real burden, and it does clarify pairing rules, exact four-digit schoolCode and the all-must-match filter combination. However transitRadiusM, limit and the role of 'supported research identifier' (businessUbi/parcelNumber) are left unexplained in prose, and parcelNumber's county=King dependency is only in the schema. Adequate but incomplete compensation for the coverage 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 three concrete resources with their grains: Census housing tenure estimates by ZIP/ZCTA, published Metro boarding stops by coordinate, and OSPI language programs by county, district or schoolCode. That is specific verb+resource detail an agent can act on. It never names the sibling it competes with (e.g. wa_site_context or wa_property_lookup), so routing is left partly to inference.

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

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

It states the input precondition clearly ('Supply a geography, schoolCode or supported research identifier; latitude and longitude must be paired') and the AND-semantics of school filters ('Combined school filters must all match'). It also gives an explicit exclusion set ('Does not determine school attendance, quality, neighborhood suitability or walking time'). No alternative tool is named for overlapping needs, which keeps it short of a 5.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds materially more — the tool is currently paused and will answer SOURCE_UNAVAILABLE uncharged, results carry a mandatory attribution array and disclaimer that must be reproduced, and the data has an explicit freshness period. Those are operational facts the agent cannot infer from 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?

Purpose and metric list are front-loaded, and nearly every sentence carries distinct information (routing, exclusions, pause state, attribution duty). It is a long single block, though; the attribution and disclaimer clauses could be compressed without loss.

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 description needn't explain return shape — yet it still flags the 'attributions' array and disclaimer as pass-through obligations, which is the one thing the schema can't enforce. The paused/SOURCE_UNAVAILABLE behavior covers the main failure mode an agent would otherwise mishandle.

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

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

Schema coverage is 100% and both parameters are already documented, including the accepted area forms and the regionType hint. The description only adds a geographic boundary ('Western Washington focus'), which is a mild constraint but not format or validation detail beyond the 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?

States a specific resource (latest Redfin market snapshot) and enumerates the exact metrics returned (median sale price, YoY change, days on market, months of supply, percent above list), plus scope ('ZIP, neighborhood, city, or county'). It explicitly distinguishes itself from wa_comps and wa_market_trends, so an agent can pick it without opening the schema.

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

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

Gives the triggering question pattern ('how is the market in X') and names two alternatives with the conditions that select them: wa_comps for recorded sale prices, wa_market_trends for price-index trends. It also states a hard exclusion ('aggregate statistics only — no individual listings, parcels, or people'), which is exactly the when-not guidance an agent needs.

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 establish read-only behavior, but the description adds substantial source-level transparency: it names publishers, periods, file hashes, attribution requirements, and legal disclaimers. It also caveats that median listing price is an asking price, not a sale price, which is valuable behavioral context beyond structured annotations.

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

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

The description is front-loaded with the data sources and fields returned, and every sentence carries relevant information. It is a dense single paragraph, though, and could be more scannable if the attribution and disclaimer instructions were separated from the data description.

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?

Although an output schema exists, the description goes beyond it to explain required attribution pass-through, the professional-advice disclaimer, and the distinction between asking and sale prices. For a multi-source read-only market data tool, an agent has everything needed to call and present results responsibly.

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

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

Schema coverage is 100%, and the schema already documents both area and regionType formats with examples. The description restates that the tool accepts a ZIP, county, city or metro but adds no syntax or format detail beyond what the schema provides, 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 exactly what data is returned and at what geography: monthly listing inventory, FHFA HPI, Census permits, BLS unemployment and OFM population for a Washington ZIP, county, city or metro. The purpose is highly specific, though it never explicitly differentiates itself from siblings such as wa_market_snapshot or wa_comps.

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

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

Provides clear output-handling rules (quote numbers verbatim with their period, reproduce required attributions, pass through the attributions array and disclaimer) and notes that unknown areas are free. However, it does not say when to choose this tool over adjacent tools like wa_market_snapshot, wa_local_context, or wa_comps.

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 establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds genuinely useful behavior: the output contains an 'attributions' array and a professional-advice disclaimer that must be passed through to end users, and it warns that 'Review every included cost' matters. It doesn't say whether costs are estimated from defaults when fields are omitted.

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

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

Three short sentences, front-loaded with the core action and followed by the two constraints that actually change behavior (rate assumption, attribution pass-through). No filler, though the 'Review every included cost' sentence is somewhat elliptical about what to review.

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 spelled out, and the description wisely focuses on the pass-through obligations. But for a ten-parameter tool where most fields have silent defaults (20% down, 0.92% tax, 0.5% PMI), an agent gets no guidance on what happens when those are omitted — a meaningful gap 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 only 20%, and the description mentions just four of the ten inputs (price, down payment, loan term, rate) with no added meaning beyond the field names. The other six — pmiPct, monthlyHoa, propertyTaxRatePct, annualPropertyTax, annualHomeInsurance and the down-payment default behavior — are neither described nor their defaults explained, and 'Review every included cost' is too vague to compensate.

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

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

States a specific verb and resource — 'Calculate a monthly mortgage and housing-cost estimate' — and names the inputs it consumes. It is clearly distinct from the sibling tools (comps, net sheet, offer comparison), though it doesn't explicitly route to any of 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?

Usage is implied: an estimate based on buyer-supplied price, down payment, term and rate. The caution that a rate is 'an assumption, not a live lender quote' frames the context well, but there is no explicit when-to-use/when-not guidance or named alternative (e.g. wa_net_sheet for full closing costs).

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

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

Goes well beyond the readOnly/openWorld annotations: it discloses that every line item is computed deterministically by the same engine as SENTINEL's product, that no third-party data is used, that the result is an itemized dict, and — critically — that the response carries an 'attributions' array and a professional-advice disclaimer that must be passed through to end users. That last instruction is operational guidance an agent could not derive from annotations.

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

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

Two dense sentences, front-loaded with the core purpose and ending with the compliance-relevant passthrough instruction. The middle enumeration is long but every clause corresponds to a computed output, so little 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 fully restated; the description still supplies the one thing the schema cannot — the obligation to surface attributions and the advice disclaimer. Combined with the county scope and determinism claim, an agent has everything needed to call and use this correctly.

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

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

Schema coverage is 100%, so baseline is 3; the description nonetheless maps its enumerated line items onto the parameters (commission, REET, mortgage payoff, HOA/tax prorations), reinforcing which inputs drive which outputs. It does not add format or edge-case detail beyond the schema, so it stays just above baseline.

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

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

States a specific verb and resource — estimate a Washington home seller's net proceeds — and enumerates the line items included (commission, graduated REET, title/escrow/closing, payoff, prorations). This is clearly distinguishable from narrower siblings like wa_reet or wa_compare_seller_scenarios because it describes a bundled itemized net-sheet computation.

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

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

Explicitly scopes use to 'what will the seller walk away with' questions on WA sales and adds a hard constraint ('WA counties only'). It does not, however, name the obvious alternatives (wa_reet for REET alone, wa_compare_seller_scenarios for side-by-side comparisons), so routing between siblings is left partly to inference.

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

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

Annotations already cover read-only scope, and the description adds substantial beyond-schema context: uneven source coverage, that other municipal sources return lookup resources instead, that source update times may reflect bulk republishes, and that the attributions array and disclaimer must be passed through. This is exactly the kind of non-obvious behavior an agent needs.

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

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

Front-loaded with purpose and source scope before the cautions, and most sentences carry real information. The attributions/disclaimer sentence is legally dense but operational, since it tells the agent to pass content through.

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 explanation is correctly omitted, and the description still flags the attributions/disclaimer elements the agent must forward. The remaining gap is the undocumented limit/city parameters, which is minor given the schema's defaults and constraints.

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, and it does explain the critical address vs. county+parcelId requirement plus the exact match rules (recorded street/unit/ZIP). It says nothing about city, limit (default 20, max 50), or the zipCode pattern, leaving half the parameters 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?

Names a specific verb and resource ('Read dated building-permit records for one exact property') and enumerates the payload fields and covered sources. It is unambiguous on its own, but it never contrasts itself with close siblings like wa_property_changes or wa_sale_history, so an agent must infer the boundary.

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?

'Use address or county plus parcelId' gives input-mode guidance and the description warns about incomplete coverage and that 'no records does not prove no permits'. However, there is no explicit statement of when to prefer this over wa_property_changes or wa_sale_history, which is the main selection risk.

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 readOnlyHint/openWorldHint already declaring the safety profile, the description still adds substantial behavioral context: history is incomplete, unavailable history is free, baselines are not changes, pagination requires unchanged inputs, and the response carries an attributions array plus a disclaimer that must be passed through. It also warns "Never infer unpermitted work," which preempts a likely downstream misuse.

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?

Sentences are short, front-loaded and each carries distinct information (modes, baseline caveat, pagination, output pass-through). A few lines, e.g. "unavailable history is free," are terse to the point of ambiguity, but there is no filler.

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

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

An output schema exists, yet the description still earns its place by flagging the attributions array and disclaimer as pass-through requirements. The remaining gap is identification of the property: it never explains the address-or-county+parcelId requirement or the exact-match constraint's implications.

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

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

Schema coverage is only 33%, and the description covers just three of nine parameters (since, asOf, cursor), leaving address vs county+parcelId, city, zipCode and limit to the schema. Worse, it instructs the agent to "Use next_cursor" while the actual parameter is named "cursor," a naming mismatch that could confuse invocation.

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

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

States a specific verb and resource ("Read immutable permit evidence") scoped to "an exactly matched property," plus the two modes (changes via since, point-in-time via asOf). It does not distinguish itself from the very similar sibling wa_permit_history, so an agent cannot tell them apart from the description 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?

"Supply since for changes after that capture time, or asOf for versions known by that time" gives explicit mode-selection guidance, and "Initial captures are baselines, not changes" removes a real misinterpretation risk. Missing are when-not-to-use signals and any pointer to the sibling permit/sale-history tools for the cases this one does not cover.

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

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

Annotations only declare readOnly and closed-world; the description adds the substantive behavior: data is cached/ingested rather than live, certain states are explicitly flagged (unverified, missing, withheld, stale), a coverage_note names extract gaps, and listing fields are null unless a licensed provider row matched. The instruction 'Read a null as no licensed listing on file... not as this home is not for sale, and do not infer a status or a price from the county fields' is exactly the kind of misuse-preventing context annotations cannot carry.

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?

Purpose and coverage are front-loaded, then null semantics, then exclusions, then call guidance — a sensible order with no filler sentences. It is dense and long (the full listing field enumeration is arguably more than the agent needs inline), but every clause carries information an agent would otherwise guess wrong.

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 lookup with a full input schema and an output schema, the description covers the remaining unknowns: data provenance, coverage gaps, null meaning, excluded fields (owner identity, equity, photos, portal valuations), legal enum scope, and the obligation to pass through attributions and the disclaimer. Nothing an agent needs to call this correctly or report results responsibly is missing.

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

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

Schema coverage is 100%, so the baseline is 3; the description adds meaning beyond the schema by stating the address must be a specific WA street address, that county plus parcelId is an accepted alternative path, and by tying NOT_FOUND back to the address/parcel inputs. It does not explain how city and zipCode disambiguation interact with the anyOf, but the added routing guidance is real value over the schema.

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

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

States a specific verb and resource ('look up one Washington property from already-ingested county assessor records'), names the four covered counties, and enumerates what the record contains. It is clearly distinguishable from adjacent siblings like wa_property_changes, wa_comps and wa_sale_history because it describes a single cached record snapshot rather than historical or comparative views.

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

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

Gives explicit invocation rules ('Use a specific WA street address or county plus parcelId'), an explicit scope exclusion ('Per-address queries only (RCW 42.56.070(8)); no area enumeration'), and a documented failure mode with handling instructions ('a NOT_FOUND error means the address is outside covered counties... say so rather than guessing'). It also pre-empts a likely misinterpretation of nulls rather than leaving the agent to invent one.

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

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

Goes well beyond the readOnly/openWorld annotations: it discloses that computation is deterministic from a production engine rather than estimated, that no third-party data is used, what the result contains (per-bracket breakdown, $5 DOR technology fee, rate-assumption caveats), and an explicit obligation to pass through attributions and the disclaimer. That last point is actionable behavior an agent could not infer from annotations.

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

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

Front-loaded with the purpose and computation basis, then scope, then output expectations — a sensible order. Slightly dense in the middle, and 'Uses no third-party data' is close to filler given the adjacent attributions sentence, but nothing is truly 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 retold, yet the description still flags the salient parts (breakdown, fee, caveats, attributions, disclaimer) that require downstream handling. Combined with the scope limits and determinism claim, an agent has everything needed to call this correctly and use the response.

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

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

Schema coverage is 100%, so both parameters are already documented, establishing the baseline of 3. The description adds only marginal meaning beyond the schema — the county drives the local rate, and there is a caveat that city-level exceptions may require verifying the DOR location code — but it does not clarify the seller-paid default's interaction with any parameter.

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

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

States a specific verb and resource — calculate Washington State REET for one sale — with the statutory basis (RCW 82.45) and the exact composition (state graduated brackets plus county local rate). No sibling tool in the list computes excise tax, and the description makes that scope unambiguous.

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

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

Gives a clear trigger ('Use when you need the exact excise tax owed on a WA home sale') plus a hard scope exclusion ('Washington State counties only') and a default assumption (seller-paid). It does not name an alternative tool for out-of-state or buyer-paid cases, which keeps it 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?

Beyond readOnlyHint=true and openWorldHint=false, the description discloses important behavior: compact and full projections retain identical claims, coordinate context is a separate point observation rather than an inferred parcel match, and unavailable or ambiguous research is free while useful partial evidence counts as one answer. It also states that the result includes attributions and a professional-advice disclaimer that must be passed through. These details add real value beyond the annotations.

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

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

The description is dense but front-loaded, starting with the core purpose and packet contents before covering projection behavior, coordinate caveats, billing semantics, and required output notices. Most sentences earn their place, though the paragraph is long for a single tool definition.

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 is complex, with 7 parameters and an output schema, and the description covers important behavioral and output-notice details. However, it leaves significant gaps around when to choose this tool over siblings and what most parameters mean, so it is only partially complete 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%, so the description must carry parameter meaning, but it only clarifies 'projection' as compact/full with identical claims and explains that coordinate context is separate from parcel identity. It does not explain the semantics of 'local', 'sellerScenarios', 'permitLimit', or 'includePermits', leaving most top-level parameters under-specified.

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: get a bounded property research packet with exact identity matching, source-backed facts, calculations, conflicts, unknowns, and follow-ups. It clearly defines the packet's scope, but it never names sibling tools like wa_property_lookup or wa_seller_packet to help distinguish when this composite packet is the right choice.

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 some usage constraints, such as preserving qualifications and passing through attributions and disclaimers, but it does not state when to use this tool versus alternatives like wa_property_lookup, wa_site_context, wa_local_context, or wa_seller_packet. There are no explicit when-not-to-use conditions.

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

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

Annotations only declare readOnlyHint and openWorldHint=false; the description adds substantial behavior the agent could not otherwise know: a three-year lookback ceiling, that multi-parcel, nominal and unverified prices are flagged rather than suppressed, that misses are free, and that results carry an 'attributions' array and disclaimer that must be passed through. That is real operational context beyond the annotation profile.

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?

Purpose and geographic scope are front-loaded, followed by record contents, caveats and the pass-through obligation in a logical order. Dense but each sentence carries distinct information; the attributions/disclaimer sentence is long but operationally necessary.

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 lookup with an output schema, the description covers source, recency window, record contents, null-result semantics and end-user obligations well. The remaining gap is the undocumented optional filters and their default limits, which an agent would need for anything beyond the basic two call patterns.

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 carries the full burden, yet it only explains address/county/parcelId and their relationship. Four of seven parameters (city, zipCode, days, limit) are never mentioned, and the 1,095-day default / 50-record limit bounds are left entirely to the schema. It compensates for the critical anyOf input modes but not for the rest.

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

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

States a specific verb and resource ('Read recorded sale dates and prices') scoped to 'one exact King, Pierce or Snohomish County parcel' from a named source. This clearly separates it from siblings like wa_property_changes, wa_comps and wa_property_lookup without any schema inspection.

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

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

Gives explicit invocation modes ('Use address or county plus parcelId') and rules out ownership use ('No buyer, seller or owner names') plus warns that a miss is not proof of no sale. It stops short of naming an alternative sibling (e.g. wa_comps for comparable-sale analysis), so the routing guidance is clear but not fully comparative.

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

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

Annotations already declare readOnlyHint=true, so the safety profile is covered, yet the description still adds real behavioral content: missing or old data must remain visible, supplied prices are scenarios not a CMA or appraisal, and licensed listing/price-index trends are substituted when snapshots are paused. It also mandates that the 'attributions' array and professional-advice disclaimer be passed through to end users, which is a downstream obligation an agent could not infer from the schema. It stops short of covering failure modes or partial-result 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?

Three sentences, front-loaded with what the tool produces before the caveats, and the pass-through instruction lands last where an agent will still read it. It is dense but every clause carries a constraint; the only mild cost is legal-register phrasing ('non-affiliation line') that slows parsing.

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?

Return values need little explanation because an output schema exists, and the description covers the disclaimer and attribution obligations well. The gap is on the input side: for a 7-parameter tool with 14% schema coverage and several optional nested objects, the description says nothing about how to decide whether to supply property, deadlines, or monthlyPayment, leaving the agent's call construction under-informed.

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 only 14% across 7 parameters, so the description carries the burden and mostly does not. It alludes to the scenarios input and to county/property/market data in passing, but never explains the deadlines sub-object, monthlyPayment, includePermits, the 2-3 scenario array bound, or the county identifier format. An agent must open the nested $defs to learn anything about how to populate the inputs.

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

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

The description gives a specific verb and artifact: 'Prepare one seller briefing that combines proposed sale-price scenarios with available county property records and dated market context.' That is concrete enough to distinguish it from single-purpose siblings like wa_comps or wa_monthly_payment. It never names a sibling it is not, though, so an agent comparing it against wa_compare_seller_scenarios or wa_research_packet must infer the boundary from the word 'packet' 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?

Usage is implied rather than stated: the word 'packet' plus the list of combined inputs signals a multi-artifact briefing, and the fallback clause about paused sale-price snapshots hints at degraded conditions. But there is no explicit 'use this when X, use wa_compare_seller_scenarios when Y', and no prerequisites such as which county values are valid or when a property locator is required versus optional.

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

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

Annotations only cover readOnly and closed-world; the description adds substantial behavior beyond that. It discloses per-source result states (unavailable / outside-study / no-mapped-feature), that observation times and attributions are returned, that cleanup observations require documented commercial reuse permission, and a critical epistemic caveat that absence of a mapped feature does not establish safety or disclosure compliance.

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?

Five sentences, all load-bearing, with the resource inventory front-loaded. It is dense but not padded; the only mild inefficiency is stacking the permission note and the safety disclaimer as separate trailing sentences rather than grouping caveats.

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 shape needn't be spelled out, yet the description still usefully previews per-source status values, timestamps, and attributions. Combined with the coordinate requirement and the non-guarantee disclaimer, an agent has nearly everything needed; only the longitude semantics and any latency/availability expectations are unaddressed.

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?

With only 2 parameters and 50% schema coverage, the schema documents latitude's bounds and the 'no address match implied' caveat but leaves longitude bare. The description compensates somewhat by requiring a 'verified coordinate' and clarifying the result describes a point, but it adds no format or precision guidance beyond what the schema already says. Baseline 3 is appropriate.

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

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

The description opens with a specific verb ('Query') and enumerates the exact resource set: FEMA flood mapping, landslide coverage/inventory, liquefaction, mapped faults within 5 km, and an Ecology cleanup lookup link. That resource list is distinctive enough to separate it from wa_property_lookup or wa_local_context by content, though it never names a sibling or states the boundary 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?

'Supply a verified coordinate; results describe a point, not an entire parcel or structure' implies the appropriate use case (point-level environmental screening) and warns against over-generalizing to a parcel. However, there is no explicit when-to-use vs. when-to-choose-a-sibling guidance, and no statement of what the tool is not for beyond the point/parcel caveat.

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