tickadoo-mcp

render_experience_cards

Read-onlyIdempotent

Use when visual cards would help present a discovery result from a supported search tool. Pass the product_id values from that result as experience_ids, never full product rows, and choose a render_type. Optionally pass render_context.intent_summary (a short phrase describing what the user asked for, such as city, date, or audience) to set the heading. Keep each result set to one card view to avoid duplicate cards; concise text context may accompany it.

Input Schema

TableJSON Schema

Name	Required	Description
`render_type`	Yes	Visual layout requested for the widget.
`experience_ids`	Yes	The stable product_id values from search_experiences results (the product_id field of each returned row). Pass IDs only, never full product rows.
`render_context`	No
`idempotency_key`	No	Optional UUID. Reuse for identical card render responses within five minutes.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedSep 3, 2026

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / oneOf

Added value: +[
+  {
+    "additionalProperties": true,
+    "properties": {
+      "experience_ids": {
+        "description": "The stable product ids rendered as cards.",
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      }
+    },
+    "required": [
+      "experience_ids"
+    ],
+    "type": "object"
+  },
+  {
+    "additionalProperties": true,
+    "properties": {
+      "detail": {
+        "additionalProperties": true,
+        "type": "object"
+      },
+      "error_type": {
+        "enum": [
+          "ambiguous_input",
+          "invalid_input",
+          "rate_limited",
+          "supplier_unavailable",
+          "circuit_breaker_open",
+          "partial_result",
+          "unauthorized",
+          "forbidden",
+          "internal_error",
+          "not_found"
+        ],
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "retry_after": {
+        "type": "string"
+      },
+      "retry_after_seconds": {
+        "minimum": 0,
+        "type": "integer"
+      },
+      "schema_version": {
+        "const": "https://mcp.tickadoo.com/schemas/tool_error/1.0"
+      }
+    },
+    "required": [
+      "schema_version",
+      "error_type",
+      "message",
+      "detail"
+    ],
+    "type": "object"
+  }
+]

removedOutput schema / properties

Removed value: -{
-  "experience_ids": {
-    "description": "The stable product ids rendered as cards.",
-    "items": {
-      "type": "string"
-    },
-    "type": "array"
-  }
-}

removedOutput schema / required

Removed value: -[
-  "experience_ids"
-]

Changed1 schema field changedJul 10, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "properties": {
+    "experience_ids": {
+      "description": "The stable product ids rendered as cards.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "experience_ids"
+  ],
+  "type": "object"
+}

Changed1 schema field changedMay 31, 2026

changedInput schema / required

Previous value: -[
-  "experience_ids",
-  "render_type",
-  "render_context"
-]New value: +[
+  "experience_ids",
+  "render_type"
+]

Changed1 schema field changedMay 27, 2026

changedInput schema / properties / experience_ids / description

Previous value: -"Stable product IDs from search_experiences. Pass IDs only, never full product rows."New value: +"The stable product_id values from search_experiences results (the product_id field of each returned row). Pass IDs only, never full product rows."

AddedApr 26, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly, non-destructive and idempotent behavior, so the bar is lower. The description adds real behavioral guidance beyond them: pass ID values not full rows, and avoid duplicate cards by limiting to one card view per result set.

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 trigger condition, followed by the key input rule and the anti-duplication constraint. Four sentences carry mostly distinct information, though the parenthetical example list ('city, date, or audience') is slightly padded.

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?

With an output schema present, return values need not be explained, and the description covers purpose, trigger, required inputs, and the duplicate-card pitfall. For a 4-parameter, nested, read-only render tool this is nearly complete; only the linkage to the specific source search tool is imprecise.

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?

Schema description coverage is 75%, so the schema already documents the meaning of experience_ids, render_type, and the nested render_context fields. The description largely restates the schema ('product_id values ... never full product rows', intent_summary sets the heading) rather than adding syntax or constraints the schema omits, so the baseline 3 applies.

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?

The description states a clear verb+resource: render visual cards presenting a discovery result. It distinguishes itself from the surrounding search/detail siblings by framing it as a presentation step rather than a retrieval step, though 'a supported search tool' is left slightly vague rather than naming which sibling output feeds it.

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 trigger ('Use when visual cards would help present a discovery result') and adds a usage constraint ('Keep each result set to one card view to avoid duplicate cards'). It does not enumerate alternatives or state when NOT to render cards, so it stops short of the top band.

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

All tickadoo-mcp 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.