Verrow, LLC rural public data

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

With no annotations, the description carries the full burden of behavioral disclosure. It adds one useful trait ('Free'), but as a mutation tool it omits whether cancellation is reversible, whether history is preserved, what happens when cancelling an already-cancelled watch, and what authorization the owner token represents.

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

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

Two short, front-loaded sentences with no filler. 'Free' is a useful, distinct piece of information rather than padding. It is terse but appropriately so for a simple two-parameter operation.

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 mutation tool with no annotations, no output schema, and 0% parameter description coverage, the definition is too thin. An agent still lacks confirmation of return behavior, idempotency, permissions, and how to source the owner token.

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 for both parameters. It only restates that a watch 'id' and 'owner token' are used, without explaining the UUID format, the 'w_' token pattern, or where an agent obtains the owner token.

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 ('Cancel a watch') plus the identifying inputs, so an agent can immediately tell it apart from list_watches or watch_parcel. It stops short of naming the sibling or clarifying the boundary between this and other watch-related 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 explicit when-to-use guidance, no preconditions (e.g. must the watch exist, who can cancel), and no alternatives mentioned. The only implied usage is that a watch id and owner token are needed, which follows from the schema rather than from deliberate 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 it does disclose the most important behavioral fact: the live source is not wired, so calls return UNKNOWN and are never charged. It stops short of describing what a wired/future response contains, latency, or how UNKNOWN should be interpreted by the caller. The accuracy and uptime statistics are unverifiable marketing claims that sit oddly next to the admission that the source is a stub.

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

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

It is a single compact sentence and the critical caveat is front-loaded in parentheses, which is good. However, roughly half the text is trust-badging ('100% golden accuracy (78/78)', '100% uptime (24h)', 'data as of 2026-10-26') that does not help an agent select or invoke the 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?

With no output schema and no annotations, the description should explain the return shape (what fields beyond citations, what UNKNOWN looks like) and the coordinates. It conveys only that the tool is a stub and cites pages, leaving an agent unable to predict a response or interpret an UNKNOWN result beyond 'not charged'.

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

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

Schema description coverage is 0% and the description says nothing about lat/lon — no format guidance, no coordinate system, no note that both are required or that out-of-range values will be rejected by the schema bounds. Latitude/longitude are conventional enough to be partly self-evident, which keeps this above 1.

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 text restates the tool name and then describes only its current operational status (BETA, returns UNKNOWN). It never says what airspace is being checked — restrictions, classes, drone/geofence limits, or regulatory clearance — so an agent cannot tell what this tool actually answers or how it differs from siblings like check_use_allowed or spray_check.

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

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

There is no statement of when to use this tool, when not to, or which sibling to prefer. The only usage-adjacent signal is 'free ... returns UNKNOWN without charge', which describes cost, not selection criteria.

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 behavioral burden. It usefully discloses that the call is free (cost is the key behavioral trait here), but says nothing about auth requirements, rate limits, or what a positive/negative result looks like.

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, cost-saving rationale front-loaded, input summary at the end. Nothing 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?

There is no output schema, so the description should say what 'covered' returns (boolean, partial-match list, nearest alternatives?). That omission is the main gap for an otherwise small, simple tool.

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

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

Schema coverage is 0%, so the description must compensate. It does add real meaning for jurisdiction ('name or slug'), but data_kind is only restated as optional with no hint about accepted values or granularity, leaving half the params underspecified.

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: check whether a jurisdiction and data kind are covered. The 'before paying for a query' framing distinguishes it from list_coverage and request_coverage without naming them 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?

Gives a clear usage condition — call this before incurring cost on a query — which is exactly the decision point an agent needs. It does not explicitly exclude or name the sibling alternatives (list_coverage, request_coverage), leaving that inference to the agent.

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 load; it does disclose real behavior an agent would otherwise guess wrong about: the tool currently returns UNKNOWN, that UNKNOWN is never charged, and the data snapshot date. It does not disclose permissions, read-only nature explicitly, or what a non-UNKNOWN result looks like.

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 run-on sentence packs marketing statistics (golden accuracy, uptime, page-cited) ahead of any statement of function. The most useful fact for a caller — that it returns UNKNOWN and is free — is buried mid-sentence.

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

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

