Tennessee Property Records

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

Annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavioral context the annotations do not: it is a non-parameterized orientation call that also surfaces usage terms and query tips, telling the agent this is a policy-and-context read, not a data read. Return format is not described, but with no output schema that is the only notable gap.

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?

"Start here" is front-loaded as an imperative, followed by a single dense sentence enumerating the covered content. Every listed item (counts, history depth, field coverage, sources, bulk files, tips, terms) is distinct and actionable, though the run-on enumeration could be grouped for faster scanning.

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 parameters and no output schema, the description carries the full burden of explaining what comes back, and it does so comprehensively across coverage, provenance, and terms. Nothing an agent needs in order to decide to call this first is missing.

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

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

The tool takes zero parameters, so there is no parameter meaning for the description to add. Baseline 4 applies; nothing is missing or misleading on this dimension.

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?

"Describes what data exists" names a specific verb and resource, and the enumeration (totals, county parcel/ownership counts, history depth, populated fields, sources, bulk files) makes the tool unmistakable against the query-oriented siblings like get_property or search_properties. An agent can tell this is the metadata/orientation tool 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?

"Start here" gives explicit ordering guidance that positions this tool ahead of the sibling query tools, and the reference to "query tips and usage terms" implies it should be consulted before constructing queries. It stops short of naming a specific alternative or stating when not to use it, so it is clear context rather than full routing guidance.

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

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

Annotations already establish readOnlyHint=true and openWorldHint=false, so the safety profile is covered. Beyond that, the description discloses the returned payload in detail and adds a genuine caveat — deed references and links appear only 'where the county provides them' — signalling variable data coverage that the agent would otherwise not expect.

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

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

A single front-loaded sentence leads with the scope before enumerating contents, and every clause conveys distinct information. The parenthetical listing of ownership-record attributes is dense but earns its place as return-value detail in the absence of an output schema.

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, the description carries the burden of describing return values and does so thoroughly. Remaining gaps are minor: it doesn't mention the include_geometry option or what happens when a parcel cannot be found.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds the alternative-lookup logic: pin alone suffices, while apn requires county to disambiguate. That relationship between parameters is meaningful even though the schema partially hints at it in the county field.

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 resource and scope: 'Everything known about one parcel', enumerating the parcel record, ownership history, sale history, and Register of Deeds link. This clearly separates it from list/search siblings like search_properties, though it doesn't name a 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?

It gives the lookup modes ('by pin, or by apn plus county') which is useful invocation guidance, but never states when to prefer this over search_properties, property_at, or owner_portfolio. Usage is implied by 'one parcel' 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 declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds useful behavior beyond annotations: results are historical and newest first, include current ownership status, acquisition date, price, summary counts, and mailing-address grouping of LLCs and trusts. It does not fully describe the response shape or pagination behavior, but pagination is covered by 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 three tightly written sentences with the core resource and ordering front-loaded. Every sentence contributes useful information about scope, returned attributes, and mailing-address grouping, with no filler.

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

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

For a six-parameter read-only query with no output schema, the description covers purpose, historical scope, ordering, returned ownership details, summary counts, and a non-obvious mailing-address behavior. It is nearly complete, though the exact response structure and what the summary counts contain are left implicit.

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

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

Schema description coverage is 100%, so the schema already documents limit, county, cursor, mailing, owner_key, and current_only. The description adds semantic value by contrasting owner_key and mailing-address lookup and by explaining that mailing-address searches group related LLCs and trusts sharing a mailbox, which is not obvious from the schema 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 clearly states a specific query resource: every property ever recorded for an owner, identified by owner_key or mailing address, with ownership status, acquisition date, price, and summary counts. It is easy to distinguish from generic property search, though it does not explicitly name sibling tools or contrast itself with them.

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

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

The description implies when to use the tool by explaining the owner_key and mailing-address input modes and the portfolio-history result. However, it gives no explicit when-to-use versus alternatives such as search_ownership_records or search_owners, and no exclusions or prerequisites.

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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so the safety profile is covered. The description adds a genuinely non-obvious behavioral trait — containment is computed against the actual parcel boundary rather than the nearest centroid — which tells the agent edge-case and accuracy behavior it could not infer from structured fields. It still omits the no-match / overlapping-parcel outcome.

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

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

Two short sentences, front-loaded with the core question and immediately followed by the semantic clarification. No filler, no restatement of the title.

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

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

For a simple two-parameter read-only lookup with full schema coverage, the description supplies purpose plus the key accuracy caveat. Remaining gaps — behavior on no match and result multiplicity — are minor given the tool's simplicity, though slightly more would make it airtight in the absence of an output schema.

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% with two required numeric parameters, so the schema already documents lat and lon. The description adds no coordinate-system, precision, or format detail beyond the schema, leaving the baseline 3 appropriate.

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

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

