Bring Your Own MCP Server

You have already decided what your systems expose to an agent, and you have probably already built the server that exposes it. The integration question here is not whether to rebuild that behind our connectors. It is which of your existing servers a given agent is allowed to see.

Servers are registered against your account rather than against a flow, and their tools are discovered live at registration, so you approve an actual tool list instead of a URL and a promise. Attachment is then per agent: a support agent and a sales agent can sit on the same account and see entirely different surfaces. Transport is remote MCP over HTTPS, the standard every hosted server already speaks.

Static headers cover an internal server behind a shared secret. OAuth2 client credentials cover a machine-to-machine grant, with the token cached and refreshed for you. A locally minted JWT covers a server that wants a signed assertion it can verify itself. OAuth2 authorization code, with redirect and refresh, covers the case where the grant belongs to a person rather than to the tenant.

This is usually the part of an evaluation that stalls, which is why all four are named here rather than left to a sales call: the mode your security review insists on is the one that decides whether any of the rest of this is available to you.

The MCP section goes further on all of this: which of the two directions you actually need, what happens at the connection boundary, and how authentication works for a server built for your own backend rather than for a third party.

Our own copilot has no privileged back door. Creating a flow, adding a stage, setting the examples that anchor a stage's behavior, writing an SOP, changing an agent setting, running a test conversation, reading back the transcripts afterwards: each one is an MCP tool call against the same surface everything else uses.

An agent here is a thing another agent can build. Design review, iteration and testing do not have to happen in a vendor UI, and the dashboard is one client of the platform rather than the platform itself.

Tool calls cover what the agent does mid-conversation. Everything around it stays ordinary: webhooks push events as they happen, and APIs handle controlled reads and writes, so escalations, transcripts and outcomes land in the systems your team already watches instead of in a console someone has to remember to open.

The Universal Commerce Protocol, launched by Google and Shopify in 2026 and backed by Etsy, Wayfair, Target, Walmart and more than twenty other partners, lets customers discover and buy products from inside assistants like ChatGPT, Gemini and Copilot without visiting a store's website.

That is the same idea as everything above, pointed outward: instead of your catalog being found by a search engine, it is made queryable and purchasable by an agent. For enterprise customers we already maintain a structured, enriched catalog, and exposing it as UCP is the short step from there. Relevant if you sell products; skip it if you do not.