No output schema exists, so the description should explain return shape, yet it only mentions the UNKNOWN case. Combined with 0% parameter documentation and no annotations, an agent cannot reliably construct a call or interpret the result.

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

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

Schema description coverage is 0% and the description says nothing about the two parameters. An agent must infer that 'name' is a person or business name and 'license_number' is a state-issued identifier, and whether either is required (the schema marks neither required, which is itself unexplained).

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

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

The description restates the tool name and then spends its entire length on beta status, pricing, and accuracy metrics. It never states what a 'license' is being checked against, what domain it applies to, or what a caller learns from a positive vs. negative result.

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

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

No when-to-use guidance at all, and no differentiation from plausible siblings such as check_state_registration, check_use_allowed, or check_coverage. The only implicit guidance is 'calls are free right now', which is a billing fact, not a selection rule.

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 exist, so the description carries the full burden. It does add genuine behavioral facts — calls are currently uncharged and return UNKNOWN because the live source is not wired — but it omits auth requirements, rate limits, what a successful (non-UNKNOWN) response contains, and what the accuracy claims mean operationally.

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 opening repeats the tool name verbatim before any substance, and the bulk of the sentence is operational bragging (78/78 golden accuracy, 100% uptime, data as of a date) that does not help the agent decide or invoke. The one useful fact — returns UNKNOWN, not charged — is buried mid-parenthetical.

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 no annotations, no output schema, and two undocumented parameters, the description needed to explain the resource being checked, the meaning of each parameter, and the shape of a real response. It supplies none of these, so an agent cannot reliably call this tool beyond passing an arbitrary jurisdiction string.

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% for both parameters. The description says nothing about what 'jurisdiction' expects (state code? full name? country?) or what 'data_kind' selects among, leaving the agent to guess on a required argument.

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 text largely restates the tool name and then pivots to status/marketing metadata (BETA, free, uptime, golden accuracy). It never states what a state registration check actually determines, what entity or subject it applies to, or how it differs from siblings like check_license or check_zoning.

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

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

There is no when-to-use guidance and no comparison to the many adjacent compliance tools (check_license, check_zoning, check_use_allowed, solar_siting_check). The only usage-relevant signal is that calls are currently free and return UNKNOWN, which tells the agent about cost but not about appropriateness.

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 exist, so the description carries the full behavioral burden, yet it discloses only marketing claims. The clause 'UNKNOWN never charged' is the single genuine behavioral fact (billing on indeterminate results), and '100% page-cited' hints at citations, but nothing covers mutation risk, jurisdiction scope, data freshness semantics, or failure modes.

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

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

It is a single short sentence, so it is not verbose, but every clause is unverified promotional signal rather than operational information. Nothing is front-loaded that helps an agent decide to call it.

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?

A regulatory look-up tool with 2 required free-text parameters, no annotations, no output schema, and no parameter documentation needs the description to define scope and inputs. The description supplies none of this, leaving the tool effectively uncallable with confidence.

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

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

Schema description coverage is 0% across three parameters (jurisdiction, use, zone) and the description adds nothing about their format or meaning. What counts as a valid 'use' string (a category? free text?), and what 'jurisdiction' looks like (US state? county FIPS?), is entirely undocumented.

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 never states what is being checked: it lists quality metrics ('100% golden accuracy', '100% uptime', 'data as of 2026-10-26') that restate nothing beyond the tool name. An agent can only infer 'check whether a land use is permitted' from the name itself, and the description does nothing to distinguish this from siblings such as check_zoning, check_airspace or spray_check.

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

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

There is no when-to-use, when-not-to-use, or alternative named anywhere in the text. With 11+ sibling check_* tools, the absence of any routing signal leaves the agent guessing whether this or check_zoning / spray_check / check_license is the right call.

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 behavioral burden and discloses two important traits: the key is shown only once and must be stored in a secret store, and creation is free. It does not cover authorization requirements or rate limits, but the security-sensitive behavior is clearly surfaced.

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 three short sentences with zero waste, front-loading the purpose and then the critical one-time visibility warning. Every sentence 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?

