Faros AI MCP server: there isn't one
An engineering intelligence platform that already ingests from a dozen connected tools, and exposes none of the result to an agent.
Last verified 1 September 2026 · from The faros-ai GitHub organization, its documentation site 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
No Faros AI MCP server exists. Its 33 public repositories contain none, and the official MCP registry has no entry either. The product remains live, but it cannot expose its cross-tool engineering data to an agent.
Both faros.ai and docs.faros.ai resolve and return HTTP 200, so this is a live vendor with live documentation that does not mention a server.
Faros AI's job is aggregating data from CI, source control, incident and project tools, most of which do publish MCP servers of their own.
What is the Faros AI MCP server, and is it usable?
Faros AI is an engineering intelligence platform. It ingests from source control, CI, incident management and project tracking, then reports on delivery performance, developer experience and increasingly on AI tool usage.
That makes it a second-order product. Almost everything it holds originated somewhere else, and Faros AI joins and models it.
For an agent, that changes what is worth connecting. The underlying data is often reachable through the source system's own server, so what is missing is Faros AI's cross-tool model rather than the raw facts.
Every one of the 90 vendors in this directory gets the same four checks. Faros AI passes 0 of them.
| Check | Result | Evidence |
|---|---|---|
| Official | Fail | No MCP server. A search of the faros-ai GitHub organization, which has 33 public repositories, for MCP repositories returns zero results on 1 September 2026. |
| Maintained | Fail | There is nothing to maintain. None of the 33 public repositories in faros-ai is MCP work. |
| Distributed | Fail | No package, and no Faros AI entry in the official MCP registry. |
| Usable | Fail | Both faros.ai and docs.faros.ai resolve and return HTTP 200, and neither documents an MCP server. |
Faros AI reports across several engineering stages, and publishes no server for any of them.
| Part of the work | What Faros AI has here | Can an agent reach it |
|---|---|---|
| Code, tests & review | Pull request and review metrics | No. Faros AI models review data it ingests, and exposes none of it over MCP |
| CI & release | Build and deployment metrics, and DORA reporting: deployment frequency, lead time and failure rate | No. The metrics are computed from ingested CI data and stay inside the platform |
| Production observability | Incident data ingested from other tools | No. Incidents are inputs to the model, not an exposed surface |
| Agent observability & evals | AI tool usage reporting | No. Faros AI reports on how teams use AI tools, and offers no way for an agent to read that |
| AI cost management | None | No spend data exposed, and no server |
The inputs are more reachable than the output. An agent can query GitHub, a CI system and an incident platform directly. It cannot get the joined view across them, which is what Faros AI sells.
What can an AI agent do with Faros AI?
Faros AI covers enough stages that an agent looks well served, until you look for the connector and find none.
Every source Faros AI ingests may have a server; Faros AI's own model does not.
The faros-ai organization has 33 public repositories and none is MCP-related, as of 1 September 2026. Both the site and the documentation site return HTTP 200 and document no server.
The tools it ingests from, including GitHub, CircleCI, Jenkins, PagerDuty and incident platforms, publish maintained servers of their own.
Guard: Ask whether the question needs the cross-tool join. If it does not, connect the source system directly and skip the aggregation layer.
Do you need the MCP server at all?
No, and nothing in the product exposes one. Go to the sources. Most of what Faros AI ingests is reachable directly. GitHub's server has 85 tools. They expose pull requests, reviews and Actions runs.
Jenkins, CircleCI and Harness cover builds and deployments, and PagerDuty, Rootly and incident.io cover incidents.
For delivery metrics an agent can compute, the raw material is in those connectors. Deployment frequency comes from CI, lead time from commits and merges, and failure rate from the incident platform.
For AI tool usage, which is Faros AI's newer focus, PostHog documents 81 tools in its AI observability category. Braintrust exposes evaluation and log data. Neither is a developer-experience product, but both hold usage data an agent can query.
What none of these reproduces is the joined model across teams and time that Faros AI builds. If that specific view is the question, the platform's own interface remains the route.
Connect the source systems for facts, and keep Faros AI's interface for the cross-tool view it computes.
Faros AI MCP server setup
Nothing here installs a Faros AI server, because there is none. This is the working route, and it has an unusual shape: connect the sources Faros already ingests.
Faros AI aggregates CI, source control, incident and project data. Most of those systems publish their own servers, so the inputs are reachable even though the aggregate is not.
What you lose is the join. An agent reading GitHub and an incident tool separately has to compute the cross-tool view that Faros computes for you.
GitHub, hosted
Source control and Actions are a primary input for Faros installations. GitHub's hosted server is the shortest route to both.
No credentials go into the configuration. The endpoint authorizes in the browser, so nothing long-lived is stored locally.
claude mcp add --transport http github \ https://api.githubcopilot.com/mcp/
GitHub, local and read-only
Where a read-only guarantee matters more than convenience, the local server takes --read-only and a toolset list that bounds what registers at all.
The personal access token here is GitHub's own, and its scopes are the real limit on what the agent sees.
claude mcp add-json "github" '{"command":"github-mcp-server",
"args":["stdio","--read-only"],
"env":{"GITHUB_PERSONAL_ACCESS_TOKEN":"<your-token>",
"GITHUB_TOOLSETS":"repos,issues,pull_requests,actions"}}'GitLab, hosted
For teams already on GitLab the equivalent is a hosted endpoint on the GitLab API itself.
No credentials are written into the command. Authorization happens in the browser on first use.
claude mcp add --transport http GitLab \ https://gitlab.com/api/v4/mcp
Every other client
Each block below is the configuration for one client, with the file path and the key that client expects.
Keep Faros for the part it computes
The aggregate is the product. Delivery metrics joined across pipelines, reviews, incidents and tickets are what Faros exists to produce, and no source connector reproduces that.
This is guidance rather than configuration, so no credentials appear. Use the Faros API where an agent needs the computed view.
Sources -> MCP servers (reachable) Sources -> Faros aggregate -> agent (no route)
Read-only access, permissions and security
No Faros credential is created
With no server, nothing here asks for a Faros token or a wider Faros role.
The exposure moves to the sources, and widens
Connecting GitHub, GitLab and an incident tool separately grants more than a single aggregate connector would have.
Prefer
--read-onlyon the local GitHub serverIt is an explicit flag rather than a token convention, which makes the guarantee auditable.
Toolsets bound what registers
repos,issues,pull_requests,actionskeeps the tool list to the surfaces Faros actually ingests instead of everything GitHub exposes.Hosted routes keep tokens out of files
Both GitHub's and GitLab's hosted endpoints authorize in the browser, leaving nothing long-lived on a laptop.
Source data is broad
Commits, reviews and tickets carry names, timings and internal discussion, and that reaches the model in full once connected.
Troubleshooting
- You cannot find a Faros AI MCP server
- There is not one. The
faros-aiorganization holds 33 public repositories and none is MCP-related, and the official registry has no entry. - The documentation site is live, so a server page should exist
- Both
faros.aianddocs.faros.aireturned HTTP 200 on 1 September 2026, and neither documents an MCP server. Live documentation is not evidence of a connector. - The sources Faros aggregates all have servers, so its own view should be reachable
- They do, and that is the odd shape of this gap. Faros AI aggregates CI, source control, incident and project data, most of which publish servers of their own.
- Connecting those sources gets you the inputs. It does not get you the aggregate Faros computed from them.
- You need Faros metrics inside an agent conversation
- Use the Faros API with the agent's HTTP access, or connect the underlying source systems and accept that the agent recomputes rather than reads.
Faros AI MCP server: Reference
| Item | Value |
|---|---|
| Server published | None |
Public repositories in faros-ai | 33 |
MCP repositories in faros-ai | 0 |
faros.ai HTTP status | 200 on 1 September 2026 |
docs.faros.ai HTTP status | 200 on 1 September 2026 |
| MCP documentation found | None on either domain |
| Official MCP registry results | None |
| What is unreachable | The aggregate view across CI, source control, incident and project data |
| Checked | 1 September 2026 |
What engineers report
The searches cover the organization and both live sites, since the vendor is active and the absence could be recent.
| What was checked | What it shows |
|---|---|
Public repositories in faros-ai | 33 |
MCP repositories in faros-ai | 0 |
faros.ai HTTP status | 200 on 1 September 2026 |
docs.faros.ai HTTP status | 200 on 1 September 2026 |
| Official MCP registry results | None |
The faros-ai GitHub organization was searched for MCP repositories on 1 September 2026 and returned zero across 33 public repositories. Both faros.ai and docs.faros.ai returned HTTP 200 on the same date. The official MCP registry has no Faros AI entry.
Should you connect an agent to Faros AI?
No. There is nothing to connect. Best for connecting the source systems directly for anything that does not need the join.
- Strongest fit
- Teams who want the cross-tool delivery model and will read it in the interface.
- Main advantage
- Most of the systems Faros ingests publish their own servers, so the inputs are reachable even though the aggregate is not.
- Main weakness
- The joined view across tools, which is the product, cannot be queried by an agent.
- Operational risk
- Connecting the sources separately grants more than one aggregate connector would, and the agent must join them itself.
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 Faros AI have an MCP server?
No. On 1 September 2026, Faros AI's 33 public GitHub repositories had no MCP work and the official registry had no Faros entry.
Is the vendor still active?
Yes. Both faros.ai and docs.faros.ai resolved and returned HTTP 200 on 1 September 2026.
What should an agent connect instead?
The systems Faros AI ingests from. GitHub, Jenkins, CircleCI, Harness, PagerDuty, Rootly and incident.io all publish maintained servers.
Can an agent compute the same metrics?
Most of them. Deployment frequency, lead time and failure rate can be derived from CI, repository and incident connectors, without the cross-team model Faros AI adds.
