Knowledge Integrations (MCP)

Knowledge integrations let you connect any remote MCP server to one of your applications — Zendesk, Notion, Confluence, GitHub, or your own internal server are all just examples; anything that speaks the Model Context Protocol works the same way. An org admin authorizes the connection once in the portal; from then on, every end-user chat and voice session for that application can use the provider's tools. Yak is the MCP client — you don't run an MCP server.

This is configured in the dashboard, not in code. It complements Tool Adapters (tools your own app exposes) — here the tools come from a third-party provider you connect to.

How it works

Org admin                          Provider's MCP server
   │  connect once (OAuth)                 │
   ▼                                       ▼
Yak (MCP client) ──── stored, encrypted ───┘
   │  used server-side
   ▼
End user on your site  →  chat / voice  →  provider's tools

The connection is owned by an application. Each application has its own credentials and its own tool settings — connecting Zendesk to your "Support" app does not expose it to any other app, and one org's connections are never visible to another.

Connecting a server

In the dashboard, open your application and go to the Integrations tab.
Click Add MCP server, give it a name, and paste the server's URL (for example https://mcp.example.com/mcp).
Click Connect. You're redirected to the provider to authorize access, then back to Yak. The connection shows as Connected once tools have been discovered.

Only organization admins or owners can add, reconnect, or remove a connection — connecting a provider grants org-wide access to that provider's data, so it is gated behind the admin role. Listing connections and their status is available to any member.

No OAuth? Some MCP servers gate on a static token instead. Expand Advanced in the Add dialog and paste a bearer token; the server is connected immediately using that token.

Public servers that require no authorization at all (for example AWS's managed Knowledge MCP server) connect in one step — no redirect. Yak probes the server unauthenticated and, since it doesn't ask for authorization, stores it as a no-auth connection straight away.

Controlling which tools the AI can use

After a server connects, Yak discovers its tools. By default all of them are available to the assistant. On the connection's card you can check specific tools to restrict the assistant to just those — useful for exposing read-only knowledge-base lookups while keeping write/destructive tools off.

The same allowlist applies to both chat and voice.

Chat and voice

Connected tools work identically in both modes. Tool calls execute server-side — the browser never sees the provider credentials or the server URL. In voice, the model's tool call is relayed through Yak's backend, executed against the MCP server, and the result is spoken back; the data channel only ever carries the tool name, arguments, and result.

If a tool call fails, the assistant degrades gracefully (it tells the user it couldn't complete the request) rather than ending the conversation.

Security model

Tokens never reach the browser. All MCP calls go browser → Yak backend → MCP server.
Encrypted at rest. OAuth refresh tokens and static tokens are envelope-encrypted with a customer-managed key; they are never returned by any API.
Strict tenancy. A session can only ever reach the connections owned by the application it belongs to. The application (and its org) is resolved server-side from the request — it can't be widened by the client.
Reconnect on revoke. Access tokens are refreshed automatically. If a provider revokes access or the grant expires, the connection moves to Needs reconnect, the assistant degrades gracefully, and an admin can reconnect with one click from the Integrations tab.

Limitations

A connection authorizes Yak to the MCP server with a single application-level grant shared by all of that app's end-user sessions. Servers that need to federate to a downstream service per individual visitor, or that drive their own downstream setup through MCP elicitation (URL-mode "finish connecting" flows), are not supported yet — connect those providers' downstream sources in the provider's own console first.

One grant per (application, server); not per end-user.
Server-initiated elicitation / "finish setup elsewhere" prompts are not surfaced in the dashboard yet.
There is a per-application cap on the number of connections; keep the tool allowlist tight, since every exposed tool is offered to the model on every turn.