madeira.fun Hiking Permits

Confirm a Permit Reservation

confirm_reservation

Destructive

Step 2 of 2: with the code the visitor got by email, madeira.fun signs them in, checks the start time live and submits the government reservation for exactly what start_reservation described. The answer gives order_id and status_token. The reservation is not paid: madeira.fun then emails the government's PayPay link, and the visitor must pay the permit fee to the government within 24 hours, or before the start time if that is sooner, or it lapses. Safe to retry: calling it again with the same reservation_token returns the same order and never books twice (also after a lost answer). At most 5 reservations per email per day through apps.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "reservation_token": "<reservation_token>",
      "code": "<code>"
    },
    "name": "confirm_reservation"
  }
}

Input Schema

Name	Required	Description	Default
`code`	Yes	The code from the madeira.fun email, digits only.
`reservation_token`	Yes	The reservation_token start_reservation returned, unchanged.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4/5.0

Behavior2/5

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

It discloses a great deal beyond annotations — the live start-time check, that the reservation is unpaid and lapses within 24 hours or before the start time, and a per-email daily cap of 5. However, it asserts 'calling it again with the same reservation_token returns the same order and never books twice', which directly conflicts with the declared idempotentHint=false and undermines trust in the retry guidance.

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?

The flow step is front-loaded and each sentence carries distinct information (prerequisite, side effect, payment deadline, retry, rate limit). It is dense but readable, with only mild redundancy between 'Step 2 of 2' and the restated start_reservation reference.

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

Completeness5/5

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

For a mutating, open-world step-2 call with no output schema, it still names the returned fields (order_id, status_token) and covers the post-call payment obligation and expiry rules. The only gap is the disputed idempotency claim, which is a correctness issue rather than missing coverage.

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 100% and already documents both fields, so the baseline is 3; the description adds real value by tying code to the madeira.fun email and reservation_token to the exact value start_reservation returned 'unchanged', clarifying provenance rather than just format.

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?

Names a specific verb and resource ('submits the government reservation') and explicitly positions itself as 'Step 2 of 2', which cleanly separates it from the step-1 sibling start_reservation that produced the reservation_token. An agent can immediately tell what this call does and where it sits in the flow.

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?

States the prerequisite chain clearly: it needs the emailed code and the reservation_token returned by start_reservation, and names that sibling directly. It does not spell out when NOT to call it (e.g. expired tokens or an already-paid reservation beyond the 24h note), so it stops short of full when/when-not guidance.

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

All madeira.fun Hiking Permits 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?