MCP server
The Ritual MCP server lets coding agents and custom MCP clients pull exploration context, recommendations, build briefs, and the workspace knowledge graph into their session over HTTPS using the Model Context Protocol.
If you’re using a supported coding agent (Claude Code, Cursor, Windsurf, Kiro, Gemini CLI, VS Code Copilot, Codex), use the CLI to set up the MCP connection automatically. The reference below is for building your own MCP client or wiring up an agent the CLI doesn’t auto-configure yet.
Endpoint
| Field | Value |
|---|---|
| URL | https://mcp.ritualapp.cloud/mcp |
| Transport | MCP Streamable HTTP |
| Auth | Authorization: Bearer ritual_pat_… on every request |
| Content negotiation | Clients MUST send Accept: application/json, text/event-stream on POST requests (per spec) |
The endpoint serves a session-init handshake. Send POST /mcp with an MCP initialize JSON-RPC request and the dual Accept header; the server responds 200 with an mcp-session-id you include on subsequent requests.
Quick connection — your own MCP client
# 1. Get a PAT
# https://app.ritualapp.cloud/settings/tokens → Create token
# 2. Initialize a session
curl -X POST https://mcp.ritualapp.cloud/mcp \
-H "Authorization: Bearer ritual_pat_YOUR_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": {
"protocolVersion": "2024-11-05",
"capabilities": {},
"clientInfo": {"name": "my-client", "version": "0.1.0"}
}
}'
Response includes an Mcp-Session-Id header (e.g. mcp-session-id: 9975a189-…). Pass that as a header on every subsequent request:
curl -X POST https://mcp.ritualapp.cloud/mcp \
-H "Authorization: Bearer ritual_pat_YOUR_TOKEN" \
-H "Content-Type: application/json" \
-H "Accept: application/json, text/event-stream" \
-H "Mcp-Session-Id: 9975a189-…" \
-d '{"jsonrpc":"2.0","id":2,"method":"tools/list"}'
Wiring up specific clients manually
Easiest path: run ritual init and the CLI auto-detects every supported agent on your machine and registers Ritual against your freshly-minted PAT. The per-client recipes below are for when the CLI doesn’t auto-configure your client yet, or you want to wire it up by hand.
What every client needs
Three things, regardless of which client you’re configuring:
- The URL —
https://mcp.ritualapp.cloud/mcp - The auth header —
Authorization: Bearer ritual_pat_…on every request. Get a PAT at/settings/tokens(“Create token”). Legacyrtl_…keys from earlier Ritual versions don’t authenticate here. - An env-var-backed config if you can — most clients support reading the bearer from an environment variable so the PAT doesn’t live in a file you might commit. The recipes below show the env-var form (
RITUAL_API_KEY) wherever the client supports it.
Then each client has its own config syntax, file path, and “is it connected” check — listed in the tabs below.
Easiest: run ritual init — the CLI runs claude mcp add-json automatically against the PAT it just minted for you.
Manual (one-line):
claude mcp add-json --scope project ritual '{
"type": "http",
"url": "https://mcp.ritualapp.cloud/mcp",
"headers": { "Authorization": "Bearer ritual_pat_YOUR_TOKEN" }
}'
| Aspect | Detail |
|---|---|
| Scope | --scope project writes .mcp.json in the current dir (safe to commit if the bearer is env-var-backed); --scope user writes ~/.claude.json (global, your PAT in one place) |
| Verify | claude mcp list — Ritual should report ✓ connected. (Note: Claude’s connectivity probe doesn’t always send the dual Accept header so the list view occasionally shows ✗ even when in-session tool calls work — see the FAQ below.) |
| Restart needed? | No — Claude Code picks up new MCP servers on the next /mcp invocation. |
Cursor speaks Streamable HTTP from v0.48.0+. Earlier versions only support stdio and won’t talk to a remote MCP server.
{
"mcpServers": {
"ritual": {
"url": "https://mcp.ritualapp.cloud/mcp",
"headers": {
"Authorization": "Bearer ritual_pat_YOUR_TOKEN"
}
}
}
}
| Aspect | Detail |
|---|---|
| Project scope | .cursor/mcp.json in the repo root — safe to commit when the bearer is env-var-backed |
| Global scope | ~/.cursor/mcp.json — applies to every project |
| Env vars | Cursor doesn’t currently expand ${VAR} in MCP config values; the recommended pattern is global scope (~/.cursor/mcp.json) so the PAT never lives in the repo |
| Verify | Settings → Tools & MCP — Ritual shows up with a tool count; expand to see the full tool list |
| One-click install | Drop this onto a docs page as a button: cursor://anysphere.cursor-deeplink/mcp/install?name=Ritual&config=<base64-of-the-JSON-above> |
| Gotcha | Cursor enforces a 40-tool global cap across all registered MCP servers; users running many MCPs may see Ritual tools silently skipped past that limit |
Codex (CLI + the VS Code extension) shares a single TOML config at ~/.codex/config.toml. There is no project-scoped variant.
CLI add command (writes the TOML for you):
codex mcp add ritual \
--url https://mcp.ritualapp.cloud/mcp \
--bearer-token-env-var RITUAL_API_KEYThen export the PAT in your shell:
export RITUAL_API_KEY=ritual_pat_YOUR_TOKENManual — edit ~/.codex/config.toml:
[mcp_servers.ritual]
url = "https://mcp.ritualapp.cloud/mcp"
bearer_token_env_var = "RITUAL_API_KEY"
| Aspect | Detail |
|---|---|
| Scope | Single global TOML file — no project override; same config feeds the CLI and the VS Code extension |
| Env vars | Native — point bearer_token_env_var at the env var name and Codex reads it at startup |
| Verify | Type /mcp inside the Codex TUI — Ritual should appear in the connected-servers list |
| Gotcha | A TOML syntax error in ~/.codex/config.toml breaks BOTH the CLI and the IDE extension at once. If Codex stops loading MCP after an edit, python3 -c 'import tomllib; tomllib.load(open("~/.codex/config.toml","rb"))' will surface the parse error |
{
"mcpServers": {
"ritual": {
"url": "https://mcp.ritualapp.cloud/mcp",
"headers": {
"Authorization": "Bearer ${RITUAL_API_KEY}"
},
"disabled": false,
"autoApprove": [
"find_explorations",
"get_exploration",
"get_recommendations",
"get_workspace_overview",
"query_knowledge_graph",
"score_context_pulse"
]
}
}
}
| Aspect | Detail |
|---|---|
| Project scope | .kiro/settings/mcp.json in the repo root |
| Global scope | ~/.kiro/settings/mcp.json |
| Env vars | Native — ${RITUAL_API_KEY} is expanded at load time. Put the export in your shell init so the file never holds a literal PAT |
| Verify | MCP Servers panel — Ritual lists with its tool count and connection state |
| One-click install | https://kiro.dev/launch/mcp/add?name=Ritual&config=<url-encoded-JSON-above> |
autoApprove | The tools above are read-only / idempotent — pre-approving them lets the agent loop stay fluid without prompting on every call. Leave write-tier tools (accept_recommendations, sync_implementation, create_workspace, add_collaborator) OUT of autoApprove so the human stays in the loop on anything that mutates state |
{
"mcpServers": {
"ritual": {
"serverUrl": "https://mcp.ritualapp.cloud/mcp",
"headers": {
"Authorization": "Bearer ritual_pat_YOUR_TOKEN"
}
}
}
}
| Aspect | Detail |
|---|---|
| Global scope | ~/.codeium/windsurf/mcp_config.json (only location Windsurf reads today) |
| Project scope | Not natively supported — Windsurf treats MCP config as user-level. For per-repo overrides, use Windsurf’s workspace settings to point at a project-specific config path |
| Verify | Cascade panel → MCP icon → Ritual should list with its tool inventory |
| Enterprise note | Windsurf admins can centrally manage MCP server lists via the admin console — useful if you’re rolling Ritual out to a team and don’t want each engineer to register manually |
VS Code Copilot uses the top-level key servers (not mcpServers like everyone else):
{
"servers": {
"ritual": {
"type": "http",
"url": "https://mcp.ritualapp.cloud/mcp",
"headers": {
"Authorization": "Bearer ritual_pat_YOUR_TOKEN"
}
}
}
}
| Aspect | Detail |
|---|---|
| Project scope | .vscode/mcp.json in the repo root |
| Global scope | User settings → MCP, or ~/.vscode/mcp.json |
| Env vars | Reference them as ${env:RITUAL_API_KEY} inside the header value |
| Verify | Command palette → MCP: List Servers — Ritual reports its connection state + tool list |
| Mode | MCP works in Agent mode only — toggle the mode in the Copilot Chat dropdown before invoking tools |
Attach as a remote MCP server via Anthropic’s MCP connector:
{
"mcp_servers": [
{
"type": "url",
"url": "https://mcp.ritualapp.cloud/mcp",
"name": "ritual",
"authorization_token": "ritual_pat_YOUR_TOKEN"
}
]
}
| Aspect | Detail |
|---|---|
| Scope | Per-request — pass mcp_servers in the body of each messages.create call |
| Header required | Add anthropic-beta: mcp-client-2025-04-04 to the request alongside your API key |
| Verify | Tool calls return mcp_tool_use blocks; if the connector can’t reach Ritual you’ll see an explicit mcp_tool_result with is_error: true and a connection diagnostic |
Tools
Tools exposed today. Tool names + arg shapes are stable; new tools are added; existing ones don’t break.
Discovery & state
| Tool | Purpose |
|---|---|
find_explorations | Semantic search across explorations the PAT can access |
get_exploration | Exploration metadata + discovery questions + answers |
get_workspace_overview | Workspace summary — explorations, status badges, recent activity |
list_workspaces | Workspaces visible to the PAT |
list_explorations | All explorations in a workspace |
query_knowledge_graph | Reverse lookup decisions + deferrals + commits by file path or topic |
ping | Health check |
Reasoning Readiness scoring
| Tool | Purpose |
|---|---|
score_context_pulse | Score Reasoning Readiness / Context Debt for an existing exploration or a free-form feature description. See Context Pulse. |
check_anti_goals | Detect collisions with declared anti-goals in the workspace |
check_exploration_overlap | Detect overlap with existing explorations before starting a new one |
Discovery → recommendations pipeline
| Tool | Purpose |
|---|---|
generate_problem_statement | Turn a raw idea into a structured problem statement |
generate_considerations | Surface the dimensions of a problem worth thinking through |
suggest_discovery_questions | Generate classified discovery questions (🔴 blocking / 🟡 uncertain / 🟢 answerable) |
accept_discovery_questions | Lock in the user-picked subset |
submit_answer / iterate_answer / get_answer_state | Question-answer cycle |
start_agentic_run / resume_agentic_run / cancel_agentic_run / get_agentic_run / list_agentic_runs | The pipeline that generates recommendations from answered questions |
get_recommendations / accept_recommendations / refine_considerations | Review and lock recommendations |
Build brief + KG writeback
| Tool | Purpose |
|---|---|
generate_build_brief | Produce implementation-ready delivery context (BUILD-BRIEF.md) from accepted recommendations |
get_build_brief_status / get_requirement_set_status | Poll generation progress |
sync_implementation | Write what shipped (commits, files, RBs verified, deferrals) back to the workspace KG. Called as a side effect of the implementation stage, not a separate user-visible step. |
Workspace + collaborator management
| Tool | Purpose |
|---|---|
create_workspace / create_exploration | Bootstrap state |
add_collaborator | Add a teammate to an exploration |
set_anti_goals | Declare what’s explicitly out of scope (workspace-wide) |
add_knowledge_source / list_knowledge_sources / get_knowledge_source / remove_knowledge_source | Attach docs, tickets, transcripts as context |
list_templates | Workspace exploration templates |
suggest_high_leverage_problems | Workspace-level suggestion engine |
fork_sibling_explorations | Create related explorations sharing context |
Typical client flow
For a coding-agent integration:
find_explorations— locate the right exploration with a natural-language query, orscore_context_pulseif starting from a raw feature description.get_exploration+get_recommendations— load the structured context.generate_build_brief(if not already generated) — pull the implementation-ready delivery context.- Code the change against the brief.
sync_implementation— writeback what shipped as code lands. Future builds in this workspace reuse the decisions.
FAQ
I’m getting 401 Unauthorized.
Check that the Authorization header is exactly Bearer ritual_pat_… (note the space) and that the PAT hasn’t been revoked at /settings/tokens. Note: legacy rtl_… tokens from earlier Ritual versions don’t authenticate against mcp.ritualapp.cloud.
I’m getting 406 Not Acceptable.
Per the MCP Streamable HTTP spec (2025-03-26), clients MUST send Accept: application/json, text/event-stream on every POST. If you only send one of the two, the SDK transport rejects with 406. Add both content types to your Accept header. This is also why claude mcp list sometimes shows ritual as ✗ failed — Claude’s connectivity probe doesn’t always send the dual header even though its actual in-session tool calls do.
I’m getting 404 “Session not found” on follow-up requests.
Each initialize POST gets a fresh Mcp-Session-Id. Subsequent requests MUST include that exact session ID as a header (Mcp-Session-Id: <uuid>). If you re-initialize to get a new session ID, the old one is gone — sessions live in-memory on the server pod.
Does Ritual MCP work over stdio?
No. The hosted server speaks Streamable HTTP only. If your client only supports stdio, run a bridging proxy (e.g. mcp-proxy) or switch to a client that supports remote MCP.
How do I rotate a PAT?
Sign in to app.ritualapp.cloud, open Settings → Tokens, create a new token, update your client config, then revoke the old one. In-flight requests using the old token start failing immediately on the next call.
What about connecting external sources (Confluence, Drive, Jira) to Ritual?
That’s a separate flow — the Ritual app’s Knowledge Sources UI ingests external content into your workspace’s knowledge graph. You don’t paste those external server URLs here. The MCP server documented on this page is Ritual’s OUTBOUND server (clients connect to it); the Knowledge Sources flow is INBOUND (Ritual consumes external content).
Related
- CLI — auto-configures the MCP connection in supported agents
- API keys — create + rotate PATs
- Build stages — what each stage of
/ritual builddoes - Context Pulse — Reasoning Readiness scoring
- Model Context Protocol — protocol spec