MCP
Connect any MCP client to your Trodo data. Ask Claude, Cursor, or your own agent to query runs, issues, evals, funnels, and users in plain language.
Trodo runs a hosted Model Context Protocol server at https://mcp.trodo.ai/mcp. Point an MCP client at it and your assistant can read straight from your Trodo data: agent runs and traces, detected issues, evaluator results, product-analytics funnels and retention, use-case clusters, and (opt-in) user profiles. No SQL, no dashboard clicks. You ask, it queries.
It's read-first and discovery-driven. The server ships a catalog of tools the model calls on its own (list_event_names, list_agent_runs, get_issue_details, run_funnel_query, and ~90 more), so "which users hit the hallucination issue this week, and what were they trying to do?" becomes a few tool calls instead of an afternoon of filtering.
It is no longer read-only. Alongside the read tools, the assistant can author prompts and their versions, build datasets from your recorded traces, run a prompt against your models, and run experiments across a dataset — the same things you'd do in the dashboard.
What you can do with it
Every tool is grouped into a capability bucket, and each bucket is gated by a scope on your key. At a high level:
| Capability | What the assistant can do | Examples |
|---|---|---|
| Agent runs & traces | Inspect runs, span trees, latency, token cost, tool calls, and failure modes; record feedback on a run. | list_agent_runs, get_agent_run, get_run_metrics, get_token_cost_breakdown, submit_run_feedback |
| Issues | Read detected issues, their root cause, timeline, affected users, and failing tools; change status. | list_issues, get_issue_details, get_issue_members, set_issue_status |
| Evaluations | Read evaluator results per run/span, manage evaluators, and work the human-review queue. | list_evaluators, get_eval_results_for_run, create_evaluator, backfill_evaluator, submit_human_eval_grade |
| Product analytics | Run funnels, retention, flows, insights, segment and period comparisons over your events. | run_funnel_query, run_retention_query, run_flow_query, compare_periods, get_segment_comparison |
| UX & technical health | Surface rage clicks, scroll depth, form abandonment, JS/network errors, and page performance. | analyze_ux_health(signal=…) |
| Capabilities | List what your agents are actually used for, pull the runs behind each, and re-run discovery. | list_capabilities, get_capability_runs, rediscover_capabilities |
| Signals | Read the raw detector output beneath issues — what fired on a run or span, and the quality scores that didn't cross. | get_run_signals, get_span_signals |
| Users & groups (opt-in) | Look up a profile, reconstruct a journey, find users by email or wallet, list groups. | get_user_profile, get_user_journey, find_users, list_groups |
| Spans | Find individual steps across runs — every failing tool call, every call to one model — and read one in full. | list_spans, get_span, search_spans |
| Prompts | Read the managed prompt registry, create prompts and versions, and move labels like production. | list_prompts, get_prompt, manage_prompt |
| Datasets | Build and edit evaluation datasets, including straight from recorded spans. | list_datasets, get_dataset, manage_dataset |
| Playground (opt-in) | Run a prompt against one or more models, or a multi-panel comparison. | list_playgrounds, get_playground, manage_playground |
| Experiments (opt-in) | Run a prompt across a whole dataset, read results, and compare experiments. | list_experiments, get_experiment, manage_experiment |
| Sessions & cohorts | Product sessions (browser visits) and saved user segments. | list_sessions, get_session, list_cohorts, manage_cohort |
| Search | One query across events, runs, spans, capabilities, signals and issues. | global_search |
| Boards | Saved dashboards — read, edit, duplicate the boards create_report builds. | list_boards, get_board, manage_board |
| Workflows (opt-in) | Automations that run on a trigger. | list_workflows, get_workflow, manage_workflow |
| Notifications (opt-in) | Your own inbox and delivery preferences. | list_notifications, manage_notifications |
| Model pricing (opt-in) | What each model costs your team in Trodo's reporting. | list_model_prices, manage_model_price |
Each authoring domain has two read tools plus one manage_* tool that takes an action (create, delete, run, …), rather than a separate tool per operation. Families of near-identical tools are collapsed the same way: analyze_ux_health(signal=…) replaces eight get_*_analysis tools, and describe_schema(of=…) replaces eight catalog list_* tools. Calling a retired name returns an error naming its replacement.
Narrowing with toolsets
94 tools is a lot for one connection. Add ?toolsets= to the URL to show only what you need:
claude mcp add --transport http trodo \
"https://mcp.trodo.ai/mcp?toolsets=debugging" \
--header "Authorization: Bearer trodo_mk_xxx"| Toolset | Tools | For |
|---|---|---|
debugging | ~28 | Runs, spans, issues, signals — fixing an agent |
analytics | ~25 | Funnels, retention, UX health, reports |
evals | ~24 | Evaluators, datasets, experiments |
authoring | ~12 | Prompts, playground, datasets, experiments |
workspace | ~11 | Boards, workflows, notifications, pricing |
identity | ~8 | User and group lookups |
Toolsets only ever narrow what your scopes already permit — they can't grant anything. Omit the parameter, or pass toolsets=all, for the full catalog.
manage_playground and manage_experiment call your model providers, so they spend real money — an experiment run costs one model call per dataset row, per model. Their scopes are off by default for that reason, and both are advertised to your client as non-read-only so it asks before running them.
The full tool set evolves as Trodo ships features, so the exact names above may shift. The server's tools/list is always the source of truth — most clients show it once connected, and the model reads it automatically.
Before you connect
Check your plan. MCP access requires a Growth or Enterprise plan. Free-plan keys are rejected with HTTP 402.
Generate a key. In Trodo, open Settings → MCP and click Create key. It's shown once at creation (Trodo stores only a hash), so copy it then. Keys are prefixed trodo_mk_. Creating and revoking keys needs the owner, admin, or developer role.
Pick the scopes the key should carry (for example agent runs + issues, but not user PII). See Scopes and permissions. You can issue several keys with different scopes; a team can hold up to 25.
Two ways to authenticate
- Direct API key — a
trodo_mk_key sent asAuthorization: Bearer …. Best for CLI and editor clients (Claude Code, Cursor, MCP Inspector, your own scripts). No browser flow. - OAuth — a browser consent flow. Used by clients that add a "custom connector" by URL, like Claude.ai web and Claude Desktop. You approve the connection once and the client manages the token.
Connect your client
Add it over HTTP with your key in the header (no wrapper needed):
claude mcp add --transport http trodo \
https://mcp.trodo.ai/mcp \
--header "Authorization: Bearer trodo_mk_xxx"The signature is claude mcp add [options] <name> <commandOrUrl> — every flag goes before the server name, and the URL is a positional argument, not a --url flag.
Confirm it registered:
claude mcp list
# expect: trodo http https://mcp.trodo.ai/mcpIf a proxy blocks HTTP from the CLI, use the stdio wrapper (trodomcp) instead. Flags — including --env — still come before the name; the child command goes after --:
claude mcp add --transport stdio \
--env TRODO_MCP_API_KEY=trodo_mk_xxx \
trodo -- npx -y trodomcpThen just ask, for example "List the top failure modes across my agent runs in the last 7 days." If tools don't show up, run /mcp inside a claude session to inspect connection status.
Open Settings (⌘+, on macOS, Ctrl+, on Windows/Linux) → Tools & MCP (called Features → MCP on some builds) → Add new MCP server → Edit JSON. Or edit ~/.cursor/mcp.json (global) or .cursor/mcp.json (per-project) directly.
Connect to the hosted server over HTTP — no local process, no wrapper:
{
"mcpServers": {
"trodo": {
"url": "https://mcp.trodo.ai/mcp",
"headers": { "Authorization": "Bearer trodo_mk_xxx" }
}
}
}If your build doesn't support remote servers, run the stdio wrapper instead:
{
"mcpServers": {
"trodo": {
"command": "npx",
"args": ["-y", "trodomcp"],
"env": { "TRODO_MCP_API_KEY": "trodo_mk_xxx" }
}
}
}Prefer filling in the form over pasting JSON? On the Command (stdio) tab set the command to npx, add -y and trodomcp as two separate arguments in that order, and add TRODO_MCP_API_KEY as a secret.
Save, then quit Cursor completely and reopen — MCP servers only start cleanly on a full restart. If tools don't appear, check View → Output → MCP for connection errors.
Cursor in the browser reads MCP from your Cursor account, not your local mcp.json — configure it separately.
Go to cursor.com/dashboard and sign in with the same account you use in the desktop app.
Open Integrations → MCP, then Add → Edit JSON.
Paste the same mcpServers.trodo block as the Cursor tab, with your real bearer token.
If you use both surfaces, restart the desktop app after changing the dashboard so the two stay in sync.
These use OAuth, not API keys. Add a custom connector with the URL:
https://mcp.trodo.ai/mcpComplete the consent flow in your browser. Claude manages the token from there. No trodo_mk_ key needed.
Inspect the server's tools and try calls by hand:
TRODO_MCP_API_KEY=trodo_mk_xxx npx @modelcontextprotocol/inspector npx -y trodomcpThe server speaks JSON-RPC 2.0 over Streamable HTTP (MCP 2025-03-26). POST to the endpoint with a bearer key:
curl https://mcp.trodo.ai/mcp \
-H "Authorization: Bearer trodo_mk_xxx" \
-H "Content-Type: application/json" \
-d '{
"jsonrpc": "2.0",
"id": 1,
"method": "initialize",
"params": { "protocolVersion": "2025-03-26", "clientInfo": { "name": "my-client", "version": "1.0.0" } }
}'The initialize response returns an Mcp-Session-Id header. Echo it back on every later request so your tool calls stitch into one session (Trodo uses it to group calls into a single run for its own analytics). Call tools/list to enumerate tools, then tools/call to run them.
The trodomcp wrapper
Clients that only speak stdio use the published trodomcp package. It's a zero-dependency adapter (Node 18+): it reads JSON-RPC from stdin, forwards each message to https://mcp.trodo.ai/mcp with your bearer key, and tracks the session id for you. Run it with npx -y trodomcp (no install) or npm install -g trodomcp.
| Variable | Default | Description |
|---|---|---|
TRODO_MCP_API_KEY | (required) | Your trodo_mk_ key. |
TRODO_MCP_URL | https://mcp.trodo.ai/mcp | Override for staging. |
TRODO_MCP_TIMEOUT_MS | 60000 | Per-request timeout. |
TRODO_MCP_DEBUG | 0 | Set to 1 to log diagnostics to stderr. |
Scopes and permissions
A key carries only the scopes you grant it, and each tool checks its scope before running. A call for a tool outside the key's scopes returns HTTP 403 naming the missing scope.
| Scope | Unlocks | Notes |
|---|---|---|
mcp:events | Product analytics, UX & technical-health tools, event catalog, report creation. | |
mcp:agent_runs | Agent runs, traces, run metrics, failure modes, run catalog. | |
mcp:cluster | Capabilities — what your agents are used for, the runs behind each, and re-running discovery. | Also still grants the Issues tools for back-compat, with a Deprecation header on the response. Move to mcp:issue. |
mcp:issue | Issues: list, details, root cause, evidence, members, timeline, status changes, and the raw signals beneath them. | The canonical Issues scope. Grant it explicitly — don't rely on mcp:cluster. |
mcp:evals | Evaluator management, results, and the human-review queue. | |
mcp:prompts | The managed prompt registry: read prompts and versions, create them, move labels. | Moving a label such as production changes which version your live agents fetch. |
mcp:datasets | Evaluation datasets: read, create, edit, and build from recorded spans. | |
mcp:playground | Prompt benches, and running a prompt against your models. | Off by default. Running calls your model providers and is billed to your team. |
mcp:experiments | Experiment results and comparisons, and running a prompt across a dataset. | Off by default. A run costs one model call per dataset row, per model. |
mcp:notifications | Your own notification inbox and preferences. | Off by default. Covers only your notifications, not your teammates'. |
mcp:workflows | Read and manage automations. | Off by default. Enabling a workflow starts it running unattended. |
mcp:team_config | Read and change model pricing rules. | Off by default. Changes every cost figure. Your team role is enforced on top. |
mcp:user:read_pii | User profiles, journeys, lookup by email/wallet, and groups. | Off by default. This exposes personal data — grant it only when you need user lookups. |
Limits and troubleshooting
- Rate limit. API keys default to 600 calls/minute per key; OAuth connections are lower.
HTTP 429means you're over. HTTP 401— the key was revoked or expired. Issue a new one from Settings → MCP.HTTP 402— your team is on the Free plan. Upgrade to Growth or Enterprise.HTTP 403mentioning a scope — re-issue the key with the missing scope (e.g.mcp:user:read_piifor user lookups).- Tool calls land as separate sessions — your client isn't echoing the
Mcp-Session-Idheader. Thetrodomcpwrapper handles this for you; for custom clients, send it back on every request.
Related
- Issues — what the issue tools read from.
- Evaluations — evaluators and results exposed over MCP.
- Reports — boards the analytics tools can compose.
- Product Analytics — the event data behind funnels and retention.