osFoundry / Platform
Connectors
A catalog of every integration the platform supports — first-party and community.
What it is
Connectors is osFoundry's single catalog of every integration the workspace can reach, spanning two kinds of thing: API connectors (an external HTTP API behind OAuth, API key, bearer, or basic auth) and MCP servers (Model Context Protocol tools that either run locally on your device or are hosted over HTTP). Instead of scattering integrations across separate settings pages, the browse screen groups everything by category — AI providers, productivity, communication, developer tools, storage, social, and MCP — with a live search over names, descriptions, and tags so you can find a capability the way you'd actually look for it.
Inside osFoundry the catalog is not a static list. The Discover panel searches the official MCP Registry from within the app, so "what I could add" sits right next to "what I have." You can type a query or paste a GitHub repository URL, and osFoundry resolves it to a structured, installable server (command, arguments, and required environment variables), rather than guessing from a README. Because registry publication is permissionless, each result shows its provenance: a verified-namespace badge tells you the publisher proved who they are (GitHub OAuth for io.github.* namespaces, or DNS/HTTP proof for a domain), which is exactly the signal you need to tell a first-party server from a typosquat before you install it. Cards mark whether a server runs on your device (stdio) or is hosted (HTTP), and whether it's already added.
This matters because osFoundry is bring-your-own-key and local-first. You connect your own accounts with your own credentials — there's no reseller markup — and secrets live in your OS keychain, never inside the connector definition or the context sent to a model. Once a connector is in place, agents and workspace apps use it through an admin-controlled, auditable proxy: apps run with no direct network access and call connector.call() so every outbound request is verified against the app's manifest and logged. Update detection flags when an installed registry server has a newer version, and never silently re-runs new code — a changed command or server URL asks for the same explicit consent the first install did.
Key capabilities
- Browse every integration in one catalog — API connectors and MCP servers, grouped by category (AI providers, productivity, communication, dev tools, storage, and more) with search across names, descriptions, and tags
- Discover community servers from the official MCP Registry (registry.modelcontextprotocol.io) directly inside the app, or paste a GitHub repo URL to resolve it to an installable server
- See who published a server before you install: a verification badge marks registry-verified namespaces (GitHub OAuth or DNS/HTTP proof) and distinguishes first-party from permissionless community entries
- Install local (device stdio) servers that run as a child process on your own machine, or hosted (HTTP) servers mediated by the platform — credentials stay in the OS keychain, never in the connector definition
- Connect your own accounts with your own keys (OAuth, API key, bearer, or basic) — no reseller markup — and let agents and apps call those tools through an admin-controlled, auditable connector proxy
Use cases
- Workspace admin: sets up a Twitter/X or Salesforce API connector once (base URL, OAuth scopes) so every app and agent in the workspace can call it through the proxy without each user wiring up credentials
- Developer/power user: pastes a GitHub URL for an MCP server, sees it's a verified io.github namespace, installs it as a local stdio server, and immediately calls its tools from chat
- Privacy-conscious team: keeps API keys in the OS keychain and runs device-local MCP servers so data and credentials never leave the machine, while still browsing community integrations in one catalog
Frequently asked questions
What's the difference between an API connector and an MCP server here?
An API connector wraps a specific external HTTP API behind an auth method (OAuth, API key, bearer, or basic) and is typically created once by a workspace admin, then called by apps and agents through the connector proxy. An MCP server exposes tools via the Model Context Protocol — it either runs locally as a child process on your device (stdio) or is reached over HTTP (hosted). Both show up in the same catalog, tagged API or MCP, so you browse them together.
Where do the community connectors come from, and are they safe?
The Discover panel searches the official MCP Registry (registry.modelcontextprotocol.io), which anyone can publish to. osFoundry shows a verification badge when the publisher's namespace is verified — GitHub OAuth for io.github.* names or DNS/HTTP proof for a domain. That proves who published a server, not that its code is safe, so you're expected to check the publisher before installing. Local servers run on your own machine and their required environment variables are shown up front.
Where are my credentials stored?
Secrets are never kept in the connector definition or sent to the model — the catalog only carries names of variables and headers, not their values. For local MCP servers, credentials live in your OS keychain. API-connector credentials are decrypted server-side only to build auth headers when the proxy makes a request on an app's behalf, and that request is verified against the app's manifest and auditable. This is consistent with osFoundry being bring-your-own-key and local-first.