The description covers purpose, key sensitivity, and cost, but leaves the three parameters completely unexplained and does not state any auth or environment prerequisites. With no annotations and no output schema, an agent lacks enough context to invoke this tool 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% and the description does not mention any of the three parameters (label, payer, credit_code). It provides no meaning or format guidance for them, so an agent must guess what to supply.

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 a specific verb and resource: create a prepaid API key. It adds the qualifier 'prepaid' and mentions cost, which helps distinguish it from generic key creation, but it does not explicitly differentiate from siblings like topup_credits.

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 does not state when to use this tool versus alternatives such as topup_credits or get_pricing. Usage is only implied by the tool name and the word 'prepaid'; no explicit when/when-not guidance is provided.

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 does carry real behavioral disclosure: it is BETA, the live source is not wired, it currently returns UNKNOWN, UNKNOWN is never charged, and data is as of 2026-10-26. That is genuinely useful context an agent would otherwise lack. However it omits what a non-UNKNOWN response looks like, what permissions/auth are needed, and what 'ESA limits' means semantically.

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

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

It is a single sentence, but nearly all of it is verification/marketing metrics (100% golden accuracy 78/78, 100% uptime 24h) that crowd out the actual purpose. The name is redundantly repeated at the front instead of a functional statement being 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 3-parameter, unannotated, no-output-schema tool with 0% parameter coverage, the description should explain what is being looked up and what comes back. It only states the current degenerate return (UNKNOWN) and data freshness, leaving the agent unable to interpret a successful response or the month parameter.

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

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

Schema description coverage is 0% across 3 parameters (lat, lon, month) and the description says nothing about them. It never explains that lat/lon is the query point, what coordinate convention applies, or what month scoping (1-12) does. All parameter meaning must be guessed from the schema's types and bounds alone.

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 never says what the tool actually returns — it only restates the name ('get_esa_limits') and then lists beta status and accuracy metrics. 'ESA limits' is never expanded (Endangered Species Act species/critical-habitat limits?) and no verb+resource statement of function is given. An agent cannot tell from this text what the tool computes for a lat/lon.

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

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

There is no when-to-use guidance and no routing against the many overlapping siblings (check_use_allowed, check_license, solar_siting_check, spray_check, check_airspace). The only implied usage cue is that it is free and returns UNKNOWN without charge, which hints 'safe to call' but not when it is the right tool.

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

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

With no annotations, the description carries the full burden and discloses the return fields, the UNKNOWN caveat for rate/REI/PPE, and the $0.05 per-call cost. It omits failure modes and auth requirements but covers key behavioral traits 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 core purpose, then lists returns, then caveats and pricing. Every sentence adds distinct value; there is no repetition or 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?

Given a single-parameter tool with no output schema and no annotations, the description is fairly complete: it details what is returned, what is not (UNKNOWN fields), and the cost. Minor gaps like error handling or auth expectations are less critical for a simple lookup.

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 provides an example format '(e.g. 66551-1)' which clarifies the expected pattern, but does not fully explain the regex or validation rules, making it adequate but not complete.

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, 'lookup,' and resource, 'US EPA pesticide product,' keyed by EPA registration number, with an example. It does not explicitly differentiate from siblings like check_state_registration or check_use_allowed, so a 4 rather than 5.

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

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

The description implies usage when an EPA registration number is known, and it explicitly warns that application rate, REI, and PPE are UNKNOWN until Phase 2, which helps avoid misuse. However, it does not name alternative tools or state when NOT to use this tool, leaving alternatives 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?

No annotations exist, so the description carries the full burden. 'Free' usefully discloses that invoking this tool costs nothing, and 'List' implies a read-only, non-destructive operation, but permission/auth requirements and whether prices are static or volatile are unstated.

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

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

Two short sentences, zero filler, with the resource and unit of measure front-loaded and the cost caveat last.

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

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

For a zero-parameter catalog tool with no output schema, the description adequately conveys the return shape (tools plus per-call price in USDC). Minor gaps: pagination or price-freshness behavior is not mentioned.

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?

Zero parameters, which is the baseline-4 case; the description correctly implies no inputs are needed to enumerate the catalog.

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

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

Specific verb ('List') plus resource ('every tool and its price per call') with the unit of currency (USDC) named. No sibling covers pricing, so the scope is unambiguous even among the 23 surrounding 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?

