Habitat's is bringing the affordances of atproto to organizations. With atproto, users access to all their personal data through a single identity and with Habitat, users can access all the data across their organization in one place. One of the many benefits of this model is that agents now have a single data repository they can navigate for context.
However, existing organizations don't currently have all their data in atproto repos tied to identity. Existing organizational data sits across SaaS apps, emails, and files. For a member of an organization to reference data from an agent, they need to wrangle all these different data sources each with their own identity and bespoke access controls.
This week, we're taking the first steps towards bridging that gap. In order to make Habitat the single entry point to your organization's data, we need link it to your existing identities across other SaaS apps. As a proof of concept for this, with developed an MCP gateway.
There are many examples of existing services that offer similar functionality (Cloudflare, Composio). Basically, an MCP Gateway merges multiple MCP server connections into one so a user only needs to authenticate once on the server, rather than once per MCP client.
The motivation behind this is that in Habitat, your organization's data server is the central access point to atproto data but what if we also made it the central access point to all types of data! We added support for an organization admin to connect MCP servers that all members of the organization now get to use. For MCPs that require their own authorization, each user signs in Habitat's portal. After that, they have access to that MCP from any client they connect to Habitat, with their atproto identity.
Since we're always trying to maintain portability, the MCP server config is just a record that members of the organization access.
So how do MCP clients connect to Habitat? Though MCP supports OAuth, it has its own idiosyncrasies that makes it incompatible with atproto OAuth directly. While atproto uses draft-parecki-oauth-client-id-metadata-document, MCP uses dynamic client registration. While atproto uses the PDS service in a DID for resource server discovery, MCP uses the WWW-Authenticate response header.
To resolve these discrepancies, we added new OAuth resource and authorization endpoints to https://pear.habitat.network/mcp so that MCP clients can connect to it. You can try this out in any agent with MCP capabilities.
Here's the exciting part though: while we need slightly different entry points between the two OAuth flavors, they can still issue the same type of token. This means that apps built on Habitat can use their existing user credentials to now access MCP servers that are already authenticated for a user! For example, our collaborative document editor https://chalk.habitat.network could start providing suggestions that are backed by the collective knowledge of all MCP connections that organization is connected to.
In the future, we can extend account linking beyond MCP and let Habitat be a proxy directly to external SaaS APIs. An example of this would be Chalk getting access to Google Calendar to link meeting notes.
Through this proxy model, every app built on Habitat can access data from external SaaS apps as well, similar to how in atproto any app can request access to any collection (solving the data cold-start problem). We believe the next generation of collaboration requires breaking down data silos across apps and are excited to continue exploring ways to do that and bridge to existing user experiences today.
You can play around with the MCP Gateway at https://home.habitat.network/opensocial by creating an organization and navigating to its MCP servers tab.
We'd love to hear your thoughts and ideas on connecting atproto to existing systems on our Discord!
-Habitat team