morocco-travel

Build a day-by-day Morocco route

plan_trip

Read-onlyIdempotent

A free, anonymous, day-by-day itinerary. Check partial, omittedCities, requestedDays and actualDays before presenting it as complete. When partial, choices describe ways to recalculate. Use get_plan_options first for valid ids. The route is not saved; send the person to the questionnaire URL to keep or adjust it.

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": {
      "cities": "<cities>",
      "who": "<who>",
      "style": "<style>",
      "vibes": "<vibes>",
      "pace": "<pace>",
      "kosher": "<kosher>"
    },
    "name": "plan_trip"
  }
}

Input Schema

Name	Required	Description
`who`	Yes
`pace`	Yes	relaxed, balanced or packed.
`month`	No
`style`	Yes
`vibes`	Yes
`cities`	Yes	City ids from get_plan_options.
`kosher`	Yes	none, partial or keep.
`duration`	No	Whole days including the flight days, or null.
`cityPlans`	No	Optional selected-city preferences; a day trip may be impossible and yield a partial plan.
`arrivalDate`	No	YYYY-MM-DD; today or later in Israel time.
`shabbatCity`	No	Only when kosher is partial or keep.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 24, 2026
- changedInput schema / properties / arrivalDate / description
```
Previous value: -"YYYY-MM-DD."New value: +"YYYY-MM-DD; today or later in Israel time."
```

Changed1 schema field changedSep 24, 2026

addedInput schema / properties / cityPlans

Added value: +{
+  "additionalProperties": {
+    "additionalProperties": false,
+    "properties": {
+      "mode": {
+        "enum": [
+          "dayTrip",
+          "stay"
+        ],
+        "type": "string"
+      },
+      "nights": {
+        "enum": [
+          1,
+          2,
+          "3+"
+        ],
+        "type": [
+          "integer",
+          "string"
+        ]
+      }
+    },
+    "required": [
+      "mode"
+    ],
+    "type": "object"
+  },
+  "description": "Optional selected-city preferences; a day trip may be impossible and yield a partial plan.",
+  "type": "object"
+}

First observedSep 22, 2026

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already signal safe/idempotent, and the description adds non-obvious behavior: the plan is not saved, it is anonymous/free, and partial plans carry recalculation choices. This goes beyond the schema/annotations and sets accurate expectations about persistence and completeness.

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?

The description is composed of short, purposeful sentences that lead with the core result, then move to output checks, recalculation, prerequisites, and persistence. There is no filler; even 'free, anonymous' is useful expectation-setting for an agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an 11-parameter tool with nested cityPlans and no output schema, the description covers the biggest behavioral traps: partial results, valid ids, and no persistence. However, it leaves parameter semantics and the response shape largely to the schema or inference, so it is adequate but not fully complete for autonomous use.

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

Parameters2/5

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

The description references get_plan_options for valid IDs and talks about output fields such as partial, omittedCities, requestedDays, and actualDays, but it does not clarify the four undocumented parameters (who, style, vibes, month) or add meaning to the tracked parameters. With schema coverage around 64%, the description needed to carry some of that weight and mostly doesn't.

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?

Description opens with 'A free, anonymous, day-by-day itinerary' after a title that names the verb ('Build') and resource ('Morocco route'). It clearly communicates that the tool creates an itinerary, though it relies on the sibling name get_plan_options to distinguish planning from option lookup rather than stating that boundary explicitly.

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?

It gives an explicit prerequisite: 'Use get_plan_options first for valid ids,' and explicit handling rules: check partial/omittedCities/requestedDays/actualDays before presenting as complete, and when partial, choices describe ways to recalculate. It doesn't state exclusions versus sibling tools, but the context is clear.

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

All morocco-travel 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?