Usage is only implied — an agent can infer this is the discovery step before invoking paid tools — but the description never says when to call it, and names no alternative or precondition.

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 behavioral burden and mostly fails: it never says the call is read-only, what is returned, or how billing works beyond the cryptic "UNKNOWN never charged" remark. The freshness stamp ("data as of 2026-10-26") and the billing hint add a little real context, which keeps this above a 1.

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

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

It is short but the entire sentence is marketing and metadata rather than operational information. Every clause is about vendor credibility, not about how to invoke the tool, so brevity here reflects under-specification rather than efficiency.

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

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

For a tool with no annotations, no output schema, and 0% parameter documentation, the description should supply purpose, usage, and parameter meaning; it supplies none of these. Only the accuracy/uptime claims and a date are 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 0% for two parameters (jurisdiction, limit), and the description adds no meaning to either. An agent gets no clue about jurisdiction format (state? county? FIPS?) or what limit constrains.

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 never states what the tool does. It consists entirely of trust metrics ("100% golden accuracy (78/78)", "100% page-cited", "100% uptime") and a data timestamp. Only the name get_recent_decisions hints at retrieving recent decisions, and the domain (legal? regulatory? zoning, given siblings) is never named.

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 indication of when to call this versus any sibling such as get_zoning, check_use_allowed, or get_site_report. No prerequisites, exclusions, or alternatives are mentioned anywhere in the text.

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 does substantial work: it discloses the billed cost ($4.00 per call in USDC), the no-charge failure mode (422 on UNKNOWN zoning/flood zone), citation behavior, and data freshness date. It stops short of describing authentication, rate limits, or the exact failure/retry semantics for other error classes.

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 report scope, then cost and failure semantics, which is the right ordering for an agent. The trailing 'Verified: 100% golden accuracy… 100% uptime' cluster is mildly promotional but does deliver trust-relevant information compactly.

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

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

The description compensates for the missing output schema by enumerating the returned report sections, and it covers pricing and the UNKNOWN failure path. However, with seven parameters at zero schema coverage and no annotations, an agent still lacks guidance on supplying jurisdiction/district/coordinates or on what happens for other error conditions.

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?

Seven parameters, two of them required, with 0% schema description coverage, yet the description only vaguely gestures at 'address/parcel' and implies proposed_use via 'allowed-use verdict'. It says nothing about jurisdiction (required), district, or latitude/longitude, so most parameters are undocumented in both the schema and the description.

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 ('Site feasibility report for an address/parcel') and enumerates exactly what the report contains: zoning, allowed-use verdict, permits, recent decisions, FEMA NFHL flood zone and soil. This clearly distinguishes it as a composite report versus the granular siblings get_zoning, check_use_allowed, get_soil and get_recent_decisions.

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 only implied by the composite nature of the tool; the description never says 'use this instead of calling get_zoning + check_use_allowed separately' or when a lighter single-purpose call is preferable. It does add one useful decision rule (a 422 with no charge when zoning or flood zone is UNKNOWN), but there is no explicit sibling routing.

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

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

With no annotations, the description carries the full behavioral burden. It usefully discloses that the live source is not wired, that calls return UNKNOWN without charge, and that UNKNOWN is never billed; however, it omits operational details such as authorization, rate limits, and what a successful response looks like, and the accuracy/uptime claims are noisy and somewhat inconsistent with the 'not wired' caveat.

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 critical caveat is front-loaded in the opening parenthetical, but the sentence then spends substantial space on golden accuracy, page-citation, uptime, and data-date metrics that do not help an agent decide or invoke correctly. It is compact but not optimally structured for tool selection.

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 two-parameter tool with no output schema and no annotations, the description should explain the return values and parameter meaning. It only says the live source is unwired and currently returns UNKNOWN, leaving the success behavior and coordinate semantics undocumented.

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

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

