A developer or small team accumulates dozens of MCP servers and API integrations with no unified view of what's alive, what overlaps, and what's safe to cut. ATLAS is the top layer that visualizes, health-checks, and recommends against that sprawl.
If you're building with AI agents in 2026, you're probably running a dozen-plus MCP servers and a scattered handful of raw API integrations - Slack, GitHub, a couple of vector DBs, three different search tools someone added "just to try," an internal server nobody remembers deploying.
Nothing tells you which ones are actually alive. You find out a server is broken when an agent call silently times out mid-task, or when the model picks the wrong search tool because four of them have overlapping schemas eating your context window. Tool-selection accuracy has been shown to collapse from roughly 43% to 14% once a tool menu gets overloaded - and MCP's own spec has no mechanism to warn you when you've crossed that line. There's no dashboard, no map. You're reconstructing your own integration topology from memory, a stale README, and whichever config file you happen to be looking at.
This is the same "app sprawl" problem SaaS-management platforms solved for enterprise software licenses several years ago - except nobody has built the equivalent for the tool layer agents actually call. It isn't hypothetical scale; it's the default state of anyone who's been adding MCP servers for more than a few months.
Individual developers and small teams (roughly 2-15 people) building agent-driven products who have accumulated MCP servers and API integrations organically. Not enterprises with a dedicated platform team - that's the gateway vendors' turf - and not people with two or three tools who don't feel the pain yet. The buyer already edits a .mcp.json file by hand and wants relief from self-managed spreadsheet-and-README tracking, not a governance mandate handed down from above.
ATLAS is an integration top-layer that sits across your existing MCP servers and APIs - not a replacement for any of them - and gives you three things nothing else on the market currently combines.
A live map of every MCP server, tool, and API integration you actually have, grouped by server with drill-down into individual tools, sized by real usage so redundant capability - four different search tools, say - is visually obvious.
Continuous liveness and capability-drift monitoring, shown as a small, honest status vocabulary - Healthy / Warning / Critical / Offline, plus a separate Idle tag for unused-but-reachable tools - never a raw metrics firehose.
A tiered engine that looks at overlap, staleness, and (once you opt in) usage to suggest concrete actions: consolidate these two, this hasn't been touched in 60 days, this server duplicates a tool you already have.
What Zylo and Productiv did for redundant SaaS licenses, applied to the MCP and API tools your agents actually call.
tools/list, ping) in the 2025-11-25 spec, but explicitly left telemetry, health aggregation, and multi-server orchestration to be built by someone else - that's a real, buildable product opportunity, not a protocol gap waiting to close on its own.Being direct about the landscape, since none of this is a strawman.
| Category | What they do | What they don't |
|---|---|---|
| MCP registries & dev tools Inspector, Smithery, Glama, PulseMCP, mcp-get | Catalog and let you test one server at a time. | No live graph of your actual running deployment. No recommendations. ATLAS starts where they stop - after install, not while browsing a directory. |
| MCP gateways Composio, Klavis, MintMCP, Kong, Lunar MCPX, MCP Manager, Portkey | Auth, routing, and - several of them - genuine health/latency/usage dashboards. | None render connection topology as a graph or generate consolidation recommendations. They're enterprise auth/routing plays; ATLAS is a layer on top of your existing connections, not a proxy you route production traffic through by default. |
| General API tools Postman, Kong Gateway, n8n, Retool | Visualize or health-check individual collections/workflows in isolation. | None treat your integration set as a portfolio to optimize as a whole - that framing is the actual product. |
| SaaS management platforms Zylo, Productiv, Torii | Tag apps by usage/category, flag redundant or dormant, suggest consolidation - the closest conceptual analog for ATLAS's recommendation logic. | Operate on procurement and login data for human-facing apps, with zero visibility into MCP tool schemas or agent tool-call telemetry. |
The honest gap: nobody has merged live topology visualization, continuous health checking, and portfolio-level recommendations into one thing for MCP specifically. Each existing tool does at most one of the three. The nearest-term threat is that a gateway incumbent ships a graph view and calls it done - they already have the harder-to-build half, the telemetry pipeline. ATLAS's defensibility has to be the visualization/recommendation UX and the lightweight, no-lock-in positioning, not the underlying monitoring plumbing, which is catchable.
One source of truth every other section is written to match, so architecture never quietly drifts ahead of what actually ships first.
| Capability | v1 | Phase 2+ |
|---|---|---|
| Connection types | MCP servers only | Raw REST/GraphQL API keys folded into the same graph, per the founder's original "MCP + API" framing |
| Discovery | Local config-file scan (.mcp.json, Claude Desktop, Cursor, VS Code) + manual add | Git-backed or hosted team registry sync |
| Health checks | Tier 0 (ping liveness) + Tier 1 (capability-list drift) | Tier 2 (synthetic canary calls) + Tier 3 (real-traffic health) |
| Telemetry | None by default (read-only). Optional proxy mode, opt-in, unlocks call-level usage/latency | OpenTelemetry trace-context correlation for already-instrumented servers |
| Recommendation engine | Tier 1 only: rule-based, schema/name-fingerprint overlap + reachability + capability-drift flags | Tier 2: LLM-driven semantic overlap, co-usage pattern analysis, gap suggestions |
| Visualization | Full graph view, drill-down, aggregate status strip, idle-node collapsing | Inferred co-usage edges (toggle-off by default even then) |
| Team / multi-user | Single developer, local-only | Team workspace, shared registry, per-user token auth, audit log |
| Write actions | None - read-only observation only | One-click disable/remove a flagged server, config diffing, rollback |
| Deployment | Single local process, embedded SQLite | Docker Compose / Kubernetes team-hosted stack (Postgres, Prometheus, OTel Collector) |
ATLAS does not extend the MCP protocol - it can't, since the protocol has no multi-server, telemetry, or health-check primitives beyond a bare liveness ping. So ATLAS is architected as an independent orchestrator that holds one live MCP client session per registered server and builds everything a fleet-management tool needs - usage metrics, health rollups, recommendations - on top of that.
Solid nodes ship in v1. Dashed nodes are Phase 2+ or opt-in. The Orchestrator and Health-Check Engine are the only components that touch live MCP sessions; everything downstream - store, rules, UI - is infrastructure ATLAS must build itself, because none of it exists in the protocol.
The registry is the source of truth for "what's connected." In v1 it holds MCP servers only, discovered two ways:
claude_desktop_config.json, Claude Code's .mcp.json, Cursor's mcp.json, VS Code MCP settings) and parses command/args/env for stdio-transport servers or url for HTTP/SSE and streamable-HTTP servers. This is the zero-effort onboarding path - run atlas scan and every server already wired into your tools shows up.The env block of a stdio server definition is exactly where raw API keys usually live. Config scanning must pattern-detect secret-shaped values (bearer tokens, API-key formats, high-entropy strings) and refuse to persist them verbatim: a detected secret is replaced with an auth_ref pointer into the OS keychain and the user is prompted to confirm the move. The registry never stores a raw credential - only a reference - regardless of how the connection was discovered.
Both scanned and manually-added connections are fingerprinted by their underlying command or URL, not by display name, so the same physical server registered through two different client configs collapses into one registry entry instead of surfacing as a false "possible duplicate" recommendation. Once registered, ATLAS performs the standard initialize handshake and walks tools/list, resources/list, prompts/list with cursor pagination to build a capability snapshot. Where a server declares a listChanged flag, ATLAS subscribes to push notifications as the primary refresh trigger, falling back to polling only where that flag is absent. Every snapshot is versioned and diffed against the last one to catch schema drift and added/removed tools.
This is deliberately conservative about what MCP actually gives us. The only standardized liveness primitive in the current spec is ping - a bare round trip that proves the transport is alive, nothing more. There's no readiness endpoint, no status taxonomy, no aggregate health payload. Everything past "is the channel alive" is ATLAS's to build:
| Tier | Mechanism | What it proves | Ships in |
|---|---|---|---|
| 0 | Configurable-interval ping | The JSON-RPC channel is alive | v1 |
| 1 | tools/list / resources/list / prompts/list, diffed against the last snapshot | Declared surface hasn't silently drifted | v1 |
| 2 | Owner-allowlisted synthetic canary calls on a schedule | The tool actually works, not just that the server responds | Phase 2+ |
| 3 | Rolling success-rate and latency percentiles from real proxied traffic | How the tool performs under real use | Phase 2+, opt-in |
A fixed four-state model, chosen because a small fixed vocabulary is what makes rollup-and-propagate (worst-child-state-wins-at-parent) tractable across dozens of nodes. Every state renders as color and icon and text label together, never color alone. A fifth, separate tag - Idle - means zero observed invocations in the lookback window; it is a usage signal, not a failure signal, and must never be visually conflated with Critical or Offline. In v1, without proxy mode, "usage" for the Idle tag is inferred conservatively from capability-list presence and check-recency, not true call volume - the UI says so explicitly rather than implying a fidelity it doesn't have yet.
MCP has no native metrics surface - no call counts, no latency, no error rates. The closest native facility, the logging capability, is being formally deprecated in the July 2026 spec revision specifically because "standard logging mechanisms (stderr, OpenTelemetry) are... better suited to observability than an application-protocol channel." Its replacement isn't a new MCP telemetry primitive - it's a convention (SEP-414) for propagating W3C trace context inside the generic _meta field so an already-OTel-instrumented system can correlate spans. In other words: the protocol's own design direction confirms that usage aggregation must be built by a client or proxy layer, not read off the wire.
v1 default is read-only - no proxy, no interception, zero adoption friction, and no telemetry beyond capability-list presence and ping/list check history. Proxy mode is an explicit opt-in upgrade: once enabled, ATLAS's Orchestrator - already an MCP client for every registered server - intercepts each tools/call, resources/read, and prompts/get it issues, timestamps dispatch and response, classifies the outcome, and emits a UsageEvent. This is the only way to get real call-frequency and latency data, and it only sees traffic that actually flows through ATLAS.
A usage-based "no calls in 60 days → candidate for removal" rule only works in proxy mode. Since proxy mode is opt-in and off by default, v1's equivalent default-mode rule is weaker and says so: a connection is flagged Idle when it has produced no capability-list changes and shown up in no manual interaction for the lookback window - a reachability/staleness proxy, not a true usage signal. The stronger, usage-accurate version of this rule is explicitly gated behind proxy-mode opt-in and labeled as such in the UI.
Call arguments are redacted or hashed by default with configurable field-level exclusion; raw payloads never leave local storage.
At ATLAS's actual scale - dozens to low hundreds of servers/tools - the problem isn't rendering technology, it's aggregation discipline. That range sits comfortably within the band where force-directed layout stays legible, so the design leans on grouping and drill-down rather than exotic layout algorithms:
18 Healthy | 3 Warning | 1 Critical | 4 Offline | 6 Idle - the whole-portfolio answer before anyone touches the graph.No existing tool merges gateway observability with SaaS-management-style consolidation advice, and recommendations are split into two tiers with visibly different confidence because they come from fundamentally different kinds of evidence:
| Tier | Signal | Recommendation | Ships in |
|---|---|---|---|
| 1 | Identical tool name + near-identical input schema on ≥2 servers | Candidate for consolidation | v1 |
| 1 | Sustained Critical/Offline health | Fix or remove | v1 |
| 1 | Capability snapshot diverges from last-known schema | Needs review | v1 |
| 1 | No real calls in N days (requires proxy mode) | Candidate for removal | opt-in / P2+ |
| 2 | Semantically similar but differently-named/described tools | Possible consolidation, shown with rationale + similarity score | Phase 2+ |
| 2 | Repeated multi-hop call sequences across servers | Possible workflow simplification | Phase 2+ |
Tier 1 is cheap, reproducible, and explainable - computed facts, not judgments. Tier 2 output always carries a confidence score and cites its evidence, and is visually distinguished from Tier 1 in the UI. Nothing in either tier auto-executes - a wrong "remove this" suggestion that breaks a workflow is far worse for trust than a missed one, so recommendations stay advisory, requiring explicit accept or dismiss, for a long time.
| Entity | Core fields | Ships in |
|---|---|---|
| Connection | type(mcp), transport, endpoint_or_command, protocol_version, auth_ref, fingerprint_hash, category_tags[], status, source | v1 |
| CapabilitySnapshot | connection_id, captured_at, tools[], resources[], prompts[], snapshot_hash | v1 |
| HealthCheckResult | connection_id, check_type, timestamp, status, latency_ms | v1 (tiers 0-1) |
| OverlapCluster | tool_ids[], similarity_score, method(exact), status | v1 (exact-match only) |
| Recommendation | type, target_connection_ids[], tier, rationale, status | v1 |
| UsageEvent | connection_id, tool_name, timestamp, latency_ms, success, trace_id | opt-in proxy |
| Connection.type = rest_api / graphql | - | Phase 2+ |
| Team, Workspace, User, AuditLog | Org boundary, per-user API tokens, action history | Phase 2+ |
v1 and Phase 2+ intentionally run different stacks - the "lightweight, no lock-in" positioning has to be true of the actual reference implementation, not just the pitch.
| Layer | v1 - single developer | Phase 2+ - team-hosted |
|---|---|---|
| Orchestrator core | Node.js/TypeScript + the official MCP TypeScript SDK, behind an internal ProtocolAdapter interface so the 2025-11-25 → July-2026 breaking change is isolated to one seam | |
| Storage | Embedded SQLite, single local process - matches the "run npx atlas" onboarding bar | Postgres for registry/metadata; ClickHouse if raw UsageEvent volume outgrows Postgres |
| Metrics | In-process rollups, no separate service | Prometheus, reusing the existing community "MCP Server Observability" Grafana dashboard as prior art |
| Telemetry ingest | None (or local-only proxy capture if opted in) | OpenTelemetry Collector (OTLP), correlating any server already propagating traceparent via _meta |
| Similarity/embeddings | Exact name/schema hash only | pgvector inside Postgres - thousands, not millions, of rows |
| Tier-2 reasoning | - | Claude, called during scheduled batch refresh jobs, not per-request, to control cost |
| Frontend graph | Cytoscape.js - mature compound/combo-node support, right-sized for hundreds (not millions) of nodes | |
| Deployment | Single binary / npx install | Docker Compose locally, same containers on Kubernetes for team-hosted mode |
| Secrets | OS keychain | OS keychain (local) or Vault/cloud KMS (hosted) - registry always stores a reference, never a raw credential |
Sitting in the call path is the only way to get real frequency, latency, and error data - the protocol exposes none of it any other way. But it means rewiring an agent's config to point at ATLAS, adds a hop of latency, and makes ATLAS a single point of failure for real traffic if it goes down. Partial adoption also produces misleading telemetry: a server that looks idle in ATLAS might just be bypassing it entirely.
ResolutionRead-only ships as the zero-friction v1 default; proxy mode is an explicit opt-in upgrade, not a global switch. When proxy mode is enabled, ATLAS fails open on its own outage - calls pass through untouched to the origin server rather than blocking - and the outage itself is logged as a Critical event for ATLAS's own health, never for the wrapped server's.
Local-only keeps call arguments, schemas, and credential references entirely on the developer's machine and works offline, but can't deliver a team-portfolio view - two teammates independently wiring up separate Notion MCP servers is only visible in aggregate. Cloud sync unlocks that but centralizes sensitive metadata into a hosted service that then needs its own access-control layer.
ResolutionLocal-only by default; Phase 2+ team sync is field-level opt-in for aggregate metrics and registry entries only - raw call payloads are never synced.
Rules are explainable, reproducible, and safe to weight heavily, but they're blind to the exact failure mode driving the tool-selection-accuracy collapse - semantically redundant tools with different names. LLM analysis catches that overlap but is probabilistic, and a confidently-wrong suggestion shown with the same visual weight as a factual one erodes trust fast.
ResolutionThe two-tier confidence model isn't polish, it's load-bearing - the tiers are never visually blended into one undifferentiated list, and Tier 2 is Phase 2+ only, after Tier 1 has a track record.
The current spec is final and already has everything v1 needs, so building now ships something usable immediately - but its stateful initialize/session-ID model is being removed in a revision finalizing roughly two weeks after this document. Waiting avoids that rework but means building against a spec with almost no real-world server implementations yet.
ResolutionBuild against 2025-11-25 now behind the ProtocolAdapter seam; track the new spec's adoption per-connection and treat migration as a scheduled follow-up, not a v1 blocker.
Canaries catch breakage in low-traffic-but-critical tools before an agent ever hits the failure - real-traffic error rate is statistically meaningless at low call volume. But they need someone to author a safe, idempotent probe per tool, and risk real side effects if defined carelessly against something like a send_email tool.
ResolutionReal-traffic health is the default wherever call volume is sufficient (Phase 2+); canaries are opt-in per connection and must be explicitly allowlisted as safe by the connection's owner.
Open-core. The local v1 tool ships free and open source - that's what makes it worth listing on the MCP registries (Smithery, Glama, PulseMCP) where developers already look for tooling, and it removes the trust hesitation of asking someone to point a proxy at closed-source infrastructure. Phase 2+ team sync, hosted deployment, and the LLM-driven recommendation tier are the paid surface, sold to the same small teams once they've outgrown single-developer use.
The open question is real, not rhetorical: the willingness-to-pay precedent (Zylo, Productiv, Torii) is enterprise procurement software sold to finance and IT buyers optimizing real license spend. It's untested whether an individual developer will pay for visibility into infrastructure that's otherwise free to run. The cheapest way to find out: a paid-beta waitlist alongside the v1 launch, priced against time-saved-per-incident rather than cost-saved, since there's no license spend to optimize away at this end of the market.
ProtocolAdapter seam contains it but doesn't eliminate it.Gated on signal from v1, not a fixed calendar date.