RandoForge

Overview Schema Source Related Servers Discussions Admin

find_bivouac_spots

Find bivouac and shelter spots along a hiking route, including refuges, cabins, flat pitches, water access, and detour warnings.

Instructions

Emplacements pour dormir le long du tracé : refuges, cabanes et gîtes (refuges.info, OSM), aires de bivouac, et emplacements calculés (terrain plat < 8 %, eau à moins de 500 m si possible, loin des routes, hors pierriers et zones où le bivouac est interdit).

    Chaque emplacement indique sa source, le détour, la distance à l'eau et les avertissements
    réglementaires. Les emplacements calculés sont des pistes à vérifier sur place.
    `abrite_seulement` : uniquement refuges, cabanes, abris, grottes et abris sous roche
    (bivouac à l'abri de la pluie et du vent).

Input Schema

TableJSON Schema

Name	Required	Description	Default
`route_id`	Yes
`abrite_seulement`	No

Output Schema

TableJSON Schema

Name	Required	Description	Default
`rappels`	Yes
`route_id`	Yes
`emplacements`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.3.0Oct 15, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the data sources (refuges.info, OSM), the per-spot metadata (source, detour, distance to water, regulatory warnings), and — importantly — that computed spots are heuristic (flat terrain <8%, water <500 m, away from roads/scree/forbidden zones) and are 'pistes à vérifier sur place'. It does not state read-only status or any auth/rate concerns, but reliability disclosure is the key trait here.

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

Conciseness4/5

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

Front-loaded with the resource and scope, then per-item output, then the filter parameter. The parenthetical criteria list is detailed but each element earns its place by defining what a 'computed' spot is. Slightly dense but not padded.

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 return values need not be explained, yet the description still summarizes what each spot carries. Combined with the heuristic caveat and the filter parameter, an agent has enough to invoke it correctly; the only gap is the absence of any routing to a sibling alternative.

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

Parameters4/5

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

Schema coverage is 0%, so the description must compensate. It fully explains the non-obvious parameter `abrite_seulement` (restrict to shelters, cabins, huts, caves and rock overhangs for rain/wind protection). route_id is left unexplained, but it is self-evident from context and sibling tools.

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

Purpose4/5

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

The description names a specific verb+resource — finding sleeping spots (refuges, cabanes, gîtes, aires de bivouac, and computed spots) along a route — and enumerates the categories returned. It is clearly distinguishable from generic siblings like find_pois by content, but it never explicitly contrasts itself with them.

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

Usage Guidelines3/5

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

Usage is only implied: the route_id input and the wording 'le long du tracé' signal that this is run against an existing route. There is no statement of when to prefer this over find_pois or when it is not appropriate, and no prerequisite (e.g. route must exist) is stated.

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