osFoundry / Platform
MCP server fleet
Install MCP servers per workspace. Tools from GitHub, Figma, Postgres — addressable from any agent.
What it is
MCP server fleet is how osFoundry manages Model Context Protocol (MCP) servers across a workspace. Instead of wiring one tool integration into one agent, you install an MCP server once and its tools become available to every agent, chat, and pipeline in that workspace. Install from the official MCP registry (registry.modelcontextprotocol.io) by search, add a remote server by HTTPS URL, or run a local stdio server by command. GitHub, Figma, Postgres and any other MCP-compatible server all land in the same place and speak the same protocol.
Inside osFoundry, servers come in two scopes. Admins install workspace servers that everyone shares; individual members add personal servers that stay private to their account (they cannot be promoted to workspace-wide without an admin). Each server's tools are namespaced (for example mcp__github__create_issue) so two servers never collide, and the underlying server name still reaches the model through each tool's description. Local servers run as child processes on your own machine and their secrets live in the OS keychain, never in a transcript or on osFoundry's servers. Remote servers connect over HTTPS with OAuth or header auth. Because osFoundry is BYOK and local-first, you point servers at your own credentials and data, and a local stdio server keeps that data on your device.
Tools are opt-in per chat rather than on by default. When you enable a server's tools for a conversation, agents can call them, and write-capable calls are approval-gated so a tool never runs an action without your consent. You can set up several servers in one workspace and enable different subsets per chat, which keeps each agent's tool surface focused instead of drowning it in every capability at once. Remote MCP setup and connection testing work on the web; running local stdio servers and enabling tools for chat is a desktop capability, since that is where the BYOK runtime and child processes live.
Key capabilities
- Install MCP servers from the official registry by search, by remote HTTPS URL, or by local command — one flow for GitHub, Figma, Postgres and any MCP server
- Workspace servers shared by admins plus private personal servers per member, each with namespaced tools so names never collide
- Every installed server's tools are addressable from any agent, chat, or pipeline in the workspace — install once, use everywhere
- Local stdio servers run on your own machine with credentials in the OS keychain; remote servers connect over HTTPS with OAuth or header auth
- Tools are opt-in per chat and write actions are approval-gated, so an agent never calls a tool without your explicit consent
Use cases
- Platform engineer: install a Postgres MCP server pointed at your own database so agents can query schema and run reports without exporting data off your machine
- Product designer: connect Figma via a remote MCP server once and let any chat pull frame and component context into design and spec work
- Engineering team lead: add a workspace-wide GitHub server so every agent can open issues and read PRs, while keeping write calls behind an approval prompt
Frequently asked questions
Do I install an MCP server for each agent or once per workspace?
Once. You install an MCP server at the workspace level (admins) or as a personal server (any member), and its tools become addressable from every agent and chat. You still choose which servers' tools to enable per conversation, so each agent gets a focused tool set rather than all of them.
Which MCP servers can I add — only well-known ones like GitHub and Figma?
Any Model Context Protocol server. osFoundry lets you search the official registry (registry.modelcontextprotocol.io), add a remote server by its HTTPS URL, or run a local stdio server by command. GitHub, Figma and Postgres are common examples, but anything that speaks MCP works the same way.
Where do my credentials and data go when I connect a server?
For local stdio servers, secrets are stored in your OS keychain and the process runs on your own machine, so data can stay on your device — consistent with osFoundry being BYOK and local-first. Remote servers connect over HTTPS with OAuth or header auth. Secret values are never written into chat transcripts.