Set up Command+K from Claude

Command+K exposes a management MCP server. Connect your own Claude (claude.ai, Claude Desktop, Claude Code or Cursor) to it with a Personal Access Token, paste one starter prompt, and Claude runs the whole setup for you: it turns your API into a hosted MCP, creates an authenticated assistant, connects the two, indexes your docs and verifies the install. You only place the embed snippet and verify the visitor token in your backend.

What is "setup from Claude"?

Everything the dashboard can do, the Command+K MCP server can do too. The server lives at https://commandplusk.com/api/public/mcp, authenticates with a workspace-scoped Personal Access Token, and ships a get_setup_playbook tool: an ordered recipe that tells an agent which tool to call next, how to verify each step and what it must never do. Point your Claude at it and describe your product once; Claude does the clicking.

Five steps from a token to a running assistant

  1. Create a Personal Access Token. In the dashboard open Settings → MCP Access → New token. Tick the scopes listed below and copy the token — it is shown once.
  2. Connect Claude to the Command+K MCP. Add https://commandplusk.com/api/public/mcp as a custom connector (claude.ai), an mcpServers entry (Claude Desktop), or with `claude mcp add` (Claude Code). Cursor works the same way.
  3. Paste the starter prompt. Tell Claude your API spec URL, your docs URL and whether your users sign in, and ask it to follow get_setup_playbook.
  4. Let Claude run the playbook. It calls get_setup_playbook, then creates the hosted MCP, the assistant, the binding, the knowledge source and runs the health check, asking you before anything sensitive.
  5. Finish the manual parts. Place the embed snippet before </body>, sign a visitor JWT in your backend, verify the forwarded token in your API, and test in the real product.

1. Create a Personal Access Token

Open Settings → MCP Access in the dashboard and click New token. Name it after the client ("Claude Desktop") and select these scopes:

text
widgets:read
widgets:write
mcp_servers:read
mcp_servers:write
mcp_servers:invoke
knowledge:read
knowledge:write
workspace:read
analytics:read

The token starts with ck_pat_ and is shown once. It is bound to the workspace you created it in; give it an expiry if you only need it for the setup.

2. Connect Claude to the Command+K MCP

claude.ai (custom connector)

In claude.ai open Settings → Connectors → Add custom connector and paste https://commandplusk.com/api/public/mcp as the URL. claude.ai discovers the Command+K authorization server and signs you in with OAuth — you pick the workspace and approve the scopes on our consent page, no token to paste. The connection shows up under Authorized applications in Settings → MCP Access, where you can revoke it.

Claude Desktop

Add this block to claude_desktop_config.json (Settings → Developer → Edit Config), replacing the placeholder with your token:

json
{
  "mcpServers": {
    "command-k": {
      "url": "https://commandplusk.com/api/public/mcp",
      "headers": {
        "Authorization": "Bearer ck_pat_…"
      }
    }
  }
}

Claude Code

bash
claude mcp add --transport http command-k https://commandplusk.com/api/public/mcp \
  --header "Authorization: Bearer ck_pat_…"

Cursor

Add the same entry to ~/.cursor/mcp.json (or the project's .cursor/mcp.json):

json
{
  "mcpServers": {
    "command-k": {
      "url": "https://commandplusk.com/api/public/mcp",
      "headers": {
        "Authorization": "Bearer ck_pat_…"
      }
    }
  }
}

Check the connection

Ask Claude to call get_workspace_overview. If it answers with your workspace name and counts, the token and scopes are right.

3. The starter prompt

Replace the two URLs and, if your users don't sign in, drop the third line:

text
Set up Command+K for my product.
My API: <https://api.example.com/openapi.json>
My docs site: <https://docs.example.com>
Users sign in, so the assistant should be authenticated.
Follow get_setup_playbook.

4. What Claude will do, step by step

These are the steps of get_setup_playbook. Claude reads each tool's input schema before calling it and verifies every step before moving on.

  1. Orient — Learn what already exists in the workspace so you reuse rather than duplicate. (get_workspace_overview, then list_hosted_mcps, list_widgets, list_knowledge_sources)
  2. Hosted MCP from the API — Convert the product's API into a hosted MCP server at /api/public/mcp/d/<slug>. (create_hosted_mcp_from_api, then get_hosted_mcp, resync_hosted_mcp)
  3. Review the tool surface — Keep only safe tools reachable; mark mutating tools as write so they need approval. (get_hosted_mcp, then get_mcp_server, update_mcp_tool_policies)
  4. Create the assistant — Create the in-product widget the end users will talk to. (create_widget, then update_widget)
  5. Connect the backend — Bind the hosted MCP to the widget so the assistant can call the product's API on behalf of the signed-in user. (connect_widget_to_hosted_mcp, then list_widget_mcp_bindings)
  6. Backend verifies the visitor — Give the human what their API needs to trust the forwarded visitor JWT. (reveal_backend_identity)
  7. Knowledge — Index the product docs so the assistant answers from real content. (create_knowledge_source, then bind_knowledge_to_widget, get_knowledge_source, search_knowledge)
  8. Install — Hand the human the exact embed snippet and the token they must sign. (get_widget_install, then reveal_widget_secret, generate_test_jwt)
  9. Verify — Prove the whole chain works before handing off. (get_widget_setup_health, then invoke_mcp_tool, generate_test_jwt)
  10. Hand-off — Tell the human exactly what is done and what remains manual. (get_widget_install)

Two choices Claude will make with you: the hosted MCP's auth_mode (per_user_token when external MCP clients like Claude or Cursor should connect with their own API key — the in-product assistant works with any mode because it authenticates through the widget's visitor identity), and the binding's exposure (support answers only from read tools; full lets the assistant perform actions with approval and requires an authenticated widget).

