Sleuth MCP server: there isn't one
Sleuth ships an actively developed tool that touches MCP, and it points the other way: it distributes skills rather than exposing deployments.
Last verified 1 September 2026 · from The sleuth-io GitHub organization, the `sx` repository README and the official MCP registry
This page is one of 90 in a directory of monitoring and developer tools. Each page checks what an AI coding agent can get out of the tool through its MCP server, the connector that lets the agent query the tool directly.
Summary
Sleuth has no MCP server exposing its own data. Nothing returns a deploy, a lead time, a change failure rate or any other DORA metric.
It does publish one MCP-related repository, and it points in the opposite direction. `sleuth-io/sx` carries 300 stars, is Apache-2.0, and was pushed on 1 September 2026.
sx shares AI assets: skills, MCP entries, agents, rules and hooks, versioned across a team. It can even serve a vault, meaning one team's stored set of those assets, as an MCP endpoint. None of that exposes Sleuth's deployment tracking.
What is the Sleuth MCP server, and is it usable?
Sleuth tracks deployments and reports DORA metrics: deployment frequency, lead time for changes, change failure rate and time to restore. That is a compact, high-value dataset an agent would benefit from reading.
The repository that appears in an MCP search is sx, described as skill sharing made easy. Its README explains that AI assets usually live inside a single Git repository and drift when copied, and sx manages them with a manifest and a lock file.
It touches MCP twice. It installs MCP server entries into AI clients as part of an asset bundle. It also exposes a vault as an MCP endpoint through a relay, with sx cloud serve. Both are about distributing skills, not about Sleuth's metrics.
Every one of the 90 vendors in this directory gets the same four checks. Sleuth passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | No MCP server exposing Sleuth's own data. The one MCP-related repository in sleuth-io, sx, shares AI assets rather than deployment metrics. |
| Maintained | Fail | sleuth-io/sx is active, with 300 stars and a push on 27 August 2026, and it publishes none of Sleuth's DORA data. |
| Distributed | Fail | No package exposing Sleuth data, and no Sleuth entry in the official MCP registry. |
| Usable | Fail | There is no tool that returns a deploy, a change failure rate or a DORA metric. |
Sleuth works in CI and release, and publishes nothing exposing that work.
| Part of the work | What Sleuth has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Change tracking against pull requests | No. Sleuth links deploys to changes, and exposes none of it over MCP |
| CI & release | Deploy tracking, DORA metrics, deploy health | No. DORA metrics are the product, and no tool returns one |
| Production observability | Deploy health against monitoring sources | No. Sleuth reads monitoring data to judge a deploy, and exposes no tool for it |
| Agent observability & evals | None for your agents | No. sx distributes AI assets to clients; it does not observe what those agents did |
| AI cost management | None | No spend data, and no server |
Sleuth's DORA numbers stay inside Sleuth. An agent can reconstruct deployment frequency from a repository connector and a CI connector. That is more work than reading the number from Sleuth. All the inputs are reachable.
What can an AI agent do with Sleuth?
Sleuth has a real search result, but it belongs to something else rather than this product's connector.
Sleuth's MCP repository distributes skills; it does not expose Sleuth.
sleuth-io/sx is the only MCP-related repository in the organization. It has 300 stars, is Apache-2.0 and was pushed on 27 August 2026, so it looks substantial in a search result.
Its README describes managing AI assets across a team, installing MCP server entries into clients, and exposing a vault as an MCP endpoint with sx cloud serve. No tool returns a deploy or a DORA metric.
Guard: Read what a repository serves, not just that it mentions MCP. sx is a way to ship skills, not a way to query Sleuth.
Do you need the MCP server at all?
No, and no server exposes Sleuth's data. Reconstruct the inputs rather than reading the metric. Deployment frequency and lead time are derived from data that does have connectors: GitHub's server exposes pull requests, commits and Actions runs, which covers changes and when they shipped.
For the deployment event itself, connect the system that performs it. Harness exposes pipelines and executions across 240 resource types; Jenkins documents 18 tools with build history and change sets; CircleCI covers pipelines and jobs; Spinnaker has a community server with execution history.
For the change failure rate, which needs incident data joined to deploys, an incident connector supplies the other half. incident.io's incident_stats aggregates by more than ten dimensions, and Rootly exposes incident history with similarity search.
For deploy health specifically, which is the judgment Sleuth makes, connect the monitoring source it would have read. New Relic's analyze_deployment_impact is the closest single tool in this directory: it links a change event to what happened afterwards.
Read deploys from your CI and repository connectors, and join incidents from an incident platform to approximate the DORA view.
Sleuth MCP server setup
Nothing here installs a Sleuth server, because none exposes Sleuth's data. This is the working route: read deploys from the systems that produced them, and join incidents from an incident platform.
DORA metrics are derived, not stored. Deploy frequency and lead time come from your CI and repository history; change failure rate needs incidents joined to those deploys.
So the agent recomputes rather than reads. It lists Actions runs and merged pull requests through the GitHub server below, then computes the metric from what came back. That is the only route that exists.
Deploys and lead time, from GitHub
Deployments, workflow runs and merge timestamps are all in GitHub, which is where deploy frequency and lead time actually come from.
The personal access token is GitHub's own. --read-only keeps the agent to reading, and the toolset list bounds what registers.
claude mcp add-json "github" '{"command":"github-mcp-server",
"args":["stdio","--read-only"],
"env":{"GITHUB_PERSONAL_ACCESS_TOKEN":"<your-token>",
"GITHUB_TOOLSETS":"repos,pull_requests,actions"}}'Incidents, for the failure half
Change failure rate and restore time need incidents. incident.io runs a hosted server documenting 32 tools across incidents, alerts, escalations, schedules, the catalog and follow-ups.
No credentials go into the configuration. The endpoint authorizes in the browser on first use.
claude mcp add --transport http incidentio \ https://mcp.incident.io/mcp
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
What `sx` is, and is not
sleuth-io/sx is the organization's one MCP-related repository, at 300 stars and Apache-2.0, pushed 27 August 2026. Its README describes sharing AI assets: skills, MCPs, agents, rules, commands and hooks.
It can expose a vault as an MCP endpoint, printed by sx cloud status. That serves your assets, not Sleuth's deployment data, and it is not a Sleuth connector.
The command prints a URL and takes no credentials of its own; the vault it exposes is authorized separately.
sx cloud status # prints the MCP URL for your own vault
Read-only access, permissions and security
No Sleuth credential is created
Nothing exposes Sleuth's data, so nothing here asks for a Sleuth token.
Two connectors replace one, and grant more
Reading GitHub and an incident platform separately is a wider grant than a single DORA connector would have been.
--read-onlyis an explicit flagOn the local GitHub server it is auditable in a way that token scopes alone are not.
Incident data names people
Timelines, responders and postmortems reach the model in full once an incident connector is attached.
sxis a different trust decisionA served vault shares configuration your agents will execute. Review what the vault holds before you serve it.
Derived numbers carry derivation risk
An agent computing change failure rate from two sources can join them wrongly, and it will not know that it has.
Troubleshooting
- `sleuth-io/sx` looks like a Sleuth MCP server
- It is not.
sxshares AI assets across a team: skills, MCP entries, agents, rules and hooks, versioned together. It can even serve a vault as an MCP endpoint. - None of that exposes Sleuth's deployment tracking. It carries 300 stars, is Apache-2.0, and was pushed on 27 August 2026.
- You cannot get a deploy or a DORA metric out of Sleuth
- No tool returns one. Nothing exposes a deploy, a lead time, a change failure rate or any other DORA metric that Sleuth computes.
- The organization has MCP work, so coverage seems likely
- It has exactly one MCP-related repository, and that is
sx. Active MCP work in an organization is not evidence that the vendor's own data is exposed. - You want DORA metrics inside an agent conversation
- Connect the source systems. Deployment and change data live in GitHub, GitLab or your CI, all of which publish servers, and the agent computes rather than reads.
Sleuth MCP server: Reference
| Item | Value |
|---|---|
| Server exposing Sleuth data | None |
MCP-related repositories in sleuth-io | 1, sx |
sx stars | 300 |
sx last push | 27 August 2026 |
sx license | Apache-2.0 |
What sx serves | AI skills, MCP entries, agents, rules and hooks |
What sx does not serve | Deploys, lead time, change failure rate, any DORA metric |
| Official MCP registry results for Sleuth | None |
| Checked | 1 September 2026 |
What engineers report
The organization search returns one result, and naming it precisely is the point of this section.
| What was checked | What it shows |
|---|---|
MCP-related repositories in sleuth-io | 1, sx |
sx stars | 300 |
sx last push | 27 August 2026 |
sx license | Apache-2.0 |
What sx serves | AI skills and assets, not Sleuth deployment data |
| Official MCP registry results for Sleuth | None |
The sleuth-io GitHub organization was searched for MCP repositories on 1 September 2026 and returned one, sx. Its README was read on the same date and describes sharing AI assets, installing MCP entries into clients and serving a vault over MCP. The official MCP registry has no Sleuth entry.
Should you connect an agent to Sleuth?
No. There is nothing to connect. Best for a CI connector plus an incident connector, joined by the agent.
- Strongest fit
- Teams who want DORA reporting in a dashboard rather than in an agent.
- Main advantage
- None to report for MCP: no server exposes Sleuth's data.
- Main weakness
- DORA metrics have to be reconstructed from CI and incident connectors.
- Operational risk
- The real risk is mistaking
sxfor a Sleuth connector.
From Oodle
One platform for agent traces and infrastructure
Agent traces usually sit in a different product from the rest of your telemetry, so when a slow database makes an agent slow the symptom is in one tool and the cause is in another. Oodle keeps both in one query surface, from $10 per million spans.
See agent observabilityFrequently asked questions
Does Sleuth have an MCP server?
Not for its own data. Nothing returns a deploy or a DORA metric, and the official registry has no Sleuth entry as of 1 September 2026.
What is sleuth-io/sx then?
A tool for sharing AI assets across a team: skills, MCP entries, agents and hooks. It has 300 stars and can serve a vault as an MCP endpoint, but it exposes no Sleuth data.
How can an agent get DORA metrics?
By reconstructing them. A repository connector supplies changes, a CI connector supplies deploys, and an incident connector supplies failures.
What is closest to deploy health?
New Relic's analyze_deployment_impact, which links a change event to what happened afterwards in telemetry.
