public

Request a bespoke proposal

request_a_proposal

Submit a structured proposal request to Kratons on behalf of a traveller or a travel agent: contact, destinations within Spain/Portugal/Morocco, dates, travellers, total budget, interests. Returns a reference. A human advisor replies by e-mail — there is no automatic booking, no online checkout and no price list. Send idempotencyKey to retry safely.

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": {
      "contact": "<contact>",
      "trip": "<trip>"
    },
    "name": "request_a_proposal"
  }
}

Input Schema

Name	Required	Description
`utm`	No	UTM parameters of the landing link, when any
`trip`	Yes
`source`	No	Where this request originated, e.g. "social" when the traveller followed a link in one of Kratons' social posts
`contact`	Yes
`requester`	No
`socialPostId`	No	The Kratons social post the traveller came from, when the link carried it
`idempotencyKey`	No	Send the same key to retry safely; the same reference comes back

Output Schema

Name	Required	Description
`missing`	Yes	Recommended details this request did not carry — collect them before the advisor has to ask
`duplicate`	Yes	true when the same request was already received in the last 24 h (same reference returned)
`reference`	Yes	Quote it in any follow-up; get_proposal_request_status reads it
`receivedAt`	Yes	ISO timestamp
`acknowledged`	Yes	One sentence echoing what was received, to confirm it to the traveller
`whatHappensNext`	Yes
`contactForChanges`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedSep 24, 2026

addedInput schema / properties / socialPostId

Added value: +{
+  "description": "The Kratons social post the traveller came from, when the link carried it",
+  "pattern": "^[0-9a-fA-F]{24}$",
+  "type": "string"
+}

addedInput schema / properties / source

Added value: +{
+  "description": "Where this request originated, e.g. \"social\" when the traveller followed a link in one of Kratons' social posts",
+  "enum": [
+    "social",
+    "web",
+    "agent",
+    "referral",
+    "other"
+  ],
+  "type": "string"
+}

addedInput schema / properties / utm

Added value: +{
+  "additionalProperties": false,
+  "description": "UTM parameters of the landing link, when any",
+  "properties": {
+    "campaign": {
+      "maxLength": 100,
+      "type": "string"
+    },
+    "medium": {
+      "maxLength": 100,
+      "type": "string"
+    },
+    "source": {
+      "maxLength": 100,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

Changed4 schema fields changedSep 17, 2026

addedInput schema / properties / trip / properties / hotelPreferences

Added value: +{
+  "additionalProperties": false,
+  "description": "Accommodation preferences by level or by hotel name (2026-09-17)",
+  "properties": {
+    "level": {
+      "description": "Hotel level the traveller expects; 'mixed' when it may vary by city",
+      "enum": [
+        "3_star",
+        "4_star",
+        "5_star",
+        "luxury",
+        "boutique",
+        "historic_or_parador",
+        "mixed"
+      ],
+      "type": "string"
+    },
+    "names": {
+      "description": "Specific hotels the traveller has in mind, by name",
+      "items": {
+        "maxLength": 120,
+        "minLength": 1,
+        "type": "string"
+      },
+      "maxItems": 10,
+      "type": "array"
+    },
+    "notes": {
+      "description": "Anything else about accommodation (room types, location, must-haves)",
+      "maxLength": 500,
+      "type": "string"
+    }
+  },
+  "type": "object"
+}

addedOutput schema / properties / acknowledged

Added value: +{
+  "description": "One sentence echoing what was received, to confirm it to the traveller",
+  "type": "string"
+}

addedOutput schema / properties / missing

Added value: +{
+  "description": "Recommended details this request did not carry — collect them before the advisor has to ask",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

changedOutput schema / required

Previous value: -[
-  "reference",
-  "duplicate",
-  "receivedAt",
-  "whatHappensNext",
-  "contactForChanges"
-]New value: +[
+  "reference",
+  "duplicate",
+  "receivedAt",
+  "whatHappensNext",
+  "contactForChanges",
+  "missing",
+  "acknowledged"
+]

Changed1 schema field changedSep 17, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "contactForChanges": {
+      "type": "string"
+    },
+    "duplicate": {
+      "description": "true when the same request was already received in the last 24 h (same reference returned)",
+      "type": "boolean"
+    },
+    "receivedAt": {
+      "description": "ISO timestamp",
+      "type": "string"
+    },
+    "reference": {
+      "description": "Quote it in any follow-up; get_proposal_request_status reads it",
+      "type": "string"
+    },
+    "whatHappensNext": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "reference",
+    "duplicate",
+    "receivedAt",
+    "whatHappensNext",
+    "contactForChanges"
+  ],
+  "type": "object"
+}

Changed1 schema field changedSep 16, 2026
- removedInput schema / properties / website
```
Removed value: -{
-  "maxLength": 500,
-  "type": "string"
-}
```
First observedSep 16, 2026

TDQS

A4/5.0

Behavior4/5

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

The description adds meaningful behavioral context beyond the annotations: the advisor replies by e-mail, there is no automatic booking, no online checkout, no price list, and idempotencyKey enables safe retries. This clarifies the asynchronous, human-mediated nature of the operation. There is no contradiction with the annotations, since readOnlyHint=false is consistent with submitting a request.

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?

The description is three sentences with no filler: it front-loads the action and key fields, then explains the behavioral consequences, and ends with retry guidance. Every sentence earns its place.

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 a tool with nested objects and many optional fields, the description conveys the essential workflow: submit a request, receive a reference, get a human e-mail reply, and retry safely with idempotencyKey. The parameter schema and output schema carry the remaining field-level detail, so nothing critical for selecting or invoking the tool is missing.

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?

The description highlights the most important request fields (contact, destinations, dates, travellers, total budget, interests) and explains idempotencyKey's retry semantics, adding value over the raw schema. However, schema coverage is only 57%, and the description does not compensate for all undocumented optional parameters such as utm, source, socialPostId, and requester.

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?

The description opens with a specific action ('Submit a structured proposal request') and names both the resource (Kratons) and the beneficiary ('a traveller or a travel agent'). It also lists the core content of the request and the return value ('Returns a reference'), clearly distinguishing this submission tool from siblings like get_proposal_request_status.

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 description conveys when to use the tool by framing it as the way to request a bespoke proposal and sets expectations that a human replies by email. However, it never names sibling tools or states when an alternative should be used instead, such as get_proposal_request_status for checking an existing request, so the routing guidance remains implicit.

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

All public 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?