CWI Discovery Engine

Request a Song

request_song

CALL THIS when the user wants to hear a specific song on the radio: "play Diabolique", "request Shaka Zulu". Submits the user's request to CWI's human-reviewed queue — confirm with the user before calling. Does NOT auto-play. Returns queue position and estimated air time. Rate limit: 3 per requester name per 24h. Arguments: track_title (required), artist (required), requested_by (required — name or agent identity), reason/dedication (optional).

Input Schema

Name	Required	Description
`artist`	Yes	Artist name.
`reason`	No	Optional: why you want to hear this track.
`dedication`	No	Optional: who this request is dedicated to.
`track_title`	Yes	Title of the track you want to hear.
`requested_by`	Yes	Your name or agent identity (used for rate limiting).

Output Schema

Name	Required	Description
`ok`	Yes
`artist`	No
`review`	No
`status`	Yes
`_session`	No	Chain session: pass _session.session_token back in the next call to continue the chain.
`try_next`	No	Suggested follow-up calls, each a pre-compiled {tool, arguments, purpose} payload.
`request_id`	Yes
`track_title`	No
`requested_at`	No
`requested_by`	No
`queue_position`	No
`estimated_air_in_minutes`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 15, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "additionalProperties": true,
+  "description": "request_song response: queued request with ID, queue position, ETA. Human-reviewed; never auto-plays.",
+  "properties": {
+    "_session": {
+      "additionalProperties": false,
+      "description": "Chain session: pass _session.session_token back in the next call to continue the chain.",
+      "properties": {
+        "session_token": {
+          "description": "Hex session token; echo it as params._session.session_token to continue.",
+          "type": "string"
+        },
+        "step": {
+          "description": "Hop number in this chain (1 = chain start).",
+          "type": "integer"
+        }
+      },
+      "required": [
+        "session_token",
+        "step"
+      ],
+      "type": "object"
+    },
+    "artist": {
+      "type": "string"
+    },
+    "estimated_air_in_minutes": {
+      "type": "integer"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "queue_position": {
+      "type": "integer"
+    },
+    "request_id": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "requested_at": {
+      "type": "string"
+    },
+    "requested_by": {
+      "type": "string"
+    },
+    "review": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "track_title": {
+      "type": "string"
+    },
+    "try_next": {
+      "description": "Suggested follow-up calls, each a pre-compiled {tool, arguments, purpose} payload.",
+      "items": {
+        "additionalProperties": false,
+        "description": "Pre-compiled next call: copy `arguments` straight into the next tools/call.",
+        "properties": {
+          "arguments": {
+            "additionalProperties": true,
+            "description": "Ready-to-use arguments, pre-populated from the current response.",
+            "type": "object"
+          },
+          "purpose": {
+            "description": "Why this call is the natural next step.",
+            "type": "string"
+          },
+          "tool": {
+            "description": "Tool to call next.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "tool",
+          "arguments"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "required": [
+    "ok",
+    "request_id",
+    "status"
+  ],
+  "type": "object"
+}

AddedOct 8, 2026

TDQS

A4.7/5.0

Behavior5/5

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

Annotations only cover the generic write profile (readOnly=false, idempotent=false, destructive=false). The description goes well beyond: human-reviewed queue, no auto-play, confirm-before-calling requirement, return of queue position and estimated air time, and a concrete rate limit of 3 per requester name per 24h.

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?

Front-loads the trigger phrase and examples, then the confirmation caveat, the anti-behavior (no auto-play), the return shape, and the rate limit. Dense but every clause carries a distinct, actionable fact with no filler.

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

Completeness5/5

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

With an output schema present plus full parameter coverage and annotations covering the write profile, the remaining agent questions — when to call, whether to confirm, whether it plays immediately, and how often it can be called — are all answered. Nothing needed to invoke correctly is missing.

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 100%, so the baseline is 3, but the description adds the required/optional split in one line and clarifies that requested_by is the name/agent identity used for rate limiting (reinforcing why it matters). It adds modest grouping value, though the schema already carries most field meaning.

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?

States a specific verb and resource ('request a song', submits to CWI's human-reviewed queue) plus concrete examples of triggering utterances. It explicitly distinguishes the action from auto-play and from passive read tools like get_requests or get_up_next.

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 an explicit trigger condition with example phrasings and a prerequisite (confirm with the user before calling). It does not name a competing sibling such as submit_for_airplay and say when that one is preferred, so it stops short of full alternative routing.

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

All CWI Discovery Engine tools Inspect

Try in Browser

Context All Your Agents Can ShareAgents share what they learn, hand off work, and hold it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.