Agent-as-a-Tool (MCP)
4 min read
Most assistants that people already use speak MCP (Model Context Protocol), not A2A: Claude, Microsoft Copilot, ChatGPT, Cursor and other IDE assistants. With Agent-as-a-Tool, any of them can call a Unique space like a tool. The assistant stays in charge of the conversation. It sends a question, Unique runs the space for the signed-in user, and the assistant gets the answer back with references.
This is not A2A. There is no task lifecycle, no multi-turn negotiation and no delegation from Unique back to the caller. For that, use Agent-to-Agent (A2A).
Your own MCP server
Unique provides each customer with a dedicated MCP server. It is built on Unique's production-ready MCP server and runs in your Unique environment. Unique customizes it to your needs before it goes live. There is no generic, shared endpoint.
What is customized | Examples |
|---|---|
Tools | Which spaces are exposed, under which tool names and descriptions, and what the input looks like. Typically one tool per space, plus optional action tools such as requesting a follow-up. |
What users see | Your branding and wording in the result view. Live progress while the space works. Whether sources are shown as a list, as cards, or not at all. How a space's answer is labelled compared with text the assistant writes itself. |
What information leaves Unique | Answer text only, or also references, document names, links, or structured data. Which fields are exposed is decided per tool. |
Identity | Which identity provider users sign in with, and how an identity maps to a Unique user. See Identity and permissions. |
Behaviour | How refusals are handled, e.g. a question outside the user's mandate. Where follow-up requests are routed. Timeouts. |
Space admins do not need to prepare a space for this. Any space the signed-in user can use can be exposed as a tool.
How a call works
The user adds your MCP server URL to their assistant and signs in once.
The assistant lists the tools. Each tool carries a description that tells the assistant's model when to use it.
The model calls a tool with the user's question.
The MCP server starts a new chat in the matching space on behalf of the user and waits for the answer. While the space works, it reports progress: which sub-agents are consulted, how long it has been running, and the partial answer as soon as text arrives.
The answer and its references are returned to the assistant. Assistants that support MCP Apps render them in the customized result view. Other assistants receive plain text.
The assistant continues its own conversation with the result.
What the client sees
Value | |
|---|---|
Tool name and description | Defined with you. The description decides when the assistant's model calls the space, so it states what the space knows and when to use it. |
Input | The question as text. Further fields can be added per tool. |
Output | The answer text, the references the space cited with name and link, and a label that marks the answer as provided by the space. Only the fields agreed for the tool. |
Progress | Steps, elapsed time and partial answer in the result view while the space works. A space with sub-agents can take a minute. |
Sources | Clickable in the result view. Each source is fetched as the signed-in user, so document permissions apply again when a source is opened. |
Each call starts a new chat in the space. If the assistant wants to continue a topic, it has to include the context in its next question. The assistant's own conversation never reaches Unique.
Identity and permissions
Sign-in. The assistant authenticates against your MCP server with OAuth. Users sign in through the identity provider agreed with you: Unique IAM for your employees, or another OpenID Connect provider for audiences without a Unique login.
Mapping. Every signed-in identity maps to exactly one Unique user. Identities without a mapping are refused before anything reaches a space. There is no fallback to a shared account.
Rights. The space runs with the mapped user's rights. The user needs access to the space and to every sub-agent space it uses. Knowledge base permissions apply as in the chat UI. Documents the user cannot read never leave Unique.
Visibility. The assistant receives only the fields agreed for the tool. It never receives prompts, tool traces or model names.
Audit. Every call creates a chat in the space and is logged like any other interaction. The MCP server logs each tool call with the identity that made it.
Getting started
Who | What |
|---|---|
You | Name the spaces to expose, the audience, the identity provider, and what users may see. Decide on branding and wording of the result view. |
Unique | Customizes and deploys your MCP server, connects it to your identity provider, and hands over the server URL. |
Space Admin | Grants the mapped users access to the spaces, as for any other user. Nothing else changes on the space. |
User | Adds the server URL to the assistant, signs in, and asks. |
Compared with A2A
Agent-as-a-Tool (MCP) | Agent-to-Agent (A2A) | |
|---|---|---|
Direction | Inbound only | Both |
Conversation state | Per call. The caller carries the context. | Per context. Follow-ups continue the same chat. |
Clarifications | None. The space answers with what it has. | The space can ask the human a question. |
Streaming | Progress in the result view where the assistant supports MCP Apps | Server-sent events |
Files | References with links | File artifacts in both directions |
Setup | Customized per customer by Unique | Self-service per space, once the gateway is deployed |
Limitations
Inbound only. A space cannot call tools of the assistant.
No conversation memory between calls on the Unique side.
Long-running calls depend on the assistant's timeout. Assistants without MCP Apps support show nothing until the answer arrives.
Changes to exposed tools, fields or branding are made by Unique, not in the admin interface.
Related
Agent-to-Agent Architecture