Skip to main content
Glama

Garden Route Specialist

by io.github.tyronplaatjies74-wq
OverviewDiscussionsAdmin

generate_itinerary

Build a day-by-day Garden Route itinerary (west to east, no repeated activities) with per-day costs, a budget check, dietary verification, safety notes and transport estimates. Activities within a day are kept walkable or a short costed hop apart. If a town has nothing left or open (e.g. rain), the day becomes a trip to the nearest hub. Picks, prices and whale season depend on the month, so ask the traveller for their travel month first (if omitted, the current month is assumed and flagged). Costs are in South African rand; times and fares are estimates.

Input Schema

NameRequiredDescriptionDefault
daysYesTrip length in days, 1-30.
seedNoOptional. Repeat a shuffled result.
debugNoInclude debug info.
monthNoMonth of travel, e.g. 'July' or 7. Ask the traveller; do not guess. If omitted, the current month is assumed and flagged in warnings. Changes activity picks, hostel prices and whale-watching.
townsYesTowns to visit. Valid: mossel bay, george, wilderness, knysna, plettenberg bay, tsitsikamma.
dietaryNovegan, vegetarian or halal. Evening meals are marked verified or NOT verified.
shuffleNoVary the picks between calls.
budget_maxNoMaximum spend per day in rand, all-in (dorm + food allowance + activities), excluding inter-town transport.
rainy_daysNoOptional. Day numbers (1-based) the traveller wants rain-proofed with indoor/covered options or a hub trip, e.g. [2, 3].
family_modeNoPrefer family-friendly activities and private/family rooms.
travel_styleNoOne of: backpacker, adventure, chill, family, foodie. Default: backpacker.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / month / description
      Previous value: -"Month of travel, e.g. 'July' or 7. Ask the traveller if unknown; do not guess. Changes activity picks, hostel prices and whale-watching."New value: +"Month of travel, e.g. 'July' or 7. Ask the traveller; do not guess. If omitted, the current month is assumed and flagged in warnings. Changes activity picks, hostel prices and whale-watching."
    • changedInput schema / required
      Previous value: -[
-  "towns",
-  "days",
-  "month"
-]New value: +[
+  "towns",
+  "days"
+]
  2. Changed4 schema fields changed
    • changedInput schema / properties / budget_max / description
      Previous value: -"Maximum spend per day in rand, all-in (dorm + food allowance + activities), excluding transport."New value: +"Maximum spend per day in rand, all-in (dorm + food allowance + activities), excluding inter-town transport."
    • addedInput schema / properties / month
      Added value: +{
+  "description": "Month of travel, e.g. 'July' or 7. Ask the traveller if unknown; do not guess. Changes activity picks, hostel prices and whale-watching.",
+  "type": "string"
+}
    • addedInput schema / properties / rainy_days
      Added value: +{
+  "description": "Optional. Day numbers (1-based) the traveller wants rain-proofed with indoor/covered options or a hub trip, e.g. [2, 3].",
+  "items": {
+    "type": "integer"
+  },
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "towns",
-  "days"
-]New value: +[
+  "towns",
+  "days",
+  "month"
+]
  3. First observed

TDQS

A4.3/5.0
Behavior4/5

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

With no annotations, the description carries the full disclosure burden and does well: it states ordering constraints (west to east), no-repeat activities, walkable clustering, rainy-day hub fallback, month-dependent picks/prices/whale season, ZAR currency, and that times and fares are estimates. It omits whether the tool has side effects (e.g. that it books nothing) and any auth/rate-limit context, which keeps it from a 5.

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 core purpose, then rule/behavior details, then currency and estimation caveats. Four tight sentences with little waste, though the month instruction partially restates the schema's month description.

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 an 11-parameter generator with no output schema, the description conveys what the output contains (per-day plans, costs, budget check, dietary verification, safety notes, transport estimates) and how warnings work. It does not specify the output structure (e.g. JSON shape), but an agent has enough to call it and interpret results.

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 already 100%, so the baseline is 3; the description adds meaning beyond the schema by explaining cross-parameter behavior: month changes activity picks, hostel prices and whale watching; budget is all-in per day; rainy days trigger hub trips; dietary drives verified/NOT verified marking. A few statements (month handling, budget definition) duplicate schema text, so it is not a full 5.

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?

Starts with a specific verb and resource ('Build a day-by-day Garden Route itinerary') and immediately names the defining constraints: west-to-east, no repeated activities, with per-day costs, budget check, dietary verification, safety notes and transport estimates. This is unmistakably different from the sibling tools get_knowledge and get_stats, which are read-only data lookups.

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 explicit operational guidance: ask the traveller for their travel month first and note that the current month is assumed and flagged if omitted. It also describes the fallback when a town has nothing open (rain → nearest hub trip). It does not provide when-not-to-use guidance, but the sibling tools are unrelated enough that explicit alternatives are not necessary.

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

All Garden Route Specialist 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