The Hiking World

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 real traits: schematic lines are flagged and are not GPS tracks, figures may be provisional, and null means 'not recorded'. It still omits the obvious read-only nature, error behavior for unknown slugs, and the response shape, and the permit-status paragraph reads as boilerplate copied from another tool rather than behavior of this one.

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?

Eight loose sentences with no grouping, mixing return-field semantics, citation advice, and permit-status vocabulary that may not even apply here. There is redundancy ('or null when the feed has none' immediately followed by 'Null means not recorded'), and only the first fragment 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?

With no annotations and no output schema, the description is the only source of return-value information, and it does cover the schematic flag, verifiedDate, and permit status. It is still incomplete: no GeoJSON structure, no error/empty-result behavior, and no signal about other fields the agent might encounter.

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?

One parameter with 0% schema description coverage, so the schema contributes nothing. The embedded URL template /trails/{slug}/geojson indirectly tells the agent that slug is the trail identifier, but there is no statement about format, uniqueness, or what happens if the slug is unknown.

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 phrase 'Trail line from /api/v1/trails/{slug}/geojson' signals that this returns the GeoJSON geometry for a trail identified by slug, which is specific enough to be understood. However it is a noun fragment rather than a verb+resource statement, and it never contrasts with the sibling get_trail, so an agent must infer the division of labor.

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 statement relative to get_trail, search_trails, or get_permit. The one routing hint is conditional and about a follow-up step ('A returned figure can be verified with get_provenance'), which implies when to reach for a sibling but not when to choose 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 and largely succeeds: it defines the tier vocabulary, explains that ambiguous names return candidates rather than a single record, clarifies that a null costLocal is not a number and null status means 'not recorded', warns figures may be provisional, and offers a verification path via record signature. Auth requirements and any rate limits are unaddressed, which keeps it short of 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?

It is front-loaded with the most important information, but the trust-tier vocabulary is stated twice (once for 'tier', once for 'permit status') and the sourcing/dated/provisional caveats are spread across several short sentences that could be consolidated. Adequate but not tight.

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 explain both the return shape and the behavioral caveats; it does both, including null handling and the provenance follow-up. The main omission is any statement about permissions or error behavior, which is minor for a single-parameter read 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 description coverage is 100% for the single 'trail' parameter, so the schema already documents slug-or-name input. The description adds only marginal semantics beyond that — the note that ambiguous names return candidates — 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?

States a specific verb+resource ('Sourced permit fee for a named trail') and enumerates the returned fields (costLocal, tier, issuer, source URL, read-date), so an agent knows this returns fee/status data rather than trail geometry or itinerary planning. It does not explicitly contrast itself with get_trail or plan_permits, but the resource is narrow enough to be distinguishable.

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 guidance is mostly about output handling ('Do not quote reported-secondary or unverified as official') rather than when to call this tool versus siblings. It does point to one alternative for verification ('can be verified with get_provenance'), but gives no condition for choosing get_permit over get_trail or plan_permits.

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 meaningful work: it discloses that figures are sourced and dated, may be provisional, defines the permit status values (verified-official, reported-secondary, unverified), and explains that null means not recorded. It also asserts the server does not invent figures, a data-integrity note. It omits auth/rate-limit behavior, but for a zero-param read tool this is solid disclosure.

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?

Six short sentences, mostly earning their place, and the content is front-loaded with what is returned. But 'or null when the feed has none. Null means not recorded.' is redundant, and the opening fragment is abrupt. Slightly padded for the amount of information conveyed.

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 must characterize the return, and it does: public key, signing policy, verification recipe, and the permit-status value set. Combined with zero parameters and no annotations, it covers what an agent needs to call and interpret the result. It could be more explicit about the shape of the verification recipe, but it is largely complete.

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

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

The tool takes no parameters, so parameter semantics are not applicable and the baseline of 4 applies per the rubric. The description instead spends its text on return-value semantics, which the absent output schema would otherwise leave 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 names the resource (public key, signing policy, verification recipe) and its source endpoint, so an agent can infer it fetches provenance metadata. However, it is written as a noun fragment with no explicit verb, and it never states plainly what the tool does relative to siblings like get_permit or get_updates. The purpose is implied 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?