Schema description coverage is 0%, and the description does not mention lat or lon at all. The schema provides types and ranges, but the description adds no meaning about coordinate order, datum, precision, or expected coordinate system.

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 never states what soil data the tool retrieves or what a successful result would contain; it mostly restates the name and adds beta/status metrics. An agent can infer soil lookup from the name and lat/lon parameters, but the description itself does not define the resource or distinguish it from siblings like get_wind or get_zoning.

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 guidance on when to use this tool versus alternatives, nor any prerequisites or exclusions. The beta caveat implies it currently returns UNKNOWN, but the description does not say what to do instead or when it would be appropriate to call.

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 behavioral burden and does a good job disclosing that the live source is not wired, the tool currently returns UNKNOWN, UNKNOWN is never charged, and the tool is free during beta. It also reports accuracy, page-citation, uptime, and data date, though it does not describe the normal return shape or units.

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 front-loaded sentence, but it spends substantial space on verification metrics and uptime claims that are not directly useful for invoking a tool that currently returns UNKNOWN. It is compact but not fully focused on invocation-relevant 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 simple two-parameter tool with no output schema and no annotations, the description should explain what is returned and what the parameters mean. It covers the current beta/UNKNOWN state but leaves the normal behavior, return content, and parameter semantics incomplete.

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

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

Schema description coverage is 0%, and the description says nothing about the lat and lon parameters. It does not explain coordinate meaning, expected format, or how the two required parameters affect the result.

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 mostly restates the tool name and reports beta/verification status rather than stating what wind data is returned. It does not clarify whether this is current wind, forecast wind, speed, direction, or another wind product, nor does it distinguish the tool from siblings.

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

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

There is no guidance on when to use get_wind versus alternatives, no prerequisites, and no exclusions. The beta/free status is noted, but that is not usage guidance for selecting this tool.

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

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

With no annotations, the description carries the full burden, but it does add genuine behavior: UNKNOWN answers are not billed, results are page-cited, and there is a stated data freshness date and uptime figure. It still omits permissions, rate limits, coverage limits, and response shape, so it is partial rather than complete.

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

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

It is short, but almost every token is marketing telemetry ('100% golden accuracy (78/78)', '100% uptime (24h)') rather than task-relevant information. Front-loaded text is the tool name repeated, not the purpose.

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 two-parameter lookup with no annotations and no output schema, the description should explain accepted jurisdiction/zone formats and what comes back. It only gestures at cited output and data vintage, leaving the agent unable to call it correctly without guessing.

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

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

Schema description coverage is 0% and both parameters ('jurisdiction', 'zone') are bare strings with only length bounds. The description supplies no format guidance (city/county/state? zone code syntax?), required-ness, or interaction between the two, so it fails to compensate at all.

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 text restates the name ('get_zoning') and piles on quality metrics rather than stating what the tool returns. Only 'page-cited' and 'data as of 2026-10-26' hint that it retrieves zoning records, but a reader never learns it looks up zoning rules for a jurisdiction/zone.

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

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

No when-to-use, when-not-to-use, or alternatives are given, despite close siblings like check_use_allowed, solar_siting_check, spray_check, and check_coverage. Nothing tells the agent how to choose between them.

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 burden. It does disclose the cost profile (free) and the shape of each returned entry (jurisdiction + data kind + data_as_of), which is genuinely useful. It says nothing about response size or whether the full enumeration is paginated, and read-only status is only implied by "List."

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, front-loaded with the resource being listed and followed by the useful return detail and cost note. 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-annotations, no-output-schema catalog tool, the description covers what is returned, the per-entry freshness field, and cost. It never states read-only/side-effect-free status explicitly or whether the result set can be large.

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 takes zero parameters, so the baseline is 4 and there is nothing for the description to compensate for. The mention of data_as_of is a return-value detail rather than a 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?

"List every jurisdiction and data kind this service covers" gives a specific verb and resource, and the return payload (data_as_of per entry) is stated. It does not name or contrast with the near-synonym siblings check_coverage and request_coverage, so an agent must infer the difference itself.

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 only usage signal is "Free," which says calling it is costless but not when to prefer it over check_coverage or request_coverage. With three sibling tools covering very similar ground, the absence of any when-to-use or when-not-to-use guidance is a real gap.

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

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

With no annotations, the description must carry behavioral context. It adds useful details—the operation is a list (implying read-only) and is free—but it does not disclose pagination, return contents, rate limits, or authentication requirements beyond the token.

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 concise, front-loaded sentence plus a cost note. Every clause earns its place and nothing is buried or redundant.

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

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

For a simple one-parameter list tool with no output schema or annotations, the description covers how to invoke it but leaves gaps about what is returned, whether results are paginated, and how canceled watches appear. It is minimally adequate but not 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?