The description states a precise spatial question — 'Which parcel contains a latitude/longitude' — which is a specific resource (parcel) plus an implicit containment verb, clearly distinct from siblings like get_property and search_properties. It stops short of naming an alternative tool explicitly, so the differentiation is inferred rather than stated.

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

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

Usage is implied: call this when you have coordinates and need the containing parcel. There is no explicit 'use X instead when...' routing against get_property, search_properties, or owner_portfolio, and no note on prerequisites or what to do when a point falls in an unincorporated 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?

The annotations already declare readOnlyHint=true and openWorldHint=false, so safety behavior is covered externally. The description adds useful return-content context by listing the aggregate metrics, but it does not discuss ordering, performance, or how the limited group list is selected beyond what the schema implies.

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 definition is front-loaded, stating the aggregation outputs before examples, with no filler or repeated framing. The long enumeration of grouping dimensions is dense but necessary and remains readable.

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 carries the burden of explaining return content; it does this by naming the aggregate metrics and grouping dimensions. It is nearly complete for an aggregation tool, though ordering and default result behavior are left to the schema.

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

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

Schema description coverage is 100%, so the schema already documents limit, county, and group_by semantics. The description restates the available grouping fields and statewide/county scope, but adds no additional format, ordering, or filtering meaning beyond the schema.

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

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

The description states a specific aggregation resource and its returned metrics: parcel counts, total/average/median appraised value, and total acres. It also names the grouping dimensions and scope, making it distinguishable from search-oriented siblings like search_properties and get_property.

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 concrete usage examples such as 'largest owners in Davidson' and 'value by land use', and clarifies statewide versus single-county scope. It does not explicitly say when not to use this tool versus alternatives like owner_portfolio or search_owners, but the examples establish the intended context clearly.

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 domain context beyond that: results are newest-first, owner_change carries both old and new owners, and 'retired' specifically means the parcel is no longer listed by the county — nuances an agent could not infer from the schema alone. It stops short of disclosing pagination mechanics or default page size.

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

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

Front-loaded with the valuable part — what the feed contains and how the kinds are defined. The trailing 'Filter by county, kind, owner name, date or area' is largely redundant given complete schema coverage and could be dropped 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?

For a 10-parameter, read-only paged list with no output schema, the description covers purpose, ordering, record shape (old/new owners) and kind semantics — enough for correct invocation. Pagination is handled by the self-describing cursor parameter, so its absence from the prose is not a real gap.

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

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

Schema description coverage is 100%, so every parameter is already documented, including format examples for bbox, near and the date fields. The description only echoes the filter set and adds semantic gloss on the kind values, which is marginal beyond what the schema provides; baseline 3 applies.

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

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

States a specific resource (change records produced by update jobs) with a precise ordering guarantee (newest first) and enumerates the three kinds with short glosses, so the agent knows exactly what domain object it gets. It does not explicitly differentiate itself from siblings like search_ownership_records or property_stats, which keeps it from a 5.

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

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

'Filter by county, kind, owner name, date or area' describes which parameters exist rather than when to choose this tool over search_properties or search_ownership_records. There is no statement of when-not to use it, no prerequisite, and no alternative named, leaving routing entirely to inference.

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

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

Annotations already declare openWorldHint=true, idempotentHint=true, readOnlyHint=false and destructiveHint=false; the description adds that the fetch hits an external official source immediately and returns a diff, which explains why readOnlyHint is false (records get refreshed). It does not discuss latency, cost, rate limits, or what happens when the source is unavailable, which is the main remaining gap.

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 tight sentences: the first front-loads the action, scope, and result; the second gives the trigger condition. The parenthetical Davidson caveat is the only extra clause and it earns its place as a behavior an agent could not infer.

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

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

For a one-parameter, no-output-schema tool with annotations present, the description covers action, scope, trigger, and return shape ('what changed'). Only failure modes and refresh cost are unaddressed, which is a minor omission rather than a blocking one.

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 single parameter already documents comma-separated pins with a max of 5. The description restates the same max-5 limit but adds no format or edge-case guidance beyond the schema, so the baseline 3 applies.

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

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

States a specific verb and resource ('re-read up to 5 parcels from their official county/state source') plus the distinguishing behavior ('return what changed'), which separates it from plain read siblings like get_property. The scope cap and the Davidson owner-history special case are stated up front.

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

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

Explicit triggering conditions are given: 'when last_checked is too old for the question, or the user says a record is out of date.' This is a clear when-to-use rule. It stops short of naming the alternative sibling (get_property) for the fresh-read case or stating when not to refresh, so it is a 4 rather than 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 already declare readOnlyHint=true and openWorldHint=false, so safety is covered. The description adds genuinely useful behavioral detail beyond that: the search covers former owners by default, and each result carries owner_key, owned-ever vs. currently-owned counts, counties, and first/last acquisition dates.

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

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

