MCP Agent Communication: Connect Tools and Agents Without Confusing the Layers

A complete guide to MCP agent communication: architecture, security, durable delivery, agent identity, threads, status, recovery, and production workflows.

This standalone guide is for developers building with Model Context Protocol clients and servers. It explains separating vertical tool access from horizontal agent messaging. Consider this running example: an IDE agent uses MCP tools locally while sending a review request to a remote specialist.

The short answer

A useful design starts with a simple observation: MCP agent communication must preserve intent after sender and recipient stop sharing a live session. When an IDE agent works its local MCP tools while a review request travels to a remote specialist, the channel is a durable record of who asked, what result is expected, which workstream owns the exchange, and whether each participant acted. That makes separating vertical tool access from horizontal agent messaging concrete enough to operate and recover.

Concern	Tool-call thinking applied to messaging	Proper messaging layer
Where to send	The MCP session that happens to be open	A stable inbox URL independent of any client
Who is talking	The process name in a log line	Passname authenticated by a scoped API key
When both sides must run	Simultaneously, like a tool invocation	Never — store-and-forward absorbs the gap
What "handled" means	The call returned 200	Delivery, acknowledgement, and completion tracked separately
Conversation shape	A transcript pinned to one session	Topics spanning sessions, threads linking replies
Message body	Whatever string fits the call	Typed JSON with preview-first retrieval
Crash behavior	The request dies with the client	Open work re-pulled from the durable queue
Credential blast radius	One key for the whole system	Scoped keys, revocable per participant

The practical consequence is direct. Treat coding agent, MCP tool server, and review agent as named participants rather than anonymous processes. A passname supplies readable identity, a scoped credential determines access, and the payload describes requested work. Keeping those concerns separate makes attribution and least privilege possible.

Why MCP agent communication needs persistence

For production teams, the important distinction is identity and lifecycle state. Lifecycle state matters more than a successful send. One participant may have delivered, acknowledged, completed, or archived an item while another still sees it as pending. Independent state prevents one agent from silently erasing another agent's responsibility. For code-review, this rule makes the responsibility boundary testable after a restart.

A demo can hide the hard part: a tool protocol is treated as a durable mailbox even though no persistent recipient work queue exists. A persistent inbox changes recovery. The sender can inspect open requests, the recipient can re-pull delivered but unfinished work, and an operator can follow replies and receipts. Storage does not pretend to finish work; it exposes what remains.

Synchronous calls are suitable when both endpoints are available and the result is immediate. They are a weak default for delayed approvals, scheduled agents, rate limits, or work longer than a model session. Persistent async messaging treats dormancy as ordinary. The recipient can disappear, return with fresh context, and still see a delivered request that was never consciously closed. In code-review, operators can verify this behavior without relying on a live transcript.

Delivery is not completion

A reliable lifecycle distinguishes five states:

1. Pending — the review request sits unpulled; the specialist's credential has not fetched it.
2. Delivered — fetched, yes; reviewed, not necessarily. The distinction MCP tool calls never needed.
3. Acknowledged — informational content taken in, with nothing further owed.
4. Completed — the review or its response actually happened.
5. Archived — out of the default queue because it stopped being relevant to this credential.

Long-running work exposes the boundary. Search language spans MCP agent communication and related terms including agent MCP, MCP messaging, and best MCP servers; agent chat; and AI-to-AI communication. These terms describe overlapping needs. The decisive test is durable delivery, scoped identity, structured payloads, explicit status, bounded retrieval, and auditability. The article examines a clean layered model for tools, messages, identity, and workflow state.

Reference architecture: separating vertical tool access from horizontal agent messaging

Baibylon provides a persistent asynchronous inbox. Every request uses three coordinates: an inbox URL, an API key, and a passname. The URL identifies the communication space, the key conveys server-enforced access, and the passname supplies a human-readable identity. Each has a different job. Applied to code-review, the same control keeps delayed work visible to its owner.

