Skip to main content
Glama
Sign In

Gingerguide: European city walking tours

by app.gingerguide
OverviewDiscussionsAdmin

Plan walking tour

plan_walking_tour
Read-onlyIdempotent

Build an ordered self-guided walking route in one city that fits a time budget, e.g. "a two-hour historical walk in Rome". Picks sights by interests, periods and style, orders them to keep walking short, and returns each stop with walking minutes, suggested time on site, clock times and a Google Maps walking link.

Input Schema

NameRequiredDescriptionDefault
paceNoWalking pace: relaxed (3.5 km/h), normal (4.5 km/h) or brisk (5.5 km/h).normal
styleNomust_see favours each city's headline sights, hidden_gems favours lesser-known ones, balanced mixes both.balanced
city_idYesGingerguide city id, e.g. "rome" or "istanbul" (from search_cities).
periodsNoHistorical periods to favour, e.g. ["byzantine"] or ["roman","renaissance"].
settingNoany
weekdayNoDay of the week of the visit. Sights known to be closed that day are left out (closing days are researched for some cities only).
languageNoLanguage of names and descriptions: en, es, fr, de, tr or zh.en
interestsNoTraveler interests to favour, e.g. ["history","architecture"].
start_latNo
start_lngNo
start_timeNoLocal start time, HH:MM.
exclude_idsNo
must_includeNoSight ids that must be on the route.
duration_minutesNo
start_attraction_idNoStart at this sight instead of a coordinate.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • addedInput schema / properties / weekday
      Added value: +{
+  "description": "Day of the week of the visit. Sights known to be closed that day are left out (closing days are researched for some cities only).",
+  "enum": [
+    "mon",
+    "tue",
+    "wed",
+    "thu",
+    "fri",
+    "sat",
+    "sun"
+  ],
+  "type": "string"
+}
  4. Added

TDQS

A4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/closed-world, so the bar is low, and the description still adds real behavior: sight selection logic, ordering to minimize walking, and per-stop output (walking minutes, time on site, clock times, Maps link). It omits the caveat found only in the schema that closing-day filtering is researched for some cities only, which is a meaningful reliability qualifier an agent should know.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences, front-loaded with the core capability and example, then a tightly packed behavior/output sentence. No filler or restatement of the title.

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?

No output schema exists, and the description compensates by enumerating what each stop returns, which is the main missing piece. For a 15-parameter tool it still leaves the start-point alternatives and the optional-array parameters unaddressed, so it is strong but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

At 67% schema coverage the schema carries most weight; the description adds meaning for the driving inputs (interests, periods, style, time budget) but says nothing about start_lat/start_lng vs start_attraction_id vs start_time precedence, must_include/exclude_ids, or pace/setting/language.

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?

Specific verb ('Build an ordered self-guided walking route') plus resource and scope ('in one city that fits a time budget'), with a concrete example. The 'one city / on-foot' framing implicitly separates it from plan_trip_itinerary and recommend_attractions without needing to name them.

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

Usage Guidelines3/5

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

The example ('a two-hour historical walk in Rome') implies when this tool is the right pick, but there is no explicit when-not guidance and no named alternative (e.g. plan_trip_itinerary for multi-city/multi-day, recommend_attractions for unsequenced lists). Usage is inferable rather than stated.

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

All Gingerguide: European city walking tours toolsInspect
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