Three tight sentences lead with what is searched, then what comes back, then the natural next step. No redundant restatement of the title or schema.

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, the description carries the burden of describing return values and does so concretely (key, counts, counties, dates). The main omission is behavior when a name matches many owners or how limit interacts with result ordering, but nothing essential for a correct call is missing.

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

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

Schema description coverage is 100%, so all four parameters are already documented, establishing a baseline of 3. The "current AND former" phrasing implies what current_only=false returns, which is a small clarification, but no extra syntax or edge-case detail is added for name matching or limits.

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

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

States a specific verb and resource ("Find people and companies by name") plus a non-obvious scope: searching current AND former ownership records. This distinguishes it from siblings like owner_portfolio (which takes a key) and search_ownership_records (record-level rather than owner-level).

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

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

Gives an explicit follow-up path: "Pass an owner_key to owner_portfolio for the full list," which clarifies the intended two-step workflow. It does not explicitly exclude or contrast with search_ownership_records or search_properties, so the alternative-selection guidance is clear but not complete.

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 the safety profile is covered. The description adds genuinely useful behavior — result cardinality (one row per owner per parcel) and the hard constraint that date-range searches cover a single county and at most 3 calendar months — but says nothing about pagination behavior or how a limit default is chosen ('default varies by tool' is only in 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?

Two sentences, front-loaded with the resource and lookup modes, and the closing example question earns its place by pinning down the intended query. The first sentence is heavily clause-stacked, which costs some readability but no words are 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?

For a 14-parameter, zero-required search tool with an output schema absent but annotations present, the description covers the key search modes and the non-obvious county/date-window restriction. Pagination and limit-default behavior are left to the schema, which is acceptable, but an explicit note that results page via cursor would close the remaining gap.

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

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

Schema description coverage is 100%, so the schema already defines every parameter and the baseline is 3. The description adds real meaning for one interaction only — county is mandatory and single-valued for date searches — while the remaining filter/sort parameters are merely restated, not elaborated beyond the schema.

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

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

The description names the resource and its grain precisely ('ownership records (one row per owner per parcel)') and enumerates the lookup keys: owner, owner_key, mailing address, pin, or a county transfer sweep. The filter and sort options plus a concrete example question make it distinguishable from siblings such as search_owners or owner_portfolio without opening either schema.

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

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

It gives clear when-to-use context via the county-plus-date-range path ('every transfer recorded in one county over up to 3 calendar months') and a sample question that shows the intended query shape. It stops short of explicit exclusions, e.g. when to prefer search_owners or property_at instead, so the agent must infer the boundary.

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 a read-only, closed-world search, so the description's added value is in disclosing the return payload (pin, address, owner, county, location, map link) and the cursor-based pagination contract, which annotations do not cover. It stops short of stating result ordering guarantees or the meaning of an empty result set, but the safety and paging profile is clear.

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 tight sentences: capability first, return values second, pagination pointer last. No filler, no repetition of the title, and the most decision-relevant information is front-loaded.

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

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

For a twelve-parameter search tool with no output schema, the description must carry the result shape and paging contract, and it does both. It is slightly thin on filter interaction (which parameters combine or conflict), but nothing essential for a correct first call 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 twelve parameters are already documented in detail, including examples, defaults and ranges. The description only restates that these filter dimensions exist; it adds no format or precedence rules beyond the schema, so the baseline of 3 applies.

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

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

The description opens with a specific verb and resource ('Find parcels') and enumerates the three search modes (address words, owner name, location by point or box) plus optional county/city/ZIP narrowing. The phrase 'current owner name' faintly distinguishes it from search_owners, but no sibling is named outright, 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?

It conveys the situations the tool covers (text, owner, proximity, administrative filters) and how to continue paging with next_cursor, which implies usage well enough. However, it never states when to prefer property_at or search_owners instead, and gives no guidance on which mode to pick when both q and owner could apply.

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 real value by making clear this is purely informational reporting (county checks, run statuses/counts, in-progress jobs, schedule), which resolves the ambiguity created by the mutation-sounding name. It says nothing about scope (all counties or a subset) or recency limits of the reported runs.

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

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

A single front-loaded sentence with a colon-delimited list of report contents; no filler. It is slightly list-like and lacks a leading verb, but every clause maps to something the agent will receive.

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 input parameters and no output schema, the description carries the burden of describing return contents, and it does so across four distinct data categories. The only gap is that it does not say whether results are scoped to all counties or a current job, which for a simple status endpoint is minor.

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. The description correctly implies a no-argument, whole-dataset report, and there are no parameter semantics that need explaining.

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 enumerates the specific content reported (per-county last-checked timestamps, recent update runs with status and counts, in-progress work, schedule), which makes the resource concrete. But it never states a verb ("returns", "reports") and the name 'update_status' reads like a mutation, so the agent must infer that this is a read-only freshness report. It also does not distinguish itself from siblings like recent_changes.

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 and no alternative named. The agent can infer it should call this to check data freshness before trusting results, but nothing states that, and nothing rules out overlap with recent_changes or refresh_property.

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