SiteCheck Shop & Social

Hiking trails from OpenStreetMap, not from AllTrails, which

social_alltrails

Read-only

Hiking trails from OpenStreetMap (via the free Waymarked Trails API), not from AllTrails, which blocks automated access: search by trail name or list routes around a point. Per trail: OSM ID, name, ref, network level, length in km, loop/linear, hardest OSM sac_scale difficulty, surfaces, operator, website, Wikidata, description and center point. No user ratings, reviews or photos (OSM has none). Coverage depends on OSM mapping. Related tools on this server, for a different need: social_carsandbids when you need Live Cars & Bids auctions from the site's public RSS feed; social_instagram when you need engagement snapshot of a public Instagram account. Price: $0.002 in USDC per successful call, paid with x402 (Base, Solana or Arc); failed calls are not charged.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "social_alltrails"
  }
}

Input Schema

Name	Required	Description
`lat`	No	Latitude of the center point
`lon`	No	Longitude of the center point
`limit`	No	Number of trails with full details, 1 to 10 (default 5)
`query`	No	Trail name to search (or use lat/lon)
`radiusKm`	No	Search radius around lat/lon, 1 to 25 km (default 10)

Output Schema

Name	Required	Description	Default
`count`	No
`query`	No
`source`	No
`trails`	No
`checkedAt`	No
`totalListed`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 23, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Goes well past the readOnlyHint/openWorldHint annotations by disclosing the data-coverage caveat ('depends on OSM mapping'), the explicit absence of ratings, reviews and photos, and the commercial terms — $0.002 USDC per successful call via x402 on Base/Solana/Arc with failed calls uncharged. For a paid, open-world read tool that is exactly the extra context an agent needs before invoking.

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

Conciseness3/5

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

The opening clause and field list are front-loaded and efficient, but the 'Related tools on this server' sentence about Cars & Bids auctions and Instagram engagement has no bearing on hiking trails and is pure noise. That off-topic paragraph costs roughly a third of the description's length for zero decision value.

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

Completeness4/5

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

An output schema exists, so the return-shape burden is lifted, and the description still covers source, coverage limits, cost and payment. The one omission is that zero parameters are required, yet the description never states that at least one of query or lat/lon must be supplied to get results.

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

Parameters3/5

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

Schema description coverage is 100%, so lat, lon, limit, query and radiusKm are already documented with types and ranges. The description only restates the two modes ('search by trail name or list routes around a point') without adding format, mutual-exclusivity, or defaulting nuance beyond the schema. Baseline 3 is appropriate.

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

Purpose5/5

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

States a specific verb and resource — hiking trails from OpenStreetMap via Waymarked Trails — and names the two operating modes (search by trail name, or list routes around a point). It also explicitly positions itself against AllTrails, which no sibling on this server duplicates, so an agent can identify it immediately.

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

Usage Guidelines4/5

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

The two usage modes are spelled out clearly, and the 'not from AllTrails, which blocks automated access' line tells the agent why this source exists. However, the 'Related tools' sentence points at social_carsandbids and social_instagram, which are not real alternatives for trail data, so the routing guidance is diluted rather than sharpened.

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

All SiteCheck Shop & Social tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?