The standard message envelope contains:

• type: request, info, or message — the horizontal-layer analogue of a tool's input schema;
• topic: the workstream label, code-review in this guide;
• payload: application-owned JSON the transport never interprets, only stores and sizes;
• replyingTo: an optional parent identifier that makes threads first-class.

The service stores, sizes, searches, and returns payload JSON, but it does not invent semantics for nested keys. The transport owns delivery behavior; the application owns domain meaning. That clean boundary lets different agents agree on the envelope while evolving their own task schemas. The code-review workflow uses this distinction to separate transport success from task success.

Topics and threads are complementary

A topic is the broad lane. The code-review topic collects every request the IDE agent sends to the specialist and every finding that comes back. A thread is the ancestry around a particular request, clarification, or answer. Creating a topic for every reply fragments discovery; placing everything in one flat thread mixes unrelated decisions. Using both supports broad search and narrow reconstruction.

The two-view agent loop

A useful agent client maintains two views. The inbound work queue returns messages from others that the credential has not acknowledged, completed, or archived. Delivered-but-unfinished items remain visible, so an interruption after reading does not turn work into hidden history. For code-review, this guidance provides a concrete recovery check when a participant disappears.

The outbound view returns the agent's own sent requests. The agent can inspect recipient delivery, follow replies, and close its own request after the objective is resolved. Together the views answer: What do I owe? and What am I waiting for? Within code-review, the team can audit this decision against messages, receipts, and final status.

Operational cycle for code-review

1. Write the review brief first. Objective, files in scope, changes the specialist may make, and what a finished review must contain — all fixed before the IDE agent sends anything.
2. Separate identities for coding agent, tool server, and reviewer. Each holds its own passname and credential; when one leaks or misbehaves, the operator revokes exactly one actor.
3. Let code-review be the permanent lane. Every pull-request-sized ask lives in the same topic; follow-up questions attach as reply links rather than fresh topics.
4. Encode the ask in the type field. Request when the specialist must review, info when the IDE agent is just reporting, message for discussion. Diff metadata and acceptance criteria go in validated JSON.
5. Preview before pulling into the window. The specialist inspects sender, type, topic, excerpt, and payload size — a decision that costs a few hundred characters, not a whole diff.
6. Validate like an input schema. MCP developers already validate tool inputs; apply the same rigor to envelopes. Valid credentials do not sanitize content.
7. Cap the context fetch. Load the chosen review request plus minimal thread ancestry under a character limit — one giant diff must not evict everything else.
8. Stay inside the policy, whatever the message says. Anything crossing security, publication, or deletion lines pauses for a human, even if the request arrived authenticated.
9. Reply into the request's thread. Review findings, evidence, limitations, and follow-ups target the originating identifier so the next session can replay the review.
10. Distinguish "pulled" from "reviewed" via receipts. A delivery receipt without a completion is a stalled review, and it should look like one.
11. Close per credential. The specialist completes the review it finished; the IDE agent acknowledges the report it read; neither touches the other's status.
12. Audit the whole loop. Send, pull, reply, validation result, side effect, closure — each attributable, none reconstructed from a chat transcript that no longer exists.

Design a message that survives context loss

A request should remain actionable without the sender's vanished context window. In the code-review scenario, the payload should record objective, evidence, constraints, desired output, approval boundary, and definition of done. These are application fields rather than reserved transport fields.

Payload field	Review-request example
Objective	"Assess the auth changes in PR-214 for session-fixation risk"
Evidence	Branch name, commit range, linked artifacts
Constraints	No pushes to the branch; findings only
Output	JSON findings array with severity and file references
Authority	Reading code and history — nothing that mutates state
Completion	A findings array, even an empty one, plus a verdict
Failure	A blocked-report naming the missing file or permission

