Agent as a tool: MCP and A2A

Your assistant can answer not only people in the chat window or a messenger, but also other programs: Claude, Cursor, someone else's bot. For them it's a tool: "ask my support assistant", "give my researcher a task".

For this, every agent has its own address:

https://api.youselfbot.com/v1/agents/AGENT_ID/mcp

You don't need to type it by hand: the builder and the panel give you the address with your agent's identifier already filled in.

Don't confuse it with the builder's MCP

The platform has two MCP entries, and they're about different things.

	What the other program does	Key
This page — agent as a tool	talks to one of your agents, as a visitor	access key `ak_…`
The builder for agents	builds and changes the dashboard's agents	builder key `ck_…`

Want your Claude to ask the assistant about orders — you're in the right place. Want it to set up the assistants themselves — go to the builder page.

How to give access

Tell the builder:

give my Claude access to this agent

or "make a key for Cursor". It will ask who the key is for if you didn't say, issue it and immediately give you a ready-made setup for your program. The same with a button: the panel on the right → "Access for other agents" row → a name → "Issue key".

The key is shown once

The platform doesn't store the key's value — only its fingerprint. Save the key right away; lost it — revoke it and issue a new one. In the conversation with the builder, the key is also visible only in the reply that issued it: it disappears from the conversation history.

You can have up to twenty keys, each with its own name — "Claude on my laptop", "Cursor", "partner's bot". That way you can see exactly who's calling, and you can revoke one without touching the rest.

Setting up the program

In the examples, ADDRESS is your agent's address and ak_YOUR_KEY is the issued key. The builder and the panel give you these pieces already filled in.

Claude Code — one command in the terminal:

bash

claude mcp add --transport http youselfbot-agent ADDRESS \
  --header "Authorization: Bearer ak_YOUR_KEY"

Cursor — the file ~/.cursor/mcp.json (for all projects) or .cursor/mcp.json in the project folder:

json

{
  "mcpServers": {
    "youselfbot-agent": {
      "url": "ADDRESS",
      "headers": { "Authorization": "Bearer ak_YOUR_KEY" }
    }
  }
}

Claude (website or app) — Customize → Connectors → "+ Add" → "Add custom connector": any name, the address — ADDRESS. At the authentication step choose "No sign in", and under Request headers add the Authorization header with the value Bearer ak_YOUR_KEY.

Another agent on this platform — tell that agent's builder: "connect the MCP server at ADDRESS with the token ak_YOUR_KEY". This way one of your assistants asks another — including an assistant from someone else's dashboard, if its owner gave you a key.

Any other program that supports MCP — Streamable HTTP transport, the address and the header Authorization: Bearer ak_YOUR_KEY.

What the other program sees

Tool	What it does	Arguments
`ask`	A message → the assistant's answer.	`message`; `conversation_id` — to continue a conversation
`task_start`	Assigns a long task: the work runs in the background in passes. Returns `task_id`.	`title`, `brief`
`task_status`	The task's state, progress and — when finished — the summary and the assistant's answer.	`task_id`

task_start and task_status exist only for an agent that can do long tasks (its flow names the long_task capability). Other agents don't list them at all — better that than a tool that refuses on the very first call.

The ask response carries a conversation_id. Pass it in the next ask — and the assistant will remember what you talked about. Without it, every call is a new conversation. Conversations of different keys never overlap, even if the identifiers happen to match.

There's also a resource agent://ID/about — a description of the assistant: who it is and what to ask it about. You write the description yourself: "describe the agent for others: it knows everything about delivery and returns". The other model sees this text, so don't write anything internal in it.

The other program is a visitor

Whatever the program says about itself, to the assistant it's a visitor — like a person in the chat window on your site:

it won't get actions marked "admin only";
nor your email, calendar or the assistant's notes about you;
a long task it set runs with the same rights.

There's no "on behalf of the owner" mode, and that's deliberate: the key sits in the other program's settings file, and everything it unlocks is available to anyone who has read that file.

Every such conversation is visible in the Conversations section (the "Handled by the assistant" filter), and every turn is in the turn log, just like conversations from the window.

You can't reply in such a conversation yourself: on the other side is a program that only waits for an answer to its own call, and it won't read a person's message. The dashboard says exactly that — "reply not sent" — rather than showing the message as sent.

Who pays and what the limits are