5. What stays manual

  • Place the embed snippet (from get_widget_install) before </body> in the product's page template.
  • For an authenticated widget: mint a visitor JWT on the product's backend (HS256 with the widget secret) and pass it as data-cmdk-token.
  • Verify the forwarded visitor JWT in the product's API (reveal_backend_identity gives the secret + audience).
  • Test in the real product: open the launcher, ask a docs question, ask for an action that hits the API.

For the visitor token, Claude hands you the widget secret and the embed snippet. Sign an HS256 JWT with sub, email, name, scopes and a short exp, and pass it as data-cmdk-token. Reference code in Node, Python, PHP and Go is on the end-user JWT page. Your API must verify the forwarded token the same way — signature, aud, exp — and reject anything else; see connection modes.

Safety notes

  • Least-privilege token. Only grant the scopes above. Set an expiry on the PAT and revoke it in Settings → MCP Access when the setup is done.
  • Sensitive tools stay off. The playbook's guardrails keep delete, billing, admin and secret-handling tools disabled unless you explicitly ask. Review the tool policies on the hosted MCP afterwards.
  • Every tool says what it does. Each tool Command+K exposes carries a plain title and a read-only or destructive hint, so the client can show you which calls only read your workspace and which change or delete something. Tools that permanently remove data — delete_widget, delete_mcp_server, delete_knowledge_source, delete_hosted_mcp, rotate_widget_jwt_secret, revoke_team_invitation — are marked destructive, and invoke_mcp_tool is treated as destructive because it can call anything on a connected server.
  • A guessed parameter fails loudly. Every tool publishes its exact parameters, and a field it does not define is dropped before the tool runs. So that a dropped field can never look like success, update_mcp_server refuses a call whose parameters were all unknown and answers with the list of fields it accepts, instead of returning ok having changed nothing. On a custom source built from a GraphQL or OpenAPI spec, server_url and base_url are the same host: pass either one and both are written, so the connector keeps working after a host change rather than calling the old, dead one.
  • Approval before writes. Leave require write approval on so the assistant asks the end user before any mutating tool call.
  • Secrets are shown, not stored. reveal_widget_secret and reveal_backend_identity return secrets once; Claude must not paste them into knowledge sources or prompts. Rotate with rotate_widget_jwt_secret if a transcript leaks.
  • Every call is audited. Tool calls made through the MCP land in the workspace audit log with the token that made them.

Next steps

FAQ

Which scopes does the token need?
widgets:read, widgets:write, mcp_servers:read, mcp_servers:write, mcp_servers:invoke, knowledge:read, knowledge:write, workspace:read and analytics:read. Skip team:*, secrets:read and workspace:write — the setup never needs them.
Can Claude enable dangerous tools on my API?
Not on its own. The playbook's guardrails tell it to keep sensitive tools (delete, billing, admin) off by default and to ask you first. You can also inspect and change every tool policy in the dashboard afterwards.
Does this work with ChatGPT or other MCP clients?
Yes. Any MCP client that speaks Streamable HTTP and can send a bearer header (or run OAuth) can call the same tools. The playbook is just a tool; the client doesn't need to be Claude.
What if Claude stops halfway?
Ask it to continue — get_setup_playbook accepts from_step so it resumes where it left off, and step 0 tells it to reuse what already exists instead of creating duplicates.
How do I cut Claude off later?
Revoke the PAT in Settings → MCP Access (or the OAuth app under Authorized applications). Every token issued to that client stops working immediately.