madeira.fun Hiking Permits

Get Start Times

get_start_times

Read-onlyIdempotent

Give trail (required without a partner key). The start times of a trail with the permits left for visitors at each one (as the trail page shows them: a number from 6 up, "few" at 1 to 5, "full" at 0), and a book_url per open start time that opens Reserve on madeira.fun at that time. Today up to 119 days ahead: give trail and date, or from and to (up to 14 days per call). Further ahead, up to 365 days: one trail and one date per call. Start times that have already begun today are never listed. Rate limited; a partner key (Authorization: Bearer mfk_...) gives higher limits, longer ranges and every trail at once (omit trail).

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": "get_start_times"
  }
}

Input Schema

Name	Required	Description
`to`	No	Last day of a range (YYYY-MM-DD, a Madeira calendar date).
`date`	No	One day (YYYY-MM-DD, a Madeira calendar date).
`from`	No	First day of a range (YYYY-MM-DD, a Madeira calendar date).
`trail`	No	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. Required, except for a partner key asking for every trail.

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 21, 2026

TDQS

A4.2/5.0

Behavior5/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds substantial context on top: rate limiting, Bearer partner-key auth, past-start-time suppression for today, the 14-day vs 365-day window split, and what book_url actually points to. These are behavioral facts an agent cannot get from the schema.

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?

Information-dense with almost no filler, but the structure is poor: it opens with the fragment 'Give trail (required without a partner key).' and packs the permit-scale legend, windowing rules, and rate limits into run-on sentences. Front-loading the core action would make it far easier to parse.

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?

There is no output schema, so the description carries the return-value burden and does it: it decodes the permit counts (6+ numeric, 'few' for 1-5, 'full' for 0) and explains book_url. Combined with the temporal and rate-limit rules, an agent has everything needed to call it correctly.

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; the description goes further by explaining the interaction between parameters (trail is required unless a partner key omits it, ranges cap at 14 days, deep-future calls take exactly one trail and one date). It does not explain how date and from/to behave when supplied together, leaving a small ambiguity.

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?

States a specific verb+resource: returns a trail's start times along with remaining permits per start time and a book_url per open slot. The parenthetical scope note (required without a partner key) clarifies coverage. It does not explicitly contrast with sibling check_trail_availability, so an agent must infer that this is the per-start-time detail view rather than an aggregate availability check.

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?

Gives concrete operating rules: today to 119 days ahead via trail+date or from/to (max 14 days per call); beyond that up to 365 days with one trail and one date per call; partner keys unlock longer ranges and all trails. That is real when/how guidance, though no sibling alternative is named for the availability-checking case.

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?