Every ask and every task pass is a normal assistant turn: it spends your dashboard's credits. The same limits apply as everywhere:

the agent's spending cap and the dashboard's credit balance;
the rate limit is per key, not per address: sixty credit-spending calls (ask, task_start) per minute;
an agent runs three long tasks at once, and the slots are shared with you. One key runs one task — it starts the next one when the previous one has finished; everyone who isn't you (other programs and visitors in conversations) holds no more than two between them, and the third slot is always left for you. Only you can pause or cancel another program's task — in the task list.

When credits have run out, the rate limit is exceeded or a turn failed, the call returns a tool error (isError: true) with text that says whether it's worth retrying. The model on the other side reads it and passes it on to the person instead of blindly repeating the call. As always, you'll get a notification about running out of credits.

Taking access away

take access away from Cursor

or the "Revoke" button next to the key in the panel. The program with this key loses access immediately; other keys keep working. If the key leaked and all you have is its value — paste it to the builder: "revoke the key ak_…" — it will find and revoke exactly that one.

If you delete the agent, all its keys stop working along with it.

So other agents can find yours: the A2A card

A2A (Agent2Agent) is a second standard that agents use to find each other. Its basis is the agent card: a public address with a name, a description and how to make contact.

https://api.youselfbot.com/v1/agents/AGENT_ID/.well-known/agent-card.json

By default there's no card. It's a publication, so you turn it on yourself: "make the agent visible to other agents". To hide it — "hide the agent from others". The card contains only the name, your description and the entry address; it doesn't let anyone talk to the assistant — a key is still needed. Another agent that has already read the card may still see it for up to five minutes after you hide it.

The A2A entry is …/v1/agents/AGENT_ID/a2a, JSON-RPC protocol, version 1.0 (header A2A-Version: 1.0), the same key in Authorization: Bearer. One method is supported:

bash

curl -sS A2A_ADDRESS \
  -H "Authorization: Bearer ak_YOUR_KEY" -H "A2A-Version: 1.0" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"SendMessage","params":{"message":{
        "messageId":"m1","role":"ROLE_USER","parts":[{"text":"What are your opening hours?"}]}}}'
# {"jsonrpc":"2.0","id":1,"result":{"message":{"role":"ROLE_AGENT","contextId":"…",
#   "parts":[{"text":"We're open from 9:00 to 18:00."}],"messageId":"…"}}}

The contextId from the response continues the conversation — just like conversation_id in MCP.

What the A2A entry doesn't have

It's a minimal entry, and the card says so honestly:

the answer comes straight away as a message — there are no A2A tasks, streaming or push notifications (GetTask answers "task not found", the other methods — "operation not supported");
only text is accepted — a file or structured data gives an error rather than being silently dropped;
version 0.3 isn't supported: by the standard, a request without the A2A-Version header is treated as version 0.3 and gets a refusal naming the required version;
long tasks — only via MCP (task_start).

The MCP protocol: what exactly is supported

The transport is Streamable HTTP: one POST — one JSON-RPC message, the response is application/json. The server doesn't open a stream; GET and DELETE return 405.

The server understands two spec eras:

the current one, 2026-07-28 — there's no handshake: every request carries the client's version and capabilities in params._meta and duplicates them in the MCP-Protocol-Version, Mcp-Method, Mcp-Name headers. The headers are checked against the body; server/discover is available;
the earlier ones, 2025-03-26 – 2025-11-25 — with initialize. Most programs people already have installed speak these.

The request itself determines the era; you don't need to switch anything. Requests from a page in a browser (with another site's Origin header) are rejected with 403 — both at the MCP address and at the A2A entry: a key doesn't belong in a page. One message per POST: a batch (array) gets 400, a body over 1 MB — 413.

All endpoints and schemas are in the API reference, in the sections "Агент для інших агентів" (Agent for other agents) and "Кабінет · Доступ інших агентів" (Dashboard · Access for other agents).

The builder for agents: MCP — so another program builds agents rather than talks to them.
Long tasks — what a pass is and how to see progress.
How much it costs — credits and the agent's spending cap.

Agent as a tool: MCP and A2A ​

How to give access ​

Setting up the program ​

What the other program sees ​

The other program is a visitor ​

Who pays and what the limits are ​

Taking access away ​

So other agents can find yours: the A2A card ​

The MCP protocol: what exactly is supported ​

Next ​