It advises citing the trail URL and verifiedDate, which is output-handling guidance, not call guidance. There is no indication of when to use this tool versus get_permit, get_updates, or get_trail, nor any prerequisites. An agent gets no routing help from this 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 not-found behavior for unknown slugs, that figures may be provisional, that permit status is one of three enumerated values or null when unrecorded, that null means 'not recorded', and that figures should be verified via get_provenance. It stops short of auth requirements, rate limits, or caching 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?

Front-loaded with the resource and its contents, then the error case, then semantics. It is somewhat choppy in its many short declaratives and spends several sentences on citation/null policy, but each sentence carries distinct information rather than 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?

With no output schema and no annotations, the description compensates well by naming the record's key fields (permits, provenance, geometryUrl) and interpreting the permit-status values and null semantics. For a single-parameter read tool this is nearly complete; only the remaining record fields and any auth/pagination notes are unaddressed.

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

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

Schema coverage is 100% and the single slug parameter is fully documented in the schema with an example, so the baseline is 3. The description only adds the negative case ('Unknown slug returns not found'), which is behavior rather than parameter meaning, so it does not exceed the baseline.

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

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

States a specific verb and resource ('Full sourced trail record from /api/v1/trails/{slug}') and enumerates what the record contains (permits, provenance, geometryUrl), so an agent knows exactly what it gets. It does not explicitly draw the boundary against siblings like get_permit or get_geojson, which it could have done to prevent overlap confusion.

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 context is implied rather than stated: it reveals the error case ('Unknown slug returns not found') and a follow-up path ('can be verified with get_provenance'), which guides the agent. There is no explicit when-to-use-this-vs-search_trails or prerequisite statement, so the guidance is adequate but incomplete.

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 ordering (newest first), the field set per row, provisional/dated status of figures, the three permit status values plus null semantics, and an explicit non-fabrication guarantee. It omits auth, rate limits, and pagination behavior beyond the schema's limit.

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 resource and ordering, then row contents, then caveats. Sentences are short and mostly load-bearing, though the staccato 'Figures are sourced and dated. They may be provisional.' could be compressed.

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 must describe return values, and it does: per-row old figure, new figure, issuer, source URL, and citation, plus permit status enumeration and null meaning. Missing only operational details like auth and pagination limits.

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 and schema coverage is 100%, so the schema already documents 'limit' fully. The description adds no syntax or format detail for it; 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?

States a specific resource and scope: confirmed permit-fee changes from /updates.json, newest first. It implicitly distinguishes itself from siblings like get_permit and get_provenance by describing change records, though it never names an alternative to route away ambiguity.

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

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

There is no when-to-use vs when-to-use-an-alternative guidance and no mentioned alternative among the eight siblings. The citation instruction ('Cite the trail URL and the verifiedDate') is output-usage advice, not tool-selection 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 delivers real behavioral context: figures are sourced and dated, may be provisional, the server 'does not invent figures,' null means 'not recorded,' and results are verifiable via get_provenance and the record signature. That is substantive provenance/trust disclosure beyond any structured field, though it still doesn't describe the shape of the returned 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?

The purpose is front-loaded, but the middle sentences (permit status enum values, 'null means not recorded') are dumped without ever saying that permit status is a field in the country results, so they read as noise for a countries-list call. The passage is longer than the task warrants and its logical order is loose.

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, parameterless list tool with no output schema, the description supplies useful data-quality caveats and a verification path. It still omits what the response actually contains (country names? figures per country? ordering?), leaving the agent to guess the return shape.

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 semantics to describe and the baseline is 4. The description appropriately spends no effort on input syntax.

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 clause, 'Distinct countries on /api/v1/trails,' gives a specific resource and verb, but the purpose is immediately muddied by a long digression into 'figures' and 'permit status' whose relationship to a countries list is never explicitly stated. There is no differentiation from the sibling list_regions, so an agent must infer the boundary between the two.

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 indirect workflow guidance ('Cite the trail URL and the verifiedDate') and points to get_provenance for verification, which is useful routing. However, it never states when to use this tool versus list_regions or search_trails, so the usage boundary is only implied.

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

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

