Dawn now ships MCP Gateway: a way to bring any hosted MCP server into your workspace as a real integration. Owners and managers connect the server from Dawn Web, choose which of its capabilities to expose, and assign them to specific agents — the same way they would assign GitHub or Jira. The agent uses those tools in the same conversation where it already uses memory pages, connected sources, files, background tasks, and the rest of the workspace.
The framing is deliberate. Dawn has always been opinionated about which integrations we build natively, and that does not change. GitHub, GitLab, Bitbucket, Azure DevOps, Jira, Linear, Trello, Google Drive, OneDrive, Confluence and Notion, and Figma and Framer all have first-class setups, provider-specific UX, source browsing, and the kind of details a generic protocol cannot quite match. Those stay the recommended path for the tools they cover. MCP Gateway is the answer for everything else.
Native Integrations Stay the Default
There is a real reason Dawn invests in curated integrations rather than treating every connector as a generic adapter. A first-party integration knows the shape of the provider it is talking to. It can browse the actual repos, render the right ticket fields, present permissions in the way the workspace owner expects, and behave well in the edge cases that matter for that specific tool. None of that comes for free over a generic protocol.
If Dawn already has a curated integration for the system you want to connect, use it. The setup will be smoother, the agent will have richer context, and the experience inside the Dawn UI will feel like a part of the product rather than a generic plumbing surface. We will keep adding native integrations for the systems where it makes sense to.
What native integrations cannot do — and were never going to do well — is cover the long tail. Internal services, specialist databases, customer-specific tooling, the operations dashboard the platform team built last quarter, the homegrown approval workflow that lives in one team only. Those are real systems with real value, and there is no realistic path where Dawn ships a first-party integration for each of them.
MCP Gateway, for Everything Else
MCP Gateway is the bridge for those systems. If your team has, or wants to build, a remote MCP server for an internal tool, you can now plug it into Dawn as a workspace integration.
A support team might expose a customer-health lookup tool. A platform team might expose deployment, incident, or runbook tools. A data team might expose a read-only metrics server. An internal operations team might expose workflow tools that would never make sense as a public SaaS connector. Once any of those are connected through MCP Gateway, the capability becomes part of the workspace — discoverable, assignable, and usable in the same agent conversations that already lean on memory pages and connected sources.
It is also for the growing public MCP server ecosystem. A lot of SaaS providers and API platforms now ship official MCP servers — Stripe for payments and billing, Google Maps for geocoding and place lookups, Sentry for errors, Twilio for messaging, HubSpot and Salesforce for CRM, Cloudflare for infrastructure, PostHog for product analytics, plus a long tail of smaller public APIs. Any of those that your team uses can be wired into Dawn through MCP Gateway as long as it speaks hosted MCP. If we have a curated integration for the same provider, that one is still the recommended path; if we do not, Gateway is the way in.
The important shift is not that Dawn understands another protocol. It is that the long tail of useful systems — internal services your team built, and public APIs you happen to depend on — can finally show up inside the agent workflow your team already uses, instead of forcing people to switch surfaces whenever a custom tool is involved.
Choose What Each Agent Can Use
Connecting an MCP server does not automatically hand every agent every capability the server exposes.
After the connection validates, Dawn shows the capabilities the server advertises. Owners and managers link the useful ones, then assign them to the agents that should actually have them. A planning agent might get the read-only project metrics tool. A support agent might get the customer-lookup tool. A release agent might get deployment status. The agent that should not need a particular tool simply does not get it.
That keeps the model close to how teams already think about agents in Dawn. Each agent gets the context and tools it needs for its job, not a blanket connection to every system in the workspace. It is also how the boundary stays useful: a tightly-scoped agent is easier to trust, easier to debug, and easier to share with teammates.
Write-capable tools are treated more carefully than read-only ones. Dawn classifies MCP capabilities and keeps write actions behind agent policy, so most teams will start with read-only workflows and opt into writes deliberately as they build confidence.
Hosted Endpoints, Real Auth, Real Boundaries
MCP Gateway supports hosted HTTPS MCP servers. It is not a local command runner. For this release, Dawn does not run local stdio MCP servers on a user’s machine or inside the Dawn cloud environment — if your team wants Dawn to use an internal MCP server, that server should be hosted behind an approved HTTPS endpoint.
The common ways teams protect those servers are supported out of the box: bearer tokens, static headers, and MCP OAuth for servers that advertise the right metadata. Credentials live with the connection, not with the user prompts. Agents do not see the secrets as conversation text; users do not paste tokens into chat to make a request work.
The same model that applies to Dawn’s native integrations — owner-and-manager-managed credentials, agent-scoped access, and connection lifecycle handled in Dawn Web — applies to MCP Gateway connections too. There is one place to look at what is connected, who can use it, and which agent it is wired to.
The Other Half of Our MCP Story
Dawn already had one MCP capability. Earlier this spring, Dawn MCP in Codex, Cursor, and Copilot made Dawn available as an MCP server, so coding agents could call into it. That is the inbound direction: an external client reaches Dawn.
MCP Gateway is the outbound direction. Dawn now reaches out to remote MCP servers and brings their capabilities into agents. The two together close the loop — Dawn can be an MCP server when other agents need its workspace context, and Dawn can be an MCP client when your team has tools that should show up in its workflows.
The everyday consequence of the outbound side is small but real. A product manager in Dawn Web does not need to know which separate MCP client can reach which internal service. A support lead in Slack does not need to switch into a developer tool to ask for customer context. If the right MCP capability is wired to the right agent, the user stays in the Dawn conversation and asks for the outcome:
Check the customer health score, summarise recent incidents, and draft a renewal-risk note.Pull this customer's Stripe payment history and flag anything unusual in the last quarter.Look up recent Sentry errors for the auth service and summarise what is failing.Find the three closest cafés to our London office with WiFi using Google Maps, and pick the one with the best reviews.Use the internal metrics source to compare this week's queue time with last month.The user asks in normal language. Dawn decides whether the assigned MCP capability is relevant, calls it when allowed, and returns the answer in the thread.
Connecting Through Dawn Web
The setup lives in the Integrations flow in Dawn Web, in the same place owners already manage GitHub, Jira, and the rest. Add a connection, choose MCP Gateway, enter the hosted MCP endpoint, pick the authentication method, and validate. Dawn shows the capabilities the server advertised; the workspace links the ones it wants and assigns them to the agents that need them.
There is no separate admin surface and no second model to learn. MCP Gateway connections sit alongside native integrations and obey the same rules — same role boundaries, same per-agent assignment, same lifecycle. The only difference is that the connection on the other end of the wire is your team’s own MCP server instead of a curated provider.
What This Release Does Not Include Yet
Worth being explicit about what this first release is, and is not.
It supports hosted HTTPS MCP servers as workspace integrations, with the credential and assignment model described above. It does not include personal MCP connections that follow a single user across workspaces, local stdio servers run on a developer’s machine, or interactive MCP Apps rendered inside Dawn. Those are interesting capabilities and we have an active spec for them, but they are not part of this release.
This release also does not replace Dawn’s native integrations. Those remain first-class and remain the recommended path for any system Dawn already covers. The point of MCP Gateway is to widen the reachable surface without forcing every connector through the same generic shape.
Getting Started
Owners and managers can open Dawn Web, go to Integrations, and pick MCP Gateway. Point it at the hosted endpoint of your MCP server, choose how the server expects to be authenticated, validate, and then link the capabilities you actually want in the workspace. From there it is the same flow as any other integration — assign capabilities to the agents that should have them, and use them in the same conversations the team already runs.
If you have an internal system that has been just out of reach for the agent until now, MCP Gateway is the path. The native integrations stay the right answer for the tools we cover. For everything else, you can now bring it in.