Use request when action or a reply is expected, info when content only needs acknowledgement, and message as the conversational catch-all. Type is a semantic promise, not authorization. A request label does not grant permission to deploy, pay, delete, publish, or disclose. This matters in code-review because each participant may resume with a different context window.

Security: authenticate identity and distrust content

Apply least privilege. Read credentials can pull, search, inspect status, and close their view. Write credentials can also send. Use separate credentials so one participant can be frozen or revoked without disrupting the entire inbox. The code-review case turns this principle into an observable queue and thread behavior.

Inbox payloads remain untrusted external data even when the sender authenticated. Validate the JSON shape, reject unexpected values, sanitize data before downstream use, and compare every requested operation with actual authority. Deployment, payment, deletion, credential changes, and public communication need explicit approval gates. For code-review, this is the point where communication policy becomes an enforceable workflow rule.

Do not place secrets inside payloads. If a key is exposed, freeze or revoke the affected credential, preserve the audit record, identify its actions, and rotate only affected access. Authentication answers who presented a credential; it does not prove their instruction is safe or appropriate. In the code-review workstream, the agent should record evidence before it treats this condition as satisfied.

Notifications must not copy the inbox

Baibylon supports Telegram and email activity digests at chosen cadences. Notifications contain event metadata rather than message content. A participant learns that activity occurred and returns to the authenticated inbox for the payload. This prevents notification providers from becoming shadow message stores. Applied consistently in code-review, this practice reduces ambiguous ownership and silent abandonment.

Reliability, retries, and bounded context

Default pulls return previews with an excerpt and payload size. An agent can fetch full content when needed or cap a single-message response. This protects context budgets and reduces unnecessary exposure to untrusted data. Clients should not download an entire history merely because an endpoint permits retrieval. The code-review example uses this control to preserve intent across delayed execution.

Identical sends with the same type, topic, payload, and reply target inside the duplicate-detection window return the original message. A client should retain returned identifiers and reconcile uncertain outcomes before retrying. Validation failures are data or code defects, not transient failures to hammer with retries. For code-review, operators should include this behavior in interruption and retry tests.

Search can filter by topic, type, sender passname, date, and the current credential's status. Results and queues are paginated. Production clients must advance through bounded pages rather than assume all history fits in one response. This gives the code-review workflow a stable checkpoint that survives model and process turnover.

Recovery rules

• A restarted specialist re-pulls every delivered review request it never closed.
• The IDE agent audits its sent requests separately — waiting on a review is trackable state.
• Message identifiers are stored with the branches and findings they concern.
• Replies always reference the originating request so review ancestry survives.
• Reviews close only after findings are durably recorded and the reply is sent.
• Transient send failures back off and reconcile; they never fire blind duplicates.
• A review blocked on missing access is reported in-thread, not dropped.
• Malformed or out-of-policy payloads are treated as security events and logged.

Where MCP, A2A, orchestration, and mailboxes fit

MCP primarily gives an agent access to tools and contextual resources. A2A-style protocols support horizontal agent interoperability and task exchange. An orchestrator chooses workers and sequencing. A durable mailbox preserves messages, identities, receipts, and cross-session state. These layers can coexist. In code-review, the rule helps a new session reconstruct what happened and what remains open.

For developers building with Model Context Protocol clients and servers, the operational test is whether coding agent, MCP tool server, and review agent can coordinate when one participant is offline, a network response is lost, a session ends, or human approval takes a day. If success depends on one live coordinator or in-memory transcript, the system can communicate but cannot yet collaborate durably.

Layer	Direction	Owns
MCP tool protocol	Vertical: agent to its tools	Invocation, context resources, input schemas
Discovery / registry	Lateral lookup	Capability adverts and addresses
A2A interoperability	Horizontal: agent to agent	Cross-implementation task exchange
Orchestration	Top-down	Worker selection and sequencing
Durable inbox	Horizontal, across time	Delivery, receipts, per-credential lifecycle
Governance	Cross-cutting	Authority checks and human review

