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's 'Makes no network call' adds corroborating context, but it repeats what openWorldHint=false already implies and says nothing about the shape or timing of the returned report.

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 waste, with the core purpose front-loaded before the network-call caveat.

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 no-parameter, read-only diagnostic tool with no output schema, the description is nearly sufficient. It could say slightly more about the report contents, but nothing an agent needs to call it 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 nothing to disambiguate; baseline 4 applies. The schema itself is trivially 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?

States a specific verb and resource ('Report this session's live calls and cache use'), so an agent knows this is a session-level diagnostic. It doesn't explicitly contrast with any sibling, but the geospatial siblings make the distinction obvious.

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 or when-not-to-use guidance; usage is only implied by the description's diagnostic nature. 'Makes no network call' hints that it is cheap to call, but does not tell the agent which situations warrant it.

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=true, so safety is covered. The description adds real behavioral context beyond that: the returned chain of counties, the meaning of 'attached to' and 'contested', the 2000 cutoff, and the caveat that some results need manual verification.

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 purpose is front-loaded in sentence one, and each following sentence carries genuine domain information rather than filler. It is longer than strictly necessary and slightly discursive, but no sentence is wasted.

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

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

With no output schema, the description usefully characterizes the return (holder(s), full chain, within-a-year changes) and the tool's scope limits. It omits edge-case behavior such as out-of-range dates or points outside the covered area, which keeps it from a 5.

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 latitude, longitude, date and refresh are already fully documented, including the year/month expansion behavior. The description adds no syntax or format detail 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?

The opening sentence states a precise verb and resource: which county held a point on a date, plus the act that made it so. That is a specific point-in-time lookup that is inherently distinguishable from siblings like county_history (history of a named county) without needing to name 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?

It gives strong contextual guidance: records were made by the county that held the place THEN, boundary_change_within_a_year should be checked by hand, and the atlas ends in 2000 and holds no towns or townships. It never explicitly names an alternative sibling or states when not to use this tool, so it stops short of a 5.

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

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

Annotations already declare readOnlyHint=true and openWorldHint=true, but the description adds real behavioral context: the shape of each returned version (dates, event string, statute) and the non-obvious atlas convention of filing counties under their modern state. It does not cover caching/rate-limit behavior beyond the schema's refresh note.

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

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

Front-loaded with purpose, then a concrete example of a returned event, then the sibling routing rule. Sentences are short and each earns its place, though the telegraphic fragment style ('Each version carries its dates, the event..., and the statute.') borders on clipped.

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 return-shape burden and discharges it by naming the per-version contents (dates, event, statute). For a single-county lookup, pagination is unlikely to matter, so nothing critical is missing.

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

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

Schema description coverage is 100%, so all three parameters are already documented, including the modern-state convention for 'state' with its own WV example. The description reinforces that convention but adds no syntax, format, or edge-case detail the schema lacks; 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 precise verb+resource: returns every version of one county over time, with creation date, parent source, and each subsequent change, plus the statute citation. It explicitly contrasts itself with the sibling county_at, so an agent can pick correctly without inspecting 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?

Names the alternative (county_at) and the exact condition that selects it: use county_at for 'a particular place,' because a county's history does not record which version held a given farm. This is an explicit when-to-use-this vs when-to-use-that statement.

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 declare readOnlyHint=true and openWorldHint=false, and the description is consistent (a local lookup that produces query arguments, not a live search). The added disclosure that the tool does not itself perform the NARA search and instead returns arguments is valuable behavioral information beyond the annotations, though the exact return shape is only loosely described.

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 purpose and the patent-vs-case-file distinction are front-loaded, and the relevant caveats follow. It is dense but each sentence carries domain weight (provenance of dates, warrant assignee, the cross-server return contract), 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?

Six parameters with no output schema, but the description compensates by explaining what the return is (arguments for search_records_advanced) and by grounding the ambiguous date/name fields. It is complete enough for correct invocation, with only minor gaps around the exact output structure.

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

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

Schema coverage is 100%, so baseline is 3, and the description earns above that: it clarifies that signature_date is the patent's date and not the entry/purchase/settlement date, that authority is as GLO gives it, and that patentee may be an assignee on a military warrant. These are semantic caveats the schema alone does not convey.

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 transformation: given a land patent, find the entry/case file, its location, and the search to run. The verb+resource (find the land entry file behind a patent) is clear and the domain is distinct from the geographic siblings (plss_locate, county_at). It stops short of naming a sibling to disambiguate against, so 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?

It gives real usage context: the patent proves a conveyance only on its signature date, and homestead/military-warrant cases require looking beyond the patent. Critically, it states that it returns arguments for nara-catalog-mcp's search_records_advanced and that this server cannot call it, telling the agent how the output is meant to be consumed. No explicit exclusion against siblings, but the routing guidance is strong.

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

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

Annotations only declare readOnlyHint and openWorldHint; the description adds the non-obvious behaviors that matter: no network call, free-text matches ANY word and is ranked, and pre-July-2026 links now degrade to the home page. These are exactly the quirks an agent could not infer from annotations or 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?

Roughly 60 words, purpose front-loaded in the first clause with the operational caveat immediately after. Every sentence carries information; the only minor cost is the fragmented line breaks rather than a single flowing statement.

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 still conveys the return artifact ('a link ... for the user to open') and that no network call occurs. Combined with the ranking and citation caveats, an agent has everything needed to build and present the link correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds real semantic value: it explains that search_text matching is per-word and ranked, that state and document_category should accompany free text, and that document_id links a single record. That goes beyond the neutral schema descriptions.

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

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

States a concrete verb and resource: 'Build a link to BLM's General Land Office Records site for the user to open,' and adds 'No network call' to distinguish it from data-fetching siblings like find_land_entry_file. It does not name a sibling explicitly, so it falls short of full sibling differentiation.

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 substantive operating guidance: add a state and a category to counter GLO's ANY-word matching, note there is no surname field, and prefer citing a patent by accession/document number/state/signature date rather than a link when it predates July 2026. It never states when to prefer this tool over a sibling such as find_land_entry_file or plss_locate, so there are no explicit alternatives.

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 declare readOnlyHint and openWorldHint=false; the description reinforces this ('Makes no network call') and adds real behavior context beyond annotations: the accepted input dialects, aliquot expansion behavior, and that `warnings` reports guesses while `raw` preserves the original text.

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

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

Front-loaded with the core purpose, then format coverage, then output semantics, then routing. Dense but each clause carries information; the format examples are somewhat list-heavy but justified for a parser.

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, and the description covers the key return concepts (`raw`, `warnings`) though not their exact structure. Given a two-parameter read-only parser, an agent has enough to invoke it correctly.

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

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

Schema coverage is 100%, so the baseline is 3, but the description adds meaning by enumerating the accepted text formats (0840N/0390W, T84N R39W, E½NE, words, lots, tracts) and explaining that state allows a missing meridian to be inferred.

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+resource: 'Read a Public Land Survey description into its parts.' It clearly distinguishes itself from siblings like plss_locate by describing the parse step and routing the placement step elsewhere.

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?

Ends with an explicit handoff: 'Pass a tract to plss_locate to place it on the map,' and notes 'Makes no network call,' which frames when to use it locally. No explicit when-not-to-use case, but the alternative is named and the boundary is clear.

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

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

Annotations already declare readOnlyHint and openWorldHint, so the safety/external-service profile is covered. The description adds genuinely non-structured behavior: results only exist in states that were once federal public domain. It does not mention caching or response latency, which the refresh parameter 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?

Three short sentences, front-loaded with what the tool returns, followed by the use case and the failure condition. Every sentence carries information an agent needs; nothing is padded.

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 usefully names the returned fields and the geographic limitation. It stops short of saying what a non-result looks like (null vs. empty vs. error) or whether results are cached, minor gaps for a read-only 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 100%, so latitude, longitude and refresh are fully documented in the schema. The description adds nothing about coordinate format, hemisphere handling, or the cache behavior, 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 ('Name the Public Land Survey tract at a point') and enumerates the returned hierarchy (township, range, section, quarter-quarter). The 'from_point' direction is clear enough to separate it from the reverse-lookup sibling plss_locate, though no sibling is named explicitly.

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

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

Provides a concrete use case ('turn a map pin (a cemetery, a farmstead) into the description a land patent or tract book would carry, then search the land records with it') and a real exclusion: it returns nothing outside federal public-domain states. No alternative tool is named for the reverse direction.

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 and openWorldHint, but the description adds substantive, non-obvious context: the precision levels reached (township/section/aliquot/lot), the warning that a centroid can be up to half a mile off, and divergence from the original plat near correction lines and water. It omits caching behavior, though the refresh parameter implies a cache.

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

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

Purpose and return values are front-loaded in the first two lines before the caveats, which is good structure. The prose is slightly literary ('A tract is not a house') and leans on metaphor, costing a little economy without losing meaning.

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 usefully enumerates the returned fields (centroid, bbox, BLM ids, precision) and warns about accuracy limits, a key gap for a coordinate tool. It does not address failure modes for unparseable or ambiguous land descriptions, leaving a modest 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 coverage is 100%, so all three parameters (state, description, refresh) are already documented in-schema with examples and defaults. The description adds no syntax or format detail beyond the schema, so the baseline 3 is appropriate.

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

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

The first sentence gives a specific verb and resource ('place a federal land description on the map, using BLM's PLSS data'), which clearly separates it from the reverse-geocoding sibling plss_from_point and the text-only parse_legal_description. It also enumerates what is produced (centroid, bbox, BLM ids, precision).

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

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

It explicitly routes the downstream step to a sibling ('pass the centroid and the patent's date to county_at'), which is clear conditional guidance. However it never states when to prefer this over plss_from_point or parse_legal_description, so the sibling differentiation is one-directional.

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

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

With readOnlyHint=true and openWorldHint=false already declared, the description reinforces this with 'No network call' and goes further by describing what a result contains (principal meridians for public-land states, Ohio's surveys, Spanish and French claims). It does not discuss error cases for invalid state input, but adds real context beyond the annotations.

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

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

The key question is front-loaded and each following sentence carries information about why a nil result occurs and what the answer includes. Slightly verbose and the mid-sentence line break in the first paragraph is awkward, but no sentence is wasted.

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

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

With no output schema, the description must convey the return content itself, and it does: state status, where the first-title records live, principal meridians, and special survey/claim cases. It could be marginally more explicit about the response shape, but an agent has enough to call it and interpret results correctly.

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

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

Only one parameter with 100% schema coverage ('A state, as a two-letter code or a name'), so the schema fully documents the input. The description adds no input-format detail beyond what the schema already states, making 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 opening question states exactly what the tool answers: whether a state was federal public domain and, if not, who granted its land. This is clearly distinct from coordinate/PLSS siblings like plss_locate and plss_from_point, and the 'No network call' note signals it is a local reference lookup.

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 explains the situation in which the tool matters: in a never-federal state a patent search comes back nil, and that nil says nothing about the family, so the agent needs the state-level provenance instead. It does not explicitly name sibling alternatives or state exclusions (e.g. 'do not use for PLSS coordinates'), so it stops short of a 5.

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