Kratons, boutique DMC: bespoke private trips in Spain, Portugal, Morocco. Facts, catalog, requests.
Scored across 7 tools
Most tools are clearly distinct: get_company_facts, list_destinations, list_sample_itineraries, search_experiences, request_a_proposal, and get_proposal_request_status each target a different resource or action. The only minor overlap is between get_company_facts and how_to_request_a_proposal, both of which describe pricing policy and proposal process, though one is general company info and the other is a procedural checklist.
Tool names mostly follow a consistent verb_noun pattern: get_company_facts, list_destinations, list_sample_itineraries, search_experiences, request_a_proposal, get_proposal_request_status. how_to_request_a_proposal deviates slightly from the pattern (it's a how-to guide rather than an action), but the naming is otherwise predictable and readable.
Seven tools is well-scoped for a travel company's public-facing MCP server. Each tool covers a distinct need: company info, destination discovery, itinerary browsing, experience search, proposal submission, and status polling. No tool feels redundant or excessive.
The server covers the full public journey: learn about the company, browse destinations and itineraries, search experiences, request a proposal, and check proposal status. A minor gap is the lack of a way to cancel or modify a proposal request, but the read-only and request-focused scope is clearly intentional and well covered.
Who Kratons is: legal identity, address, contact channels, countries served, languages, services, pricing policy and how to request a proposal. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true and openWorldHint=false, and the description repeats 'Read-only' without adding new behavioral context such as output format, pagination, or auth requirements. The list of included content is informative but not behavioral.
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 sentence that front-loads the purpose ('Who Kratons is') and lists all covered topics efficiently without any redundant or tangential content.
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 parameters and no output schema, the description fully specifies what the tool returns. The scope is exhaustive for a company-facts tool, and nothing an agent needs to invoke it correctly is missing.
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?
The tool has zero parameters, so schema description coverage is 100%. No additional parameter documentation is needed, and the description adds nothing beyond the schema, which is appropriate.
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 purpose: providing company facts such as legal identity, address, contact channels, countries served, languages, services, pricing, and proposal request info. This clearly distinguishes it from sibling tools that deal with proposals, destinations, and itineraries.
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 description makes it clear when to use this tool (when company information is needed) and the sibling names indicate different functions (e.g., request_a_proposal, list_destinations). It does not explicitly state when not to use it, but the context is unambiguous.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Where a submitted proposal request stands (received, being prepared, proposal sent, confirmed, closed) by its reference. Returns no personal data. Poll this instead of e-mailing.
| Name | Required | Description | Default |
|---|---|---|---|
| reference | Yes | The reference returned by request_a_proposal, e.g. PR-20260916-U8GB |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, and the description adds a useful privacy guarantee ('Returns no personal data') plus a closed status enumeration. This goes beyond what the annotations convey and gives agents important context about safe repeated polling. There is no contradiction with the annotations.
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?
The description is two short sentences, front-loaded with the core status-lookup behavior, followed by two useful caveats: no personal data and polling instead of emailing. There is no filler or redundancy.
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 one-parameter read-only lookup with no output schema, the description is largely sufficient: it gives the status vocabulary, identifies the identifying reference, and notes privacy. It does not describe the exact response shape, but with no output schema and such a simple semantic, that 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 100%, so the baseline applies. The schema already documents the reference format, pattern, example, and source. The description only restates that lookup is 'by its reference', adding no new parameter semantics.
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 exactly what the tool does: returns the current status of a submitted proposal request by reference, and enumerates the possible statuses. This is a specific verb+resource and is clearly distinct from sibling tools such as request_a_proposal.
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 phrase 'Poll this instead of e-mailing' provides clear context for using the tool and an explicit behavioral alternative. It also implies usage after a proposal request has been submitted via the reference. However, it does not name sibling tools or state explicit when-not-to-use conditions, so it falls just short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
The checklist a traveller or agent should send to Kratons to receive a bespoke proposal, the pricing policy, and how a human advisor follows up. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the read-only nature is covered. The description adds valuable behavioral context: it explains that this is a checklist for sending to Kratons, mentions pricing policy, and human advisor follow-up. This goes beyond the annotation by detailing the tool's role in the workflow. No contradiction.
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?
The description is a single clear sentence that front-loads the purpose ('The checklist...'), followed by key details (pricing policy, follow-up). It is concise with no fluff, earning a high score.
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?
Given there are no parameters and no output schema, the description provides enough context for an agent to understand what this tool does: it returns a checklist. It doesn't detail the exact content of the checklist, which could be useful, but for a parameterless read-only tool, the description is nearly complete.
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?
The input schema has zero parameters, and schema description coverage is 100% (vacuously). The description doesn't need to document parameters. It adds meaning by explaining what the tool provides, which is sufficient for a parameterless informational tool.
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 clearly states the tool's purpose: providing the checklist for requesting a proposal, pricing policy, and advisor follow-up. It specifies the resource (the checklist) and the action (how to request), distinguishing it from siblings like request_a_proposal (which likely submits the request).
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 description clarifies that this is a read-only informational tool about the process, which implicitly distinguishes it from action tools like request_a_proposal. However, it doesn't explicitly state when to use this vs. get_proposal_request_status or list_sample_itineraries, but the context is fairly clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Countries and cities where Kratons currently offers tours or tickets, with counts. Read-only.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already provide readOnlyHint=true and openWorldHint=false TicketDetail. The description adds useful behavioral context by specifying that the returned data reflects destinations where Kratons 'currently offers' tours or tickets and that counts are included. This goes beyond the annotation coverage, though it does not describe output formatting or ordering, which is acceptable for a simple no-parameter list.
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?
The description is concise and front-loaded, using two short sentences. The only minor redundancy is 'Read-only.', which duplicates the readOnlyHint annotation, but this does not meaningfully hurt clarity or consume excessive tokens.
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?
Given the tool has no parameters, no output schema, and read-only annotations, the description is complete enough for an agent to understand exactly what it will get: destination names with counts. No prerequisites, side effects, or alternatives are strictly necessary for this simple list operation.
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?
The tool has zero parametersached, which warrants the baseline score of 4. The description does not need to explain input semantics because there are no inputs; the schema is an empty object and the description appropriately focuses on the output rather than parameters.
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 clearly states what the tool returns: countries and cities where tours or tickets are offered, with counts, and that it is read-only. It does not explicitly start with a verb like 'List', but the tool name and title make this clearhol and the content distinguishes it from the experience/itinerary-focused siblings by focusing on destinations.
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 description implies the appropriate use case: when a caller wants the set of destinations with counts of available tours or tickets. However, it does not explicitly mention when not to use it or point to alternatives such as search_experiences or list_sample_itineraries, leaving some routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Published sample itineraries Kratons operates (name, destination, duration, category, summary, day-by-day outline) to start a conversation from. Never prices or suppliers — every trip is quoted as one package price by a human advisor.
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free text on name, summary and tags | |
| limit | No | Max results (default 20, max 50) | |
| country | No | Destination filter, e.g. Portugal, Andalusia |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, so the safety profile is covered. The description adds valuable behavioral context beyond annotations: it explicitly states that results never include prices or suppliers and that trips are quoted as one package price by a human advisor. This prevents the agent from misusing sample data as a pricing source.
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 compact sentences cover the resource, its fields, its purpose, and the critical no-pricing caveat. Every sentence earns its place and the most important constraint is front-loaded before the pricing clarification.
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 read-only list operation with three optional, fully documented parameters and no output schema, the description is complete. It names the returned fields, states the purpose, and discloses the key limitation about prices/suppliers, so an agent has enough context to invoke it correctly.
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 100%, so the parameters q, limit, and country are already fully documented. The description's field list (name, destination, duration, etc.) describes result content rather than adding meaning to the parameters, so the baseline 3 is appropriate.
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_sample_itineraries' lists published sample itineraries, with fields detailed in parentheses. It also gives the conversational purpose ('to start a conversation from'), which clearly differentiates it from siblings like list_destinations or search_experiences.
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 description gives clear context: use this tool to start a conversation with sample itineraries rather than pricing or supplier details. It does not explicitly compare alternatives among siblings, but the 'to start a conversation from' framing makes the intended use evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
| Name | Required | Description | Default |
|---|---|---|---|
| trip | Yes | ||
| contact | Yes | ||
| website | No | ||
| requester | No | ||
| idempotencyKey | No | Send the same key to retry safely; the same reference comes back |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description reveals the key behavioral trait that this is an asynchronous human-mediated process: 'A human advisor replies by e-mail', and it returns only a reference rather than a booking or a price. It also explains retry semantics via idempotencyKey, going beyond the sparse annotations. It does not mention failure modes or expected response time, but the most important behavior is disclosed.
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?
The description is three tight sentences with no filler. The first sentence front-loads the action, scope, and payload; the second explains the human-asynchronous nature; the third gives a key reliability instruction. Every sentence earns its place.
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?
The tool is complex: nested objects, many optional fields, no output schema, and sparse annotations. The description covers the high-level return ('a reference') and the human-reply model, but it does not mention how to follow up on a submitted request, expected timing, or how to handle partial optional data. It is adequate but leaves notable gaps for an agent operating without further guidance.
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?
With schema description coverage at only 20%, the description partially compensates by summarizing the main payload elements and, importantly, restricting destinations to Spain/Portugal/Morocco, which is not explicit in the schema. However, it does not clarify nested required structures, currency/language options, or optional fields like requester and website, so the agent still needs to inspect the schema carefully for full invocation correctness.
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 uses a specific action verb ('Submit') and names the resource ('a structured proposal request to Kratons'), plus the beneficiary ('on behalf of a traveller or a travel agent'). It describes what the tool returns ('a reference') and lists the core payload, making it clearly distinct from sibling status/list/search tools.
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 description clearly conveys when to use the tool: when a human advisor should craft a bespoke proposal. It also gives useful exclusions by stating there is no automatic booking, no online checkout, and no price list, and advises sending idempotencyKey for safe retries. However, it does not explicitly point to sibling alternatives such as get_proposal_request_status for follow-up.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tours and tickets Kratons operates, filtered by country, city and free text. Returns name, type, city, country, category, duration, free-cancellation flag and a summary — never prices or suppliers (Kratons quotes one package price per trip).
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | Free-text search on name, description and tags | |
| city | No | City name, e.g. Madrid, Lisbon, Marrakech | |
| limit | No | Max results (default 20, max 50) | |
| country | No | Country name, e.g. Spain, Portugal, Morocco |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare readOnlyHint=true and openWorldHint=false. The description goes beyond these by specifying the exact fields returned, explicitly stating that prices and suppliers are never included, and noting that Kratons quotes one package price per trip. This adds valuable behavioral context not present in annotations, such as the output composition and the business rule about pricing.
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?
The description is two sentences with no redundant words. It front-loads the core purpose and immediately lists the output fields and exclusions. Every sentence contributes useful information, and the structure is clean and scannable.
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?
The tool has no output schema, but the description enumerates all returned fields (name, type, city, country, category, duration, free-cancellation flag, summary) and clarifies the absence of prices/suppliers. The limit parameter is already documented in the schema. Nothing an agent needs to call this correctly is missing, making it contextually complete.
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 100%, with each parameter already having a description. The tool description adds minimal new meaning beyond restating the filters (country, city, free text). Since the schema handles parameter documentation fully, a baseline score of 3 is appropriate; the description does not introduce new parameter semantics.
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 clearly states the tool searches tours and tickets operated by Kratons, with filters for country, city, and free text. It enumerates the exact fields returned, making the purpose unambiguous. While it does not explicitly contrast with sibling tools like list_destinations, the resource type and filter scope are distinct enough that an agent can easily differentiate.
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 description implies usage context (searching experiences by location/text) but does not explicitly state when to avoid it or mention alternatives. It is clear enough that an agent would know to use this for finding tours/tickets, though it lacks explicit exclusions like 'for destination lists use list_destinations'. The clear scope earns a 4, but not a 5 because no alternatives are named.
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_company_factsget_proposal_request_statushow_to_request_a_proposallist_destinationslist_sample_itinerariesrequest_a_proposalsearch_experiencesRead-only MCP for Sparkling Tracks European tours: packages, itineraries, pricing, contacts.
Plan, quote & book the Camino de Santiago: routes, stages, live hotels, one package price, FAQ.
datos.gob.es — Spanish open-data catalogue
Multilingual travel guides, gear picks and booking links for AI travel agents.
Add one secure layer between your agents and this server.
