madeira.fun Hiking Permits

Build Booking Link

build_booking_link

Read-onlyIdempotent

Build the link a visitor opens to book a permit: https://madeira.fun/hiking/<seo_slug>?date=YYYY-MM-DD opens that date's start times on the trail page. Optional adults (visitors aged 13 or over who are not Madeira residents) and children (aged 12 or under, no fee) preset the party; lang sets the page language. The link books and stores nothing. On the page the visitor picks a start time and presses Reserve: madeira.fun submits the government reservation for them and emails a PayPay link to pay the government fee.

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>"
    },
    "name": "build_booking_link"
  }
}

Input Schema

Name	Required	Description
`date`	Yes	The hike date (YYYY-MM-DD, a Madeira calendar date).
`lang`	No	Page language.
`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 (they pay the government fee).
`children`	No	Visitors aged 12 or under who are not Madeira residents (no fee, still part of the reservation).

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 21, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, and the description adds real context beyond them: the string contains no state, the visitor supplies the start time on the page, and madeira.fun handles the government submission plus a PayPay payment email. That downstream chain is information an agent cannot infer from the annotations or schema.

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 literal URL template, then parameter meaning, then downstream behavior – a sensible order with no filler. The final sentence about Reserve/PayPay is useful but slightly long, and the adults/children parentheticals largely repeat the schema.

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 pure link-builder with no output schema, the description supplies the URL format, the meaning of each parameter's effect, and the full downstream booking flow. Nothing needed to call it correctly or explain the result to a user is missing.

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 baseline is 3; the description goes slightly further by showing how date (YYYY-MM-DD) and the preset party surface in the generated URL, and by re-stating the adults/children age-and-residency split with fee implications. Much of this duplicates the schema's own parameter descriptions, limiting the added value.

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?

Opens with a specific verb and artifact ('Build the link a visitor opens to book a permit') and immediately shows the concrete URL shape, so the agent knows exactly what it gets back. The closing contrast ('The link books and stores nothing') separates it cleanly from start_reservation/confirm_reservation in the sibling set.

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 description establishes a clear context – generate a link for a visitor to self-serve on the trail page, with the reservation happening later via makeira.fun. It does not explicitly name sibling alternatives (start_reservation, check_trail_availability) or state when not to use it, so it stops short of full routing 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?