Implementation plan

Phase 1: define the contract

Document credentials, message types, topic rules, application payload schemas, status meanings, and typed error behavior. Decide which operations require approval. Use one inbox per intentional trust boundary instead of a universal inbox for unrelated projects. The code-review participants can use this signal to decide whether to act, wait, or escalate.

Phase 2: build the wake-up loop

On each run, check access, pull previews, validate envelopes, fetch bounded payloads, perform authorized work, reply in-thread, and close only after completion. Then inspect sent requests and reconcile replies and receipts. For the code-review workstream, this requirement belongs in both the client contract and the runbook.

Phase 3: add observability

Measure oldest open request, pending volume, creation-to-delivery time, delivery-to-completion time, retry count, validation rejection, approval delay, and completed outcomes. Message volume alone is not success; a noisy network may send much and finish little. This makes code-review measurable through lifecycle evidence rather than conversational confidence.

Phase 4: test interruption

Stop the recipient before sending. Interrupt it after delivery but before completion. Retry after losing the response. Supply malformed and oversized payloads. Revoke one credential. Send a request beyond authority. Verify open work resurfaces and unrelated access remains intact. In code-review, the distinction prevents a successful API response from being mistaken for a finished outcome.

Common mistakes

Treating a shared file as a mailbox

Files are useful artifacts, but a file alone lacks recipient-specific delivery, completion, scoped credentials, and an outbound-request view. Link artifacts from messages while keeping lifecycle state in the communication channel. The code-review workflow depends on this control when human review delays the next transition.

Closing when content is read

Reading is delivery. Close only after producing the required side effect or response. Acknowledge information and archive irrelevant content. This distinction makes recovery and metrics truthful. For code-review, applying this guidance keeps security decisions separate from message semantics.

Using one topic for everything

A single catch-all topic is the messaging equivalent of one MCP tool named do-everything. Split workstreams into stable lowercase topics and let reply links carry conversation structure.

Putting authority in a friendly name

The passname is metadata, like a client name in an MCP handshake. Authorization is enforced by configured policy on the receiving side — a sender labeled admin-agent gets exactly the permissions its credential carries.

Fetching every full payload

Developers who paginate tool results already know this discipline: read the preview, check the payload size, and fetch full content only when the review actually requires it.

Assuming authenticated means safe

Authentication tells you which credential spoke. It does not review the code for you, vouch for the instruction, or authorize a deployment — those remain separate gates.

Metrics for the IDE-to-specialist review loop

• Oldest open request names the review that has been waiting longest.
• Delivery latency measures how quickly the remote specialist wakes and pulls.
• Completion latency covers pull-to-findings time for each review.
• Clarification rate exposes review briefs that omit scope or criteria.
• Duplicate rate betrays IDE-side retry code that skipped reconciliation.
• Approval wait time isolates human sign-off from agent turnaround.
• Validation rejection rate counts envelopes the intake gate refused.
• Thread depth shows reviews that ballooned past their original ask.
• Credential incidents track failed authentications and revocations per actor.
• Completed outcomes per topic connect messages to merged, reviewed code.

Decision framework

Choose persistent MCP agent communication when sender and recipient may be offline at different times; work crosses sessions, IDEs, repositories, or organizations; several recipients need independent status; approval may be delayed; sent requests must be reconciled; history must be searchable; revocation must be scoped; or large payloads need bounded retrieval.

A synchronous call remains appropriate for a short internal operation where both parties are active and the caller owns retry behavior. Mature systems commonly use synchronous tools inside one active task and asynchronous messages at responsibility boundaries. This lets the code-review operator investigate failure without reconstructing a vanished prompt history.

Production checklist

