Sourced trail facts. Tiers verified-official, reported-secondary, or unverified. Gaps stay empty.
Scored across 9 tools
Each tool targets a distinct data slice (geometry, fees, provenance, full record, recent changes, catalog listings, aggregated plan, search), and descriptions explicitly cross-reference each other to steer selection (e.g. get_permit for fee-only vs get_trail for route facts). The only soft boundaries are within the permit/record cluster: get_trail also returns permits and a geometry URL, and plan_permits aggregates stored permit rows, so an agent could occasionally pick the heavier tool for a single-fee question.
All nine names follow a strict snake_case verb_noun pattern with verbs that map cleanly to intent: get_* for single-record retrieval, list_* for catalog enumeration, search_* for filtering, plan_* for aggregation. There are no style mixes or vague verbs.
Nine tools is squarely in the well-scoped range, and each one covers a distinct facet of a read-only trail catalog (facts, geometry, fees, updates, provenance, country/region listings, search, permit planning). No tool appears redundant padding.
The surface covers the read-only lifecycle well: discovery (list_countries, list_regions, search_trails), detail (get_trail, get_geojson), fees (get_permit), change tracking (get_updates), verification (get_provenance), and a composite intent (plan_permits). Minor gaps remain: no batch/multi-slug trail fetch, no tool for other trail facts mentioned only inside get_trail (e.g. grade is not independently queryable), and no update/create operations, though the 'stored, never invented' framing suggests a deliberately read-only domain.
Returns the stored line GeoJSON for a trail slug. Use when the client needs geometry; use get_trail for summary facts. Schematic lines are flagged. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), so the bar is lower. The description nonetheless adds real behavior: null is returned when geometry is absent, schematic lines are flagged, and no figures are fabricated—important for trusting the payload. It stops short of describing the returned geometry's coordinate structure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four short sentences, front-loaded with what is returned and followed by routing and behavioral caveats. Efficient overall; "Never invents figures" is slightly colloquial phrasing for "no fabricated values" but still earns its place.
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 read tool with no output schema, the description covers return content, fallback behavior (null), data-quality flagging, and sibling routing. Only the shape of the GeoJSON payload itself is 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?
The schema has zero description coverage and the single parameter is undocumented there, so the description must carry the load. It does clarify that the slug identifies a trail (not a region or permit), but it gives no format, casing, or lookup expectations, leaving some ambiguity unresolved.
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 ("Returns the stored line GeoJSON for a trail slug") and explicitly contrasts with the sibling get_trail, which serves summary facts. An agent can pick between the two 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?
Gives an explicit selection rule ("Use when the client needs geometry") and names the alternative tool with its own condition ("use get_trail for summary facts"). This is the when-to-use/when-to-use-something-else pattern at full strength.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns permit fee rows (costLocal, issuer, readDate, tier). Use for fee and booking questions; use get_trail for distance and grade. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| trail | Yes | Slug or trail name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is covered. The description adds genuine behavioral context those annotations cannot: the tool never fabricates figures and returns null when a value is not stored, which tells the agent how to interpret missing data. It stops short of saying whether one row or many are returned per 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?
Three short sentences, each carrying distinct payload: return shape first, then routing, then data-fidelity caveat. Nothing is redundant 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?
With no output schema, the description correctly compensates by naming the returned columns and the null convention. For a single-parameter read tool with full annotation coverage this is close to sufficient; only the row cardinality and the meaning of 'costLocal' (presumably local currency) 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?
The schema has 100% description coverage, documenting the single 'trail' parameter as 'Slug or trail name', so the description starts at the baseline. It adds no syntax, format, or resolution guidance (e.g. how slug vs display name is matched) beyond what the schema already supplies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns permit fee rows') and immediately enumerates the returned fields (costLocal, issuer, readDate, tier), which pins down what an agent actually gets back. It explicitly distinguishes itself from get_trail, though it does not clarify its boundary against plan_permits, which also concerns permits/booking and could be confused with it.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear when-to-use clause ('Use for fee and booking questions') plus a named alternative for a different concern ('use get_trail for distance and grade'). The routing guidance is concrete but incomplete — the sibling set includes plan_permits and get_provenance, and neither is addressed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the public signing key and verification recipe. Use to validate a get_trail signature, not for trail facts. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive, so the safety profile is covered. The description adds genuine behavioral context beyond that: it never fabricates figures and returns null when data is not stored, which tells the agent how to interpret an empty result. It stops short of describing the structure or trust properties of the 'verification recipe' itself.
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 is returned, then usage, then a caveat about nulls. Every sentence carries distinct information and none restates the name or 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 zero-parameter read-only tool with no output schema, the description covers what comes back at a high level and how to behave when data is absent. The remaining gap is that the format and fields of the 'verification recipe' are never characterized, which matters because there is no output schema to fall back on.
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 disambiguate; baseline is 4. The description correctly avoids inventing parameter guidance for a no-argument tool.
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 ('Returns the public signing key and verification recipe') and immediately distinguishes itself from get_trail by declaring it is 'not for trail facts'. An agent can tell exactly what this produces without opening any other tool's schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives an explicit when-to-use condition ('validate a get_trail signature') and an explicit when-not ('not for trail facts'), naming the sibling tool that serves that other purpose. Nothing about tool selection is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns the full sourced trail record (distance, grade, permits, geometry URL). Use for route facts; use get_permit for fee-only questions. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Trail slug, for example inca-trail |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely non-obvious behavior beyond that: it never fabricates figures and returns null when a value is not stored, which tells the agent how to interpret gaps rather than treating them as errors. It omits what happens when the slug itself is unknown (error vs. null), leaving one behavioral 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?
Three short clauses with zero filler: the return payload is front-loaded, the sibling routing follows, and the null/data-integrity caveat closes. Every sentence carries distinct information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully names the fields returned, and it clarifies the null semantics an agent needs to interpret the response. The only meaningful omission is behavior for an unrecognized slug, which matters for a required-key lookup 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% and the single slug parameter already has a description plus an example ("inca-trail"), so the schema carries the parameter semantics. The description adds no format, casing, or slug-resolution detail beyond that, making the baseline 3 correct.
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 ("Returns the full sourced trail record") and enumerates the returned fields (distance, grade, permits, geometry URL), which pins down scope precisely. It also implicitly separates itself from search_trails by being a single-record lookup keyed on slug.
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 routing rule: "Use for route facts; use get_permit for fee-only questions," naming the alternative and the condition that selects it. It does not cover other plausible alternatives such as get_geojson for geometry or search_trails for discovery, so the guidance is clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns confirmed permit fee changes from /updates.json. Use for what changed recently, not current fees (use get_permit). Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many changes to return. Default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds genuinely new behavior: the backing endpoint, that figures are never invented, and that null is returned when nothing is stored. It leaves 'confirmed' undefined, which is the one piece of behavioral meaning still missing.
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, no filler: purpose and source first, then the usage split, then the null/no-fabrication caveat. Every clause carries information an agent needs.
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 one optional parameter and no output schema, the description supplies what an agent needs to call it and to interpret an empty result (null). It does not describe the fields of each returned change record, which is a minor residual gap for a no-output-schema tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% and the single limit parameter is fully documented in the schema, including its default and 1-50 bounds. The description adds nothing about limit, 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 ('Returns confirmed permit fee changes') plus the underlying source (/updates.json), and explicitly contrasts itself with the sibling get_permit. An agent can distinguish this from a current-fee lookup without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives both the when ('what changed recently') and the when-not with a named alternative ('not current fees (use get_permit)'). This is explicit routing guidance rather than implied usage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns distinct country names from the catalog. Output: countries[] of strings. Use with list_regions to scope search_trails. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint, and nondestructive behavior, so the safety profile is covered. The description adds the return shape ('countries[] of strings') and a data-integrity caveat about returning null when data is not stored, but that caveat is oddly phrased for a list of country names and creates ambiguity about whether the tool returns an array or null.
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, with the output shape and the usage hint front-loaded before the caveat, so an agent can skim it quickly. The closing caveat ('Never invents figures') is slightly mismatched to a country-name list and could be trimmed or reworded.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only lookup with no output schema, the description covers the return shape and the downstream usage, which is what an agent needs to call it. The remaining gap is the ambiguous null-versus-array behavior, which is the one point an agent would want clarified.
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 the description must compensate for beyond the schema. The description correctly doesn't invent arguments or filters, which matches the empty input 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 a specific verb and resource ('Returns distinct country names from the catalog') and specifies the distinctness of the results, which is more than a restatement of the name. It doesn't describe how it differs from get_geojson on the sibling list, 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?
'Use with list_regions to scope search_trails' gives a concrete downstream workflow, telling the agent where this tool fits in a chain. It never states when not to use it or what the alternative would be, so it is clear context rather than explicit routing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns distinct region names and countries from the catalog. Parameters: none. Output fields: regions[] with name, country, slug. Use before search_trails to see coverage; pair with list_countries. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: it is parameter-free, it enumerates the returned fields, and it discloses that missing data surfaces as null rather than being fabricated.
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 compact clauses for parameters, output, positioning, and null handling. Every sentence earns its place, though the fragment-style phrasing ('pair with list_countries') is slightly telegraphic rather than a complete instruction.
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 list tool with no output schema, the description carries the return shape itself and adds null behavior, which is the right level of detail. The one soft spot is that 'returns null when not stored' does not specify whether null applies to a field, a record, or the whole response.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With zero parameters the baseline is 4, and the description correctly confirms 'Parameters: none', matching the empty schema. No additional parameter meaning is possible for this tool.
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: 'Returns distinct region names and countries from the catalog.' It also names the exact output fields (regions[] with name, country, slug) and positions itself relative to siblings by saying it should be paired with list_countries and run before search_trails, so an agent can tell it apart without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives concrete when-to-use guidance ('Use before search_trails to see coverage') and names the complementary sibling ('pair with list_countries'). It does not state any when-not condition or explain what makes list_countries the better choice for country-level enumeration, which keeps it short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns a structured permit plan from stored rows only. Use when the user needs a multi-trail permit checklist, not raw trail geometry. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | Trail name or permit question. No fee figures. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety and determinism are covered. The description adds genuinely new behavioral facts beyond that: data is sourced only from stored rows, figures are never fabricated, and null is returned when data is absent. What is missing is any sense of the shape of the returned plan, but that gap is modest.
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 is returned, followed by usage context and behavioral guarantees. There is mild redundancy between "from stored rows only" and "returns null when not stored," but 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 one documented parameter, rich annotations, and no output schema, the description covers purpose, when-to-use, data provenance, and null semantics — enough to call it correctly. A more concrete idea of what a "structured permit plan" contains 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% and the single parameter is documented as "Trail name or permit question. No fee figures." The description adds no syntax, format, or example guidance for the query beyond what the schema already states, so this sits at the baseline for fully documented schemas.
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 — returns a structured permit plan from stored rows — and adds a scope qualifier (multi-trail permit checklist) that separates it from geometry-returning siblings like get_geojson. It does not explicitly contrast with the closest sibling, get_permit, so it falls short of 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?
"Use when the user needs a multi-trail permit checklist, not raw trail geometry" gives a clear use condition plus an implicit exclusion that routes geometry requests elsewhere. It stops short of naming the alternative tools (get_geojson, get_permit) explicitly, which is what a 5 would require.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Returns trail summaries filtered by country, region, or distance. Use to shortlist trails before get_trail. Never invents figures; returns null when not stored.
| Name | Required | Description | Default |
|---|---|---|---|
| region | No | ||
| country | No | ||
| sacScale | No | SAC grade such as T3 | |
| maxDistanceKm | No | ||
| minDistanceKm | No | ||
| maxTypicalDays | No | ||
| permitRequired | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds a genuinely useful trait beyond that: it 'never invents figures; returns null when not stored', which tells the agent how to interpret missing data. It stops short of describing result ordering, count limits, or pagination 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?
Two short sentences, front-loaded with the resource and filter scope, then the workflow pointer, then a data-quality caveat. No wasted wording.
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 7 optional parameters, no required params, and no output schema, the description should say what happens when no filters are supplied and roughly what a 'trail summary' contains. It covers the null-handling contract but leaves the unfiltered/default behavior and result size unspecified.
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), so the description carries most of the burden. It names country, region and distance as filter concepts but adds no format, matching, or unit semantics, and leaves maxTypicalDays and permitRequired entirely undocumented in both schema and description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Returns trail summaries') plus the filtering axes, and names the sibling it feeds into (get_trail), so an agent can distinguish it from get_trail/get_geojson. It falls short of 5 because the stated filter set (country, region, distance) omits three real filter dimensions present in the schema (sacScale, maxTypicalDays, permitRequired).
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Explicitly says to use this 'to shortlist trails before get_trail', which gives a clear position in the workflow relative to a named sibling. It does not state when not to use it (e.g. no guidance on whether zero filters is acceptable or when to prefer get_geojson/plan_permits).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_geojsonget_permitget_provenanceget_trailget_updateslist_countrieslist_regionsplan_permitssearch_trails
Add one secure layer between your agents and this server.