There is one required parameter with 0% schema description coverage, so the description must compensate. It explains that the owner_token is returned when the watch was created, which adds meaning beyond the schema's pattern, but it does not clarify token handling, security, or format beyond what the regex implies.

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 and resource: "List watches." It also scopes the operation to an owner token and notes the cost, making the purpose clear, though it does not explicitly distinguish itself from sibling tools like cancel_watch or watch_parcel.

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 "owner token returned when the watch was created" implies the tool is used after creating a watch, but it does not explicitly state when to use this versus alternatives or mention exclusions. Usage is therefore implied rather than guided.

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 largely delivers: it discloses the $5 charge, the $5 of call credits returned on success, the 14-day refund queue, and the side effect of starting the records agent. It omits auth requirements, repeat-request/idempotency behavior, and whether the charge occurs at submission or only on success — and the trailing metrics block (uptime, golden accuracy, data-as-of) is service-level promo rather than tool 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?

The first two sentences are dense and front-loaded with the cost and the refund policy, which is the right ordering. But roughly half the text is an unverifiable marketing metrics block (78/78, 100% uptime, data as of 2026-10-26) that does not help an agent decide or invoke correctly.

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 paid, side-effecting tool with no annotations and no output schema, the billing and refund story is covered, but key gaps remain: no explanation of the two optional parameters, no indication of what the call returns (job ID? demand-signal record?), and no statement of prerequisites such as an API key or existing credit balance.

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

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

Schema description coverage is 0% across all three parameters, so the description must compensate and does not. 'jurisdiction' is only loosely implied by 'for a town'; the 'needs' array (1–10 free-text strings) and 'official_site_url' are never mentioned, so an agent has no idea what belongs in them or why they matter.

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 ('Request coverage for a town') and immediately names the differentiator versus siblings check_coverage/list_coverage — this is a paid request that also creates a demand signal and starts a records agent. An agent can distinguish it from check_coverage and watch_town without opening another schema.

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

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

Usage is implied — you spend $5 here when a town is not already covered — but the description never explicitly says 'use this only after check_coverage reports UNCOVERED' or names a sibling as the alternative. The refund-after-14-days clause gives useful context on the outcome if coverage never lands, but the trigger condition is left to inference.

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

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

With no annotations, the description carries the full burden, and it does disclose one genuinely useful behavioral trait: the tool may return UNKNOWN, and UNKNOWN is never charged, so an agent knows a non-answer is possible and costless. However, it discloses nothing about permissions, rate limits, response shape, or what a positive result contains, and the accuracy/uptime statistics are marketing rather than actionable 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?

It is short, but almost the entire sentence is spent on golden-set accuracy, page-citation rate, and 24-hour uptime figures that do not help an agent decide or invoke. The one operational fact (UNKNOWN, no charge) is buried mid-sentence rather than 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 six-parameter, required-field domain-check tool with no output schema and no annotations, the description supplies neither the purpose, nor the parameters, nor the return contract. It is essentially unusable for correct invocation beyond guessing from the name.

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?

Six parameters at 0% schema description coverage, and the description mentions none of them — parcel, address, district, latitude, longitude, jurisdiction are entirely unexplained. It does not even note that jurisdiction is required or how to choose between address-based and coordinate-based lookup.

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 never states what the tool actually checks — it only restates the tool name and piles on provenance/uptime/accuracy claims. An agent learns that a 'solar siting check' exists and is free in beta, but not that it evaluates whether a parcel is suitable for solar development, nor how that differs from get_zoning or check_use_allowed.

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

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

There is no when-to-use, when-not-to-use, or alternative guidance at all, despite siblings like get_zoning, check_use_allowed, check_coverage, and get_site_report that clearly overlap. The only routing-adjacent statement is that it returns UNKNOWN for free while unwired, which is a caveat, not usage 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 at all, the description carries the full burden, and it does disclose genuinely useful traits: no charge while unwired, UNKNOWN as a possible response, page-cited output, and a data-as-of date. However it omits what verdicts are returned, whether auth or rate limits apply, and what happens once wired, leaving core behavior undefined for a 3-required-param tool.

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

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

