Read-only 1-3 day trip plans in Portugal and Europe by train, boat and on foot. Not an agency.
Scored across 3 tools
Each tool has a clearly distinct purpose: search_trips lists trips, get_trip fetches one full record, and how_to_request explains the outbound request mechanism. There is no overlap in action or resource, so an agent can select the right tool unambiguously.
All names use snake_case and are readable, but get_trip and search_trips follow verb_noun while how_to_request is a descriptive phrase rather than a parallel action name. The deviation is minor and does not impede understanding.
Three tools are well matched to a deliberately read-only, short-trip server: one for discovery, one for detail, and one for explaining how to request new plans. Each tool earns its place without bloat or missing essential operations.
The surface covers discovery, full trip retrieval, and the request pathway for new plans, which fits the read-only purpose. Minor gaps might include richer filtering or pagination details, but agents can work around them.
Full record of one trip by id: day by day, where to sleep, three places worth it, what to cut, sources with dates.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true and openWorldHint=false, so safety and repeatability are covered. The description adds real value by previewing the returned content (day-by-day plan, lodging, top three places, what to cut, dated sources), but says nothing about failure behavior for a bad id or about record size.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
A single front-loaded sentence with no filler; the content list is terse but informative. The clipped phrasing ('three places worth it, what to cut') reads slightly informal but remains clear.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description usefully substitutes for it by naming the record's contents, which is the main thing an agent needs here. Remaining gaps—id format and error behavior—are small for a one-parameter read tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 0% for the single 'id' parameter, so the description carries the disclosure burden; 'by id' confirms the parameter identifies one trip but does not state its format (numeric, slug, uuid) or where to obtain it. Minimal compensation for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb (retrieves) and resource (one trip) keyed by id, and the enumeration of contents makes it obvious this is the full-record fetch rather than a listing. It never names search_trips, so differentiation from that sibling is by implication only.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Usage is implied: call it with an id when you want the whole record. There is no explicit statement that ids come from search_trips, nor any guidance on what to do when the id is unknown or invalid.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
How a Bot can ask Está no Ir for a new 1-3 day plan, a second opinion or a plan B, by plain-text email. This tool sends nothing.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, and openWorldHint=false, so the safety profile is covered. The description contributes a meaningful clarification that 'This tool sends nothing', preventing an agent from believing it dispatches email, but it says nothing about what the response contains or how the guidance should be acted on.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with the capability stated first and the non-action caveat immediately after, which is the right front-loading. Minor loss for the slightly run-on first sentence that folds three request types into one clause.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter, read-only helper with no output schema, the description covers the trigger scenarios and rules out side effects. It still leaves open what the agent actually receives (instructions text? a template?) and what details the email needs, which is the sole thing this tool exists to convey.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so there is nothing for the description to disambiguate; the baseline for a no-parameter tool applies. No misleading parameter hints are introduced.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific outcome: the tool explains how a Bot can request a new 1-3 day plan, a second opinion, or a plan B via plain-text email. The closing sentence 'This tool sends nothing' disambiguates it from an actual send action, and the resource (plan-request instructions) is clearly distinct from the trip-retrieval siblings. It falls short of 5 only because it never explicitly says the tool itself returns instructional text.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The scenarios that motivate a call are named (new 1-3 day plan, second opinion, plan B), which implies when to reach for it. However, there is no explicit statement of when to use this versus get_trip or search_trips, nor any when-not guidance, so tool selection still requires inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Está no Ir trips (1-3 days), optionally filtered. Returns id, type, title, origin, days, transport and URL.
| Name | Required | Description | Default |
|---|---|---|---|
| no_car | No | true = only plans that work without a car | |
| country | No | ISO 3166-1 alpha-2, e.g. PT, ES | |
| max_days | No | ||
| no_flight | No | true = only plans without a flight | |
| origin_contains | No | Text to match in the origin, e.g. Porto, Lisbon |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and openWorldHint=false, so the safety and closed-corpus profile is covered. The description adds value by listing the returned fields, which matters because there is no output schema, but it does not disclose result volume, ordering, or pagination behavior for an unfiltered query.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with zero filler; the scope constraint and the optional filtering are front-loaded, followed by the return fields.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All five parameters are optional and documented, and the description compensates for the missing output schema by listing returned fields. Only the unfiltered/unbounded result behavior and any limits are left unstated, which is a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 80%, so the schema already documents nearly every parameter with examples and semantics. The description only says results are 'optionally filtered' and adds no filter semantics beyond the schema, which is the appropriate baseline when the schema does the heavy lifting.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('List ... trips') plus a concrete scope (1-3 days, optionally filtered) and enumerates the return fields. It does not name or contrast with the siblings get_trip and how_to_request, but 'List' vs 'get' is reasonably self-differentiating.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Only 'optionally filtered' hints at when to use it. There is no statement about when to use search_trips versus get_trip for a single trip, and no mention of prerequisites or behavior when no filters are supplied (whether it returns everything).
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_triphow_to_requestsearch_tripsPlan journeys by train, bus, tram, metro and ferry across 42 European countries.
Plan trips on a map: routed transport, day-by-day itineraries, and a plan you can share.
Free city-walk planner: day-by-day self-guided walking itineraries for 50+ cities. No sign-up.
Read-only European city sights: search, nearby, walking routes and itineraries in 6 languages.
Add one secure layer between your agents and this server.
