Authentication and channels
Connected account vs. customer sign-in
For each tool, you choose who it acts as when it runs: the shared company account, or the person in the conversation, who signs in. That choice decides what data the tool can reach and which channels it works on. Pick the option that matches the data the tool touches.
The two options
Connected account
The tool runs with a single company credential. Every conversation uses the same account, so every end user gets the same level of access. Use it for tools that read data that isn’t tied to one person: policies, product catalogs, store hours, public order status by number.
Because nothing depends on who the end user is, connected-account tools work on every channel, including voice and email.
Customer signs in
Some tools should only ever return a person’s own data: their orders, their account, their bookings. For these, the end user signs in to your system during the conversation, and the tool acts as that person, reaching no more than that user is allowed to.
If the end user is already signed in to your system, they may not need to sign in again. Depending on your authorization server, they may still complete a one-time consent screen.
If your platform can obtain a token that your MCP server accepts for the end user, it can forward that token to the AI Agent instead. The tool then runs without the authorization step in the conversation. See Forward a token from your platform.
What the end user sees
When the AI Agent needs the tool, it sends a sign-in prompt into the conversation. The end user opens the sign-in link, which takes them to your system’s own sign-in page in the browser. After they sign in, or accept a one-time consent screen, the browser window closes and the conversation resumes on its own. The AI Agent then runs the tool as that user. The end user can also decline and continue without signing in.
Supported channels
Signing in happens in a browser, so these tools run only on channels that support customer sign-in:
- Ada Chat
- Twilio SMS and Twilio WhatsApp
- Ada Instagram
- Most Zendesk Sunshine Conversations channels
Every other channel is skipped, including voice, email, and the Conversations API. Before you turn on customer sign-in for an MCP tool, confirm how each of your channels connects to Ada. The connection path, not the app the end user is in, decides whether the tool runs there.
There is no fallback to the company account. If a conversation on a skipped channel needs a sign-in tool, the Agent answers without it, or handles the request another way such as a handoff, rather than calling the tool.
When you build for a skipped channel, remember that a task needing the end user’s personal data can’t be completed by an MCP tool there today.
Forward a token from your platform
The authorization step in the conversation exists so that your MCP server can issue a token for the end user. If your platform can obtain such a token itself, it can pass the token to the AI Agent. The tool then acts as the end user, and the conversation has no authorization step.
The token must be one that your MCP server accepts for that end user. A session with your own app is not enough on its own: your platform has to hold, or request from your authorization server, a token issued for the MCP server. A token is issued for one server, so use a separate field for each server you connect.
To forward a token:
- Have your platform write the token into the end user’s sensitive metadata, under a field name you choose. Use the Chat SDK’s
setSensitiveMetaFields()or the End Users API. The name can contain lowercase letters, digits, hyphens, and underscores, up to 128 characters. - On the Tools page, open the server’s options menu and select Edit.
- Under Customer token field name, enter the field name, then save. This setting is available on OAuth connections only.
From then on, each time a tool that acts as the end user runs on that server, the AI Agent reads the field and sends the token with the call.
When the token is missing or rejected:
- If the field is empty, or the end user has no value stored, the tool falls back to the authorization step described above. An existing grant is reused if there is one; otherwise the end user gets the authorization link in the conversation.
- If the server rejects the token, the AI Agent stops using that value for the rest of the conversation and falls back the same way. Write a new token to the field to try again.
- Sensitive metadata values are deleted after 24 hours. Refresh the token before it expires if a conversation can run longer than that.
- To stop forwarding tokens, clear the Customer token field name field. The server goes back to the authorization step.
What the AI Agent does with the token:
- The AI Agent does not read or verify the token. It sends it only to that server, with that server’s tool calls. Your MCP server decides whether the token is valid.
- The token is never sent to the AI model and never sent to another server. It never replaces the company account: a tool that runs on the connected account ignores it.
- The channel rules above still apply. A forwarded token does not make these tools run on voice, email, or the Conversations API.
Choosing an option
Match the option to the data a tool returns, not to the tool itself:
- Start from the data: if a tool returns anyone-can-see-it data, use connected account; if it returns one person’s private data, use customer signs in.
- If your platform can obtain a token your MCP server accepts for the end user, forward the token, so the tool runs without the authorization step in the conversation.
- If you need a personal-data task on a channel that isn’t listed above, that path isn’t available through MCP tools yet, so design the conversation to handle it another way.
Related features
- Connect a server: Add a server, give it a credential, and turn on its tools.
- MCP tools overview: What MCP tools are and how they work.