It is a single sentence with no fat in length, but it is front-loaded with a beta disclaimer and marketing metrics rather than the tool's purpose. Every phrase earns its place only as sales copy, not as call guidance, so brevity does not translate into usefulness.

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?

No annotations, no output schema, three required undocumented parameters, and an undefined operation: an agent cannot determine what to send beyond raw values or what a response means. The marketing claims about golden accuracy (78/78) and uptime do not compensate for the missing operational contract.

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

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

Schema description coverage is 0%, so the description must explain all three parameters — epa_reg_no, lat, lon — and it explains none. It never mentions EPA registration numbers, coordinates, or any format/validity expectations, so the agent must infer semantics purely from parameter names and min/max bounds.

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 never states what spray_check actually does — no verb, no resource, no mention of pesticide/EPA registration, location eligibility, or what a verdict means. It only reports beta status, accuracy stats, and uptime, which restates the name rather than defining the operation. A sibling like check_use_allowed is not differentiated in any way.

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 call this versus the many closely named siblings (check_use_allowed, check_state_registration, check_license, solar_siting_check). The only usable signal is that the live source is unwired and returns UNKNOWN, which tells the agent the call is currently pointless but not what the tool is for or when to prefer 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 does substantial work: it discloses the 30-day watch window, HMAC-signed webhook delivery with retries, the $4.00/30-day USDC price, and that UNKNOWN results are never charged. It omits how to stop the watch (cancel_watch), whether re-registering the same parcel duplicates a watch, and any auth/credit-balance requirement, which keeps it below a 5.

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

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

The first sentence is excellent and front-loaded with scope, delivery, and price. The second sentence is largely promotional telemetry ('100% golden accuracy (78/78), 100% page-cited, 100% uptime (24h)') that consumes attention without helping an agent decide or invoke, and a data-as-of date adds only marginal freshness value.

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?

There is no output schema and no annotations, so the description must cover the full contract; it handles cost, cadence, and webhook delivery but leaves the required jurisdiction and parcel/address semantics undefined, and does not point at sibling tools for coverage checks or cancellation.

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 five parameters (including required jurisdiction and webhook_url) are undocumented anywhere. The description only glancingly implies a parcel identifier and an HTTPS webhook URL; it says nothing about label, address, or the expected format of jurisdiction, and never clarifies whether parcel is an APN versus a free-form string.

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 (watch), a specific resource (a parcel), the duration (30 days), the trigger (new permits or decisions touching it), and the delivery channel (HTTPS webhook). The parcel scope implicitly distinguishes it from the sibling watch_town, and an agent can tell what the tool does before 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?

Recurring monitoring is clearly implied, so the agent can infer when to call it, but there is no explicit guidance on parcel-level vs town-level watching (watch_town exists), no pointer to list_watches/cancel_watch for lifecycle management, and no stated precondition such as a supported jurisdiction (check_coverage exists).

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 does well: it discloses webhook delivery over HTTPS, HMAC signatures, retries, 30-day duration, USDC pricing, and that UNKNOWN results are not charged. It still does not explain subscription lifecycle details such as renewal, cancellation, or what happens if the jurisdiction 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 front-loaded with the core action and delivery mechanism, followed by pricing and verification claims. It is dense but reasonably structured; the accuracy and uptime statistics are somewhat promotional but still provide decision-relevant context.

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?

There is no output schema and no annotations, so the description should do more to explain what happens after the watch is created, how the subscription behaves, and what the agent should expect. It covers purpose, delivery, and price well, but leaves gaps around lifecycle, coverage prerequisites, and the label parameter.

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 adds meaning for keywords ('matching your keywords') and webhook_url (HTTPS webhook), but it does not explain the label parameter, jurisdiction format, keyword limits, or required status of parameters beyond what the schema already declares.

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 and resource: it watches a covered town for 30 days and delivers council/planning decisions matching keywords. It is clearly a subscription-style monitoring tool, but it does not explicitly distinguish itself from sibling tools such as watch_parcel or get_recent_decisions.

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 'covered town' implies that coverage must be checked and that this is town-level monitoring, but the description gives no explicit when-to-use guidance, exclusions, or alternatives. An agent must infer that check_coverage or list_coverage is a prerequisite and that watch_parcel is the parcel-level counterpart.

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