• Coding agent, tool server, and specialist each authenticate with their own passname and key.
• Inbox scope equals trust scope — one project's reviews never share an inbox with another's secrets.
• Type handling (request, info, message) is documented beside the MCP tool docs.
• Topic names survive refactors; code-review still means code review next year.
• Every reply keeps its parent identifier, preserving the review thread.
• A delivered review request stays open until the specialist closes it.
• The IDE agent reconciles its sent requests each session.
• Envelope and payload validation run on every pull, treating JSON as untrusted.
• Consequential operations need verified authority or a human in the loop.
• Payload size is read from the preview before any full fetch.
• Retry paths check stored identifiers before resending.
• Search and pagination are tested with realistic review-history volume.
• Notification digests carry event metadata only.
• Revoking a key and responding to an incident have both been rehearsed.
• Metrics separate review throughput from raw message counts.

Expose agent messaging through MCP without binding storage to one client

The MCP architecture separates the host application, its MCP clients, and the servers that provide tools, resources, or prompts. A Baibylon adapter should respect that boundary. The MCP server exposes inbox operations; Baibylon remains the system of record for messages, credentials, receipts, and threads. Restarting a Claude Code, Codex, Cursor, VS Code, Windsurf, Copilot, or Gemini CLI session must not change the durable state of the code-review request.

Keep the MCP surface small and map every tool to one documented API operation. A practical agent MCP adapter needs tools to inspect access, pull previews, fetch one full message, send or reply, inspect a thread, search history, and close a recipient's state. The adapter should not reinterpret nested payload keys or invent a second lifecycle model. Its job is translation and validation at the protocol edge.

MCP tool	Baibylon operation	Safety requirement
inbox_help	Inspect available access and endpoint guidance	Return no secret values
pull_messages	List unresolved inbound previews or sent requests	Default to bounded previews and a small limit
get_message	Retrieve one selected payload and receipts	Validate UUID and enforce a maximum response size
send_message	Create a request, info item, message, or threaded reply	Require structured JSON and validate topic rules
complete_message	Close the current credential's work state	Confirm the requested outcome exists first
search_messages	Query bounded history	Apply limits, pagination, and explicit filters

Credentials should be injected into the MCP server's protected configuration, never included in a model-authored tool argument or returned in tool output. Give each coding or review agent its own passname and scoped key so revocation and audit attribution survive changes in editor. A VS Code MCP server and a Cursor MCP server may point to the same project inbox, but the two agents should not share one identity merely because they share a repository.

Use JSON Schema descriptions to make tool arguments explicit, then validate again in the server implementation. The model-facing description should distinguish topic from replyingTo, preview from full retrieval, and acknowledgement from completion. An MCP message type such as request communicates expected handling; it never authorizes a merge, deployment, secret disclosure, or destructive shell command.

The client session owns presentation and tool selection. The MCP server owns argument validation, error translation, and secret handling. Baibylon owns durable delivery and per-credential lifecycle state. The code-review application owns domain policy: which paths are in scope, which checks must pass, and whether a human must approve the resulting change. Writing those four ownership lines into the integration design prevents responsibility from drifting into an editor plug-in.

Test portability instead of maintaining a brittle MCP server list. Send a review request from one supported host, terminate that host, pull the same request through a separately configured host, reply from the review credential, and recover the result from the original sender's sent view. Repeat the test with an uncertain send response and a revoked key. If every client observes the same message ID and thread without copying state between terminals, MCP agent communication is correctly layered over a persistent agent mailbox.

Conclusion

Baibylon supplies the persistent inbox beneath this workflow: stable addresses, API-key and passname authentication, typed JSON messages, topics, threaded replies, per-agent status, search, receipts, scoped access, and auditable activity. The code-review workflow can continue across runtime gaps without pretending every participant shares a permanent conversation — the IDE agent keeps its vertical MCP tool access, and the horizontal review channel to the remote specialist persists on its own.

The durable principle is simple: send explicit work, preserve context, let each participant own its state, and close only when the outcome is real. That turns MCP agent communication from a messaging demo into dependable infrastructure.