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
- 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.
- 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.
- 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.
- 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.
- 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:
widgets:read
widgets:write
mcp_servers:read
mcp_servers:write
mcp_servers:invoke
knowledge:read
knowledge:write
workspace:read
analytics:readThe 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:
{
"mcpServers": {
"command-k": {
"url": "https://commandplusk.com/api/public/mcp",
"headers": {
"Authorization": "Bearer ck_pat_…"
}
}
}
}Claude Code
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):
{
"mcpServers": {
"command-k": {
"url": "https://commandplusk.com/api/public/mcp",
"headers": {
"Authorization": "Bearer ck_pat_…"
}
}
}
}Check the connection
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:
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.
- Orient — Learn what already exists in the workspace so you reuse rather than duplicate. (
get_workspace_overview, thenlist_hosted_mcps,list_widgets,list_knowledge_sources) - 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, thenget_hosted_mcp,resync_hosted_mcp) - Review the tool surface — Keep only safe tools reachable; mark mutating tools as write so they need approval. (
get_hosted_mcp, thenget_mcp_server,update_mcp_tool_policies) - Create the assistant — Create the in-product widget the end users will talk to. (
create_widget, thenupdate_widget) - 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, thenlist_widget_mcp_bindings) - Backend verifies the visitor — Give the human what their API needs to trust the forwarded visitor JWT. (
reveal_backend_identity) - Knowledge — Index the product docs so the assistant answers from real content. (
create_knowledge_source, thenbind_knowledge_to_widget,get_knowledge_source,search_knowledge) - Install — Hand the human the exact embed snippet and the token they must sign. (
get_widget_install, thenreveal_widget_secret,generate_test_jwt) - Verify — Prove the whole chain works before handing off. (
get_widget_setup_health, theninvoke_mcp_tool,generate_test_jwt) - 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, andinvoke_mcp_toolis 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_serverrefuses 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_urlandbase_urlare 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_secretandreveal_backend_identityreturn secrets once; Claude must not paste them into knowledge sources or prompts. Rotate withrotate_widget_jwt_secretif 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.