With no annotations, the description carries the full burden and does a good job: it discloses that figures are sourced and dated, may be provisional, lists the permit-status enum values, explains that null means 'not recorded' when the feed lacks status, and states the server 'does not invent figures.' It also points to get_provenance and a record signature for 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?

Front-loaded with the core purpose, but the back half sprawls across permit-status enums, null semantics, and provenance advice that read as loosely assembled caveats rather than tightly scoped statements. Most content is useful, but the structure is muddled.

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 or annotations to lean on, and the description adequately covers the caveats an agent needs: data freshness/provisionality, null handling, enum values, and how to verify a figure via get_provenance. Some return-shape detail is absent, but the behavioral surface is well covered.

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 for the description to compensate for; the 4 baseline for a 0-param tool 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 clear verb and resource: distinct region and country names on the /api/v1/trails endpoint, with the intent 'so an agent can see coverage.' It does not, however, differentiate itself from the sibling list_countries, leaving overlap ambiguous.

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?

Implies when to use it ('so an agent can see coverage') but never states when not to use it or names the obvious alternative, list_countries. Usage context is inferable rather than explicit.

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 substantive traits: figures are never authored/invented, totals may be absent, values are sourced and dated and may be provisional, and status is one of verified-official/reported-secondary/unverified/null. It stops short of stating read-only nature, auth needs, or how the plan is scoped to a trail.

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 clause is front-loaded, which is good, but the body is a run of short clipped fragments with redundancy ('does not author fees' restated as 'does not invent figures'). It is not bloated, but several sentences could be merged 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 annotations and no output schema, the description does a reasonable job covering output semantics and null handling. However, it never explains what a 'plan' actually contains or when the tool should be chosen over its siblings, leaving a real gap for an agent deciding between the nine available tools.

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

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

Schema description coverage is 100% and there is a single required 'query' parameter, so the schema already defines it. The description adds no syntax or format guidance for the query beyond echoing the schema's 'no fee figures' constraint, 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 phrase 'Structured permit plan from stored rows only' names the resource (a permit plan) but leaves the action vague and never distinguishes this from siblings like get_permit or get_provenance. Most of the description is output policy rather than a statement of what the tool does, so an agent must infer the core purpose.

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 alternatives are named, despite a crowded sibling set (get_permit, get_provenance, get_updates). Nothing tells the agent when to reach for a 'permit plan' versus fetching a single permit.

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 and no output schema, the description carries the full burden and delivers meaningful behavioral context: figures are sourced and dated, may be provisional, permit status is enumerated (verified-official, reported-secondary, unverified, or null), and null explicitly means 'not recorded.' It stops short of permissions, rate limits, or pagination, but the data-trust semantics are unusually well disclosed.

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, but the body drifts into a provenance lecture with redundancy ('Figures are sourced and dated. They may be provisional... This server does not invent figures'), consuming space that the undocumented input filters needed.

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 seven-parameter tool with no annotations and no output schema, the description details output trust signals but omits any guidance on the inputs an agent must actually supply. It is under-specified where the risk of a wrong call is highest.

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

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

Schema description coverage is only 14% (just sacScale), and the description explains none of the seven inputs — region, country, distance bounds, maxTypicalDays, or permitRequired. The word 'Filter' implies these exist but adds no meaning beyond the schema names, leaving the coverage gap unpatched.

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 specific verb and resource: 'Filter trail summaries from /api/v1/trails.' This is a concrete operation, though it never distinguishes itself from the sibling get_trail, so an agent must infer that search_trails is the multi-criteria list while get_trail is the single-record fetch.

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 search versus get_trail, get_geojson, or the list_* tools. The only routing hint is 'a returned figure can be verified with get_provenance,' which is post-hoc verification, not selection guidance for this tool.

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