Supported MCPs
Lander mirrors MCP at the transport layer, so it can proxy any standard MCP server an agent is configured with: stdio servers spawned locally, and http/sse servers reached through mcp-remote. There is no per-server integration to write.
So the useful question is not “is my server on the list?” but what a server’s transport, auth model, and hosting imply about what you get from it. That is what this page answers. For the agents on the other side of these connections, see Supported Agents.
Transports
Section titled “Transports”| Transport | Description |
|---|---|
stdio |
The agent spawns the MCP server as a subprocess (JSON-RPC over stdin/stdout) |
http |
The agent connects to a long-lived MCP server over HTTP streaming |
sse |
Server-Sent Events streaming, used by some remote MCP servers |
When a server is mirrored, Lander injects the calling agent’s identity so events can be attributed per agent — the LANDER_AGENT_ID environment variable for stdio, the X-Lander-Agent header for HTTP and SSE.
What to expect from a given server
Section titled “What to expect from a given server”Install, tool-level permissions, tool-call events, and payload capture are available for every standard MCP server — every transport, every hosting model, every auth type the catalog supports. There is no server shape that forfeits one of them, which is why there is no per-server support table to look yourself up in.
What varies is not whether you get them but how the traffic is wired to reach them, and that comes down to two decisions:
- Routing — proxied or direct. This is the on/off switch for everything except inventory.
- Which proxy path — chosen automatically from the server’s own transport. It doesn’t remove capabilities; it changes three specific behaviors, one of which matters for enforcement.
Transport and hosting decide the path. Auth decides where the credential lives, and nothing else.
Routing is the switch
Section titled “Routing is the switch”| Proxied | Direct | |
|---|---|---|
| Discovered and inventoried | ✅ | ✅ |
tools/call allow / deny |
✅ | ❌ |
tools/list filtering |
✅ | ❌ |
| Tool-call events | ✅ | ❌ |
| Payload capture | ✅ | ❌ |
| Where the credential lives | Lander’s config | the agent’s own config file |
Direct isn’t a degraded install — it’s a server Lander knows about but doesn’t sit in front of, so there is no interposition point to enforce or record from. Install proxied for anything that needs a policy applied or a call recorded.
The path follows the server’s transport
Section titled “The path follows the server’s transport”You don’t choose this; the install does, matching the proxy’s transport to the server’s own so that OAuth endpoints keep working.
| Server | Path | What lands in the agent’s config |
|---|---|---|
stdio |
stdio proxy — Lander spawns the real command as a subprocess | lander serve-stdio --proxy <name> |
http / sse |
HTTP proxy — Lander reverse-proxies to the upstream | mcp-remote http://localhost:8082/stream/proxy/<name> |
http / sse on Claude Desktop |
stdio proxy, bridging to the remote endpoint over streamable HTTP | lander serve-stdio --proxy <name> |
The third row is why hosting and transport aren’t independent: Claude Desktop’s config takes stdio entries only, so a remote server there is bridged rather than reverse-proxied, and it picks up the stdio path’s behavior instead of the HTTP path’s.
What the path changes
Section titled “What the path changes”| stdio proxy | HTTP proxy | |
|---|---|---|
tools/call gate |
Request-side — always applies | Request-side — always applies |
tools/list filtering |
Always applies | Plain-JSON responses only — an SSE-framed listing passes through unfiltered |
| Session identity on events | Synthetic, one per proxy process | The client’s real Mcp-Session-Id |
| OAuth 2.0 upstreams | — | Discovery forwarded; browser flow runs direct to the upstream |
The filtering row is the one to plan around. Both paths refuse a disallowed tools/call, because that gate runs on the request before anything is forwarded — enforcement is never silently lost. But hiding a tool from tools/list is a response-side rewrite, and on the HTTP path it only happens when the upstream returns a plain JSON body. Streamable HTTP servers may frame responses as text/event-stream, in which case the model sees the tool, tries it, and gets refused.
If a tool must not be visible, leave it out of the catalog entry’s allowed tools rather than relying on the filter — that keeps it out of the listing at the source, on either path.
Auth: who holds the credential
Section titled “Auth: who holds the credential”| Auth model | Held by | Where it lives |
|---|---|---|
| None | — | — |
| Token or API key | The Connector, from a stored secret | Lander’s config; injected on the upstream leg only, where configured values beat anything the agent sends |
| OAuth 2.0 | The end user | Nowhere in the Connector — registration, authorize, and token all run directly between the agent and the upstream |
Proxied routing is what keeps credentials out of the agent’s config: the entry there only ever points at Lander, and the real command, environment, and headers stay in Lander’s own config. Route direct and the resolved secret is written into the agent’s file — as an env value for stdio, a headers value for http/sse.
Two consequences worth knowing. A catalog entry can record an auth type of none and still be an OAuth-protected server: that field records whether the Connector holds a credential, not which protocol the server speaks. And OAuth needs an HTTP layer, so it never applies to a local stdio server.
The catalog also accepts token exchange, AWS SigV4, and passthrough variants. Those paths are wired but not yet exercised end to end — untested, not unsupported, and not to be read as either working or broken.
Recognized in the registry
Section titled “Recognized in the registry”The servers below are known to the control plane’s known-MCP registry, which enriches a discovered server with a friendly description and its expected tools instead of showing a bare name.
Registry recognition is naming and enrichment — it is not a verification claim. Any of these should proxy like any other standard MCP server, and an unrecognized server still proxies fine; it just displays under its raw name. What a given server actually gives you follows from its transport, hosting, and auth, not from whether it appears here.
Dev tools and code
Section titled “Dev tools and code”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| GitHub | GitHub | Remote | http / sse |
| GitLab | GitLab / community | Remote / local | stdio, http |
| Filesystem | Anthropic | Local | stdio |
| Git | Anthropic | Local | stdio |
| Atlassian (Jira / Confluence) | Atlassian (Rovo) | Remote | http / sse |
| Linear | Linear | Remote | http / sse |
| Sentry | Sentry | Remote | http / sse |
| Playwright / Puppeteer | Microsoft / community | Local | stdio |
| Postgres / SQLite | Anthropic + community | Local / remote | stdio, http |
| Docker Hub | Docker | Remote | http |
| Cloudflare | Cloudflare | Remote | http / sse |
| Vercel | Vercel | Remote | http |
| Supabase | Supabase | Remote | http |
| Neon | Neon | Remote | http |
| Context7 | Upstash | Remote | http / sse |
Communication and productivity
Section titled “Communication and productivity”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| Slack | Slack | Remote | http |
| Notion | Notion | Remote | http / sse |
| Google Workspace (Drive/Gmail/Calendar/Sheets) | Google / community | Remote / local | stdio, http |
| Confluence | Atlassian | Remote | http |
| Microsoft 365 / Teams | Microsoft / community | Remote / local | stdio, http |
| Box | Box | Remote | http |
| Obsidian | Community | Local | stdio |
CRM, sales and business apps
Section titled “CRM, sales and business apps”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| Salesforce | Salesforce | Remote | http |
| HubSpot | HubSpot | Remote | http |
| Clay | Clay | Remote | http / sse |
| Apollo | Apollo | Remote | http / sse |
| Close | Close | Remote | http |
| Airtable | Airtable | Remote | http |
| Asana | Asana | Remote | http |
| Monday.com | Monday | Remote | http |
| Stripe | Stripe | Remote | http |
Search, web and data
Section titled “Search, web and data”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| Brave Search | Brave | Local / remote | stdio, http |
| Exa / Tavily | Exa / Tavily | Remote | http |
| Firecrawl | Firecrawl | Remote | http |
| Ahrefs | Ahrefs | Remote | http |
Memory, reasoning and analytics
Section titled “Memory, reasoning and analytics”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| Memory | Anthropic | Local | stdio |
| Sequential Thinking | Anthropic | Local | stdio |
| Mem0 / Letta / OpenMemory | Various | Local / remote | stdio, http |
| Amplitude | Amplitude | Remote | http |
| Hex | Hex | Remote | http |
| Figma (Dev Mode) | Figma | Local | stdio |
Aggregators and gateways
Section titled “Aggregators and gateways”| MCP server | Provider | Hosting | Transport(s) |
|---|---|---|---|
| Zapier MCP | Zapier | Remote | http / sse |
| Composio | Composio | Remote | http |
| MCP gateways (MCP Manager, Prisma, etc.) | Various | Remote / on-prem | http |
A gateway exposes many downstream apps behind one MCP endpoint — concentrated scope through a single connection. Lander mirrors an agent’s connection to a gateway like any other MCP, but note what that captures: the agent→gateway hop, not the gateway’s own fan-out to downstream apps. A gateway is itself a governance layer, and a peer to the Connector rather than something underneath it.
Adding a server to the catalog
Section titled “Adding a server to the catalog”Servers are added to the Connector’s catalog rather than to Lander — nothing in the endpoint agent needs to change to support a new one, because mirroring happens at the transport layer. A catalog entry carries the server’s endpoint and transport, its auth model, the tools it’s allowed to expose, which access groups may request it, and whether an install needs admin approval. From there it moves through the usual request → approve → install flow.