CWI Discovery Engine

Pitch for Playlist

pitch_for_playlist

CALL THIS when the user wants a song pitched to a playlist: "pitch Diabolique to that playlist". Submits the user's pitch to CWI — confirm with the user before calling. Goes to human review, NEVER auto-added. Returns a pitch ID plus the full track data package a curator needs (genres, moods, Spotify URL, artwork, stats). Rate limit: 3 per requester per 24h. Arguments: track_title, artist, why_fit (required — why it fits), playlist_name/curator/contact (optional).

Input Schema

Name	Required	Description
`artist`	Yes	Artist name.
`contact`	No	Optional: email for follow-up.
`curator`	No	Optional: curator name or handle.
`why_fit`	Yes	Why this track fits the playlist (required).
`track_title`	Yes	Title of the track you are pitching.
`playlist_name`	No	Optional: target playlist name.

Output Schema

Name	Required	Description
`ok`	Yes
`note`	No
`artist`	No
`review`	No
`status`	Yes
`curator`	No
`receipt`	No	Confirmation receipt; id is the real intake row id.
`why_fit`	No
`_session`	No	Chain session: pass _session.session_token back in the next call to continue the chain.
`pitch_id`	Yes
`try_next`	No	Suggested follow-up calls, each a pre-compiled {tool, arguments, purpose} payload.
`track_data`	No
`track_title`	No
`submitted_at`	No
`playlist_name`	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": "pitch_for_playlist response: pitch ID, review status, and a receipt with the real D1 row id.",
+  "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"
+    },
+    "curator": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "note": {
+      "type": "string"
+    },
+    "ok": {
+      "type": "boolean"
+    },
+    "pitch_id": {
+      "type": [
+        "integer",
+        "null"
+      ]
+    },
+    "playlist_name": {
+      "type": [
+        "string",
+        "null"
+      ]
+    },
+    "receipt": {
+      "additionalProperties": false,
+      "description": "Confirmation receipt; id is the real intake row id.",
+      "properties": {
+        "id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "received_at": {
+          "type": "string"
+        },
+        "status": {
+          "type": "string"
+        }
+      },
+      "required": [
+        "id",
+        "status",
+        "received_at"
+      ],
+      "type": "object"
+    },
+    "review": {
+      "type": "string"
+    },
+    "status": {
+      "type": "string"
+    },
+    "submitted_at": {
+      "type": "string"
+    },
+    "track_data": {
+      "additionalProperties": true,
+      "type": [
+        "object",
+        "null"
+      ]
+    },
+    "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"
+    },
+    "why_fit": {
+      "type": "string"
+    }
+  },
+  "required": [
+    "ok",
+    "pitch_id",
+    "status"
+  ],
+  "type": "object"
+}

AddedOct 8, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing that pitches go to human review, are NEVER auto-added, are rate-limited to 3 per requester per 24h, require user confirmation, and return a pitch ID plus a curator data package. These are materially useful behavioral traits not captured by readOnly/idempotent/destructive hints.

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 condition in an imperative 'CALL THIS when...' clause, then layers in confirmation, outcome, rate limit, and parameters. Dense but every sentence carries distinct information 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?

Complete for a mutation tool: it covers the trigger, the confirmation requirement, the review outcome, rate limits, and the return package. An output schema exists, so the description need not detail return structure, and nothing critical 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?

Schema coverage is 100%, so the schema already documents all six parameters and required/optional status. The description reiterates which fields are required vs optional and frames why_fit as the fit rationale, but adds little syntax or format detail beyond the schema, so baseline 3 applies.

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 (pitch) and resource (song to a playlist) and includes an example utterance that pins the intent. It is clearly distinguishable from siblings like submit_for_airplay, submit_sync_brief, or nominate_featured.

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?

Explicitly says 'CALL THIS when the user wants a song pitched to a playlist' and instructs confirming with the user first, which gives clear usage context. It does not explicitly name a sibling tool to use instead, so it falls short of the top bar.

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.