madeira.fun Hiking Permits

Start a Permit Reservation

start_reservation

Step 1 of 2 to reserve a Madeira hiking permit for a visitor through madeira.fun. Before calling, tell the visitor these three points in your own words and get their yes: (1) madeira.fun creates a madeira.fun account with the visitor's email address (or signs in the one they already have). (2) madeira.fun sends that email address and the party size to the Madeira government's Simplifica system (IFCN), which issues the permit. The name stays with madeira.fun. (3) Reserving is not paying: the government's PayPay payment link arrives by email, and the visitor must pay the permit fee to the government within 24 hours, or before the start time if that is sooner, or the reservation lapses. madeira.fun charges nothing and never collects the permit fee. This step checks the start time and emails the visitor a 6-digit code from madeira.fun; nothing is reserved yet. Then ask the visitor for the code and call confirm_reservation. Standard visitor reservations only (no Madeira residents, no Verified Permit): for those use build_booking_link. Today up to 119 days ahead. At most 3 codes per email per hour. For apps calling from a server: a call from a web page is refused.

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": {
      "trail": "<trail>",
      "date": "<date>",
      "start_time": "<start_time>",
      "name": "<name>",
      "email": "<email>",
      "visitor_agreed": "<visitor_agreed>"
    },
    "name": "start_reservation"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	The hike date (YYYY-MM-DD, a Madeira calendar date).
`lang`	No	Language of madeira.fun's emails (default en).
`name`	Yes	The visitor's name, for their madeira.fun reservation (madeira.fun keeps it; the government gets the email and the party size).
`email`	Yes	The visitor's email: madeira.fun sends the code there, creates or signs in their madeira.fun account with it, and the government's payment link and permit go there. Not an Apple Hide My Email address.
`trail`	Yes	The trail: its seo_slug from list_permit_trails (preferred), a code such as "PR 18", "PR18" or "PS PR1", or a name such as "Levada do Rei". Accents are ignored.
`adults`	No	Visitors aged 13 or over who are not Madeira residents (each pays the government fee).
`children`	No	Visitors aged 12 or under who are not Madeira residents (no fee, still part of the reservation).
`start_time`	Yes	The begin of an open start time from get_start_times, HH:MM (Madeira time).
`visitor_agreed`	Yes	true only after the visitor heard the three points in this tool's description and said yes. The emailed code is what confirms it.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only mark this as a non-read-only, non-idempotent open-world call; the description goes far beyond by disclosing side effects: an account is created with the visitor's email, the email and party size are sent to Simplifica/IFCN, a 6-digit code is emailed, and nothing is reserved at this step. It also covers rate limits, the 24-hour payment lapse rule, the no-fee posture, and the matching/referral constrains for browser callers.

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 sequence, the three consent points, and the constraints are front-loaded and dense with policy that the agent must actually relay. Some sentences are long (the three numbered points, the eligibility/rate-limit tail), but each carries distinct contractual information rather than filler.

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?

For a 9-parameter, no-output-schema mutation step, the description covers the consent prerequisite, side effects, timing window, rate limit, and next step thoroughly. The one gap is the return payload: it says a code is emailed but not what the tool returns (for example, a handle or state needed by confirm_reservation), leaving the handoff slightly implicit.

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%, so the baseline is 3, but the description adds real meaning: 'madeira.fun sends that email address and the party size to the government' clarifies what adults/children feed into and what stays with madeira.fun (the name). It also frames visitor_agreed as the consent flag tied to the three disclosed points, which the schema alone only gestures at.

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 — 'Step 1 of 2 to reserve a Madeira hiking permit' — and immediately scopes it to standard visitor reservations. It names the siblings that handle the other cases (confirm_reservation for step 2, build_booking_link for residents and Verified Permit), so an agent can route without opening any schema.

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

Usage Guidelines5/5

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

Explicit when-to-use and when-not: standard visitor reservations only, with build_booking_link named for residents and Verified Permit holders. It also gives operating bounds (today up to 119 days ahead, max 3 codes per email per hour, server-side calls only because browser calls are refused) and the prerequisite consent gate.

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?