For the complete documentation index, see llms.txt. This page is also available as Markdown.

Agent Platforms

How an agent connects to Cakewalk's MCP Gateway, plus the catalog of supported runtimes (Cursor, Claude, ChatGPT, Codex, Copilot and more). One pattern, five install methods.

Agent Platforms are the AI agent runtimes that plug into Cakewalk's MCP Gateway: Cursor, Claude, ChatGPT, Codex, Copilot and more. They all connect the same way: point the client at the gateway, then sign in through Cakewalk on first connect. What differs is the install method, how each client gets pointed at the gateway.

This page covers the connection pattern and the per-method install reference. To set up, add and manage your own agents, see My Agents.

πŸ“– Key Concepts

  • Agent Platform: An AI agent runtime (Cursor, Claude, ChatGPT, Codex, Copilot and others).

  • Install method: How Cakewalk hands the gateway values to a given agent. Five methods: Deep Link, JSON Config, YAML Config, Custom Form and CLI.

  • Gateway URL: The single shared endpoint the agent client points at. Filled into the install flow automatically, never copy-pasted by hand.

πŸ’‘ Why this matters: Cakewalk supports the agent runtimes employees already use: no swap-out, no migration. One connection pattern covers every agent, and the right install path is shown per agent.


πŸ”Œ The Connection Pattern

Every supported Agent Platform connects the same way. What differs is how the client takes the values Cakewalk gives it.

Definition

The MCP Gateway exposes a single MCP server endpoint, shared across every organization. To bring an agent under governance, the client needs the Gateway URL in its MCP config. Form-based clients also take a server name, transport type and auth method.

On first connect the employee signs in through Cakewalk. That sign-in binds the agent to the employee's identity and sets the tenant. From then on the agent calls the Gateway, the Gateway proxies to the downstream Agent Connection and every decision is recorded.

How it works

  1. In My Agents, the employee clicks Connect on the agent.

  2. The employee follows the install steps Cakewalk shows for that agent: one click, a config snippet or a command.

  3. The employee signs in through Cakewalk to link the agent to their identity.

  4. The agent shows as Active. Every tool call now flows through the Gateway.

If the session credential later expires or the agent client is reinstalled, the employee signs in again. The same install method applies.

Every organization shares one gateway endpoint, https://mcp-gateway.getcakewalk.io/mcp. There is no per-org URL. Tenant identity comes from the employee's Cakewalk sign-in, and the install flow fills the endpoint in automatically, so employees never copy a raw URL by hand.

Why this matters

  • One pattern, every agent. Cursor, Claude Desktop, Copilot, ChatGPT and Codex all use the same connection model.

  • No raw secrets. The employee signs in through Cakewalk; they never paste or handle credentials directly.

  • Governance from the first call. Default policies apply immediately: no extra setup, no waiting period.


βœ‹ Approval Support

Every Agent Platform connects the same way, but not every one can stop and ask. This is what decides whether a Require approval Policy actually asks anyone.

Definition

When a tool call hits a Require approval Policy, the MCP Gateway pauses the call and asks the User who delegated the Agent. It asks over MCP elicitation, a protocol channel the Agent client has to implement itself. Clients that implement it show an inline prompt. Clients that do not have nowhere to ask.

Support by Agent Platform

Agent clients an employee connects. For the Claude Console and the Messages API, see Anthropic.

Agent Platform
Inline approval prompt

Claude Code

Yes

Cursor

Yes

VS Code

Yes

Codex

Yes

Claude (claude.ai and Claude Desktop)

No

Microsoft 365 Copilot

No

ChatGPT

No

Why this matters

  • Pick the client before you write the Policy. On a client with no prompt, a Require approval Policy behaves as a Deny Policy.

  • Nothing fails silently. Every fallback denial is recorded in Agent Activity with Based on: Fallback policy, alongside the Policy that fired.

  • The gap belongs to the client. Support arrives when the vendor ships elicitation. No change is needed on the Cakewalk side.

Learn more


The fastest path, used by agents like Cursor. One click hands the agent a deep link that carries the Gateway URL.

How it works

  • Cakewalk generates the one-click link.

  • The employee clicks Open; the agent opens and configures itself automatically.

  • The agent shows as Active once it connects.

A Copy link fallback covers browsers that block deep-link handlers.


πŸ“„ JSON Config Install

For agent clients that read MCP servers from a config file.

How it works

  • Cakewalk shows a pre-filled config snippet.

  • The employee pastes it into the agent's MCP config file and saves.

  • The employee restarts the agent. Cakewalk then appears in its MCP servers list.


🧾 YAML Config Install

Same as JSON Config, with a YAML snippet instead of JSON.

How it works

  • Cakewalk shows a pre-filled YAML snippet.

  • The employee pastes it into the agent's config file, saves and restarts the agent.


πŸ“ Custom Form Install

For agent clients with their own guided MCP setup screen.

How it works

  • Cakewalk shows the values the agent's form needs: Server name, Server URL, Transport type and Auth method.

  • The employee adds the server in the agent, saves, then signs in through Cakewalk when redirected.


πŸ’» CLI Install

For agents installed with a shell command.

How it works

  • Cakewalk pre-fills the command with the Gateway URL.

  • The employee copies it and runs it in a terminal.

  • The agent connects and shows as Active.

Commands are shaped like:

The exact syntax depends on the agent CLI; Cakewalk fills in the right one.


Last updated

Was this helpful?