MCP and A2A solve related but different AI integration problems. Model Context Protocol helps applications obtain external context and call tools. Agent2Agent supports communication among agent systems through messages, tasks and artifacts. Neither guarantees the factual correctness of a result or gives the model independent authority to change an external system.
This complete guide develops the practical difference through an entirely fictional Pinefield Museum programme enquiry. An assistant delegates source comparison to another agent, obtains a current notice through a bounded tool, checks an artifact and answers without inventing a registration. The exercise teaches the message, task and permission contracts behind a reliable AI workflow.
This is a specialist companion to eduKate’s How Super Intelligence Works curriculum, not a claim that modern AI has reached artificial superintelligence.
Contents and evidence routes
1. A protocol is an interface contract, not a truth certificate · 2. MCP serves tools and context to applications · 3. A2A supports interactions between agent systems · 4. Keep user permission separate from compatibility · 5. Tool discovery is not a tool call · 6. Input schema and access permission are different gates · 7. Resources, prompts and tools have distinct origins · 8. A2A messages are not necessarily long-running tasks · 9. An artifact can be complete and still be wrong · 10. The fictional Pinefield Museum evidence packet · 11. A narrowly bounded fictional document tool · 12. Delegating the comparison through A2A · 13. Check the original two notices · 14. The short answer the evidence permits · 15. Tool results do not grant booking authority · 16. Untrusted source instructions remain data · 17. Task identifiers and state do not certify correctness · 18. Fictional timing shows the complete cost of delegation · 19. The A2A artifact is not a source document · 20. A timeout should trigger state reconciliation · 21. The protocol boundary also carries privacy risk · 22. Independent transfer: a third approved notice · 23. A tool failure is not an event cancellation · 24. A simpler baseline may outperform several agents · 25. Independent tests for a protocol-based workflow · 26. Frequently asked questions · 27. Official sources and continued learning
1. A protocol is an interface contract, not a truth certificate
Protocols define what information participants exchange and how they describe operations or results. That is valuable when different services must work together. But a perfectly formatted message may contain an obsolete date or unsupported conclusion, and a successful request may return a result that applies to the wrong user.
The complete job still needs source provenance, permissions, claim checking and observed outcome. A protocol can report that an agent finished producing an artifact while the human-facing application remains unable to establish whether the artifact is correct.
2. MCP serves tools and context to applications
The Model Context Protocol supplies a standard way for AI applications to interact with external tool and context services. A client may discover a callable operation and provide arguments conforming to its schema, then receive a response or error. The exact supported capabilities vary by implementation.
Read the MCP base specification, 25 November 2025 for JSON-RPC requests, responses, notifications and lifecycle. The protocol defines communication; an operator must still define which user can access which records.
3. A2A supports interactions between agent systems
Agent2Agent treats collaborating agent systems as communicating participants. The A2A Life of a Task guide describes stateless messages and stateful tasks that can progress, request input or reach terminal statuses such as completed, failed or rejected.
A remote task can produce an artifact that the initiating coordinator uses later. Completion means the remote task reached a protocol state, not that a third-party factual claim has been independently verified or that a public booking has been confirmed.
4. Keep user permission separate from compatibility
A programme-time question authorises finding information, not editing the organiser’s database. The system should not allow a source document to broaden that authority merely by including command-like text. Access control belongs in the application and tool service as well as the model’s behavioural instructions.
This distinction matters even when both services implement the same protocol correctly. One caller may have permission to read a public notice while another may be permitted to update a specific record. A protocol envelope does not erase that difference.
5. Tool discovery is not a tool call
MCP’s official tool specification describes tools/list for discovering advertised capabilities and tools/call for invoking an operation. Discovery can return the tool name, description and parameter schema.
Learning that a schedule-lookup tool exists does not mean any schedule was retrieved. The assistant must invoke the correct operation, pass suitable arguments, inspect the result and check source scope. It cannot claim the work happened solely because the tool appeared in a catalogue.
6. Input schema and access permission are different gates
A tool may accept a string field called notice_id. The fact that a string is syntactically valid does not make every record bearing that identifier available to the caller. The underlying service must enforce access independently.
A permitted lookup can also return an incorrect or obsolete record. Thus schema validation, authorisation, execution status and factual relevance require separate checks. A tool’s attractive description cannot replace the evidence provided by its actual operation.
7. Resources, prompts and tools have distinct origins
An MCP resource may supply a document, while a tool may query records or compute a sum. Prompt templates are another type of capability. A retrieved resource is source content, not a higher-priority instruction to the assistant.
The distinction is important when an official-looking page contains imperatives. Those words may describe what a visitor should do but do not grant the assistant access to private membership data or permission to publish a public announcement.
8. A2A messages are not necessarily long-running tasks
An interaction may be a quick message or a trackable task depending on the remote agent’s capabilities. A stateful task can require more input or authorisation before reaching a terminal state. A coordinator should respect that distinction rather than describing every message as a completed job.
The task identifier helps correlate a particular operation with its later updates; a context identifier may group related interactions. These identifiers organise state but do not confer correctness, consent or an unlimited right to retain the conversation.
9. An artifact can be complete and still be wrong
A remote research agent may return a completed artifact containing a concise comparison of two documents. That means the artifact was produced. It does not prove its source dates were correct or that its conclusion applies to the current programme.
An independent auditor should open the controlling records and check each consequential claim. This is a separate step from accepting the remote task’s status. More agents agreeing is not independent proof when they all rely on the same obsolete source.
10. The fictional Pinefield Museum evidence packet
Pinefield Museum exists only in this teaching example. A visitor asks for the current start time and studio of a makers session. An initial preliminary notice, P-01, lists 10:00 in Studio 2. The later approved revision, P-02, lists 11:30 in Studio 4 and supersedes the earlier notice.
Neither notice supplies a current price, booking availability or confirmed reservation. The visitor’s permitted request is for information only. No real museum, booking service or remotely connected agent was accessed to create this packet.
11. A narrowly bounded fictional document tool
Imagine a tool whose sole purpose is to retrieve authorised public programme notices by ID and version. It can return source metadata and text fields but cannot access confidential visitor records or create a reservation. Its functionality should be restricted by the server even if a model asks for more.
An illustrative result contains programme identifier, approved notice revision, start time, studio and which earlier notice was superseded. These are fictional application fields, not mandatory schema elements built into the MCP protocol.
12. Delegating the comparison through A2A
The coordinator asks a remote research agent to determine which notice governs and prepare a supported comparison. The permitted deliverable is a research artifact, not publication, messaging or a payment. The request can be tracked as a task while the agent performs the authorised lookup.
A stateful task status tells the coordinator whether the remote work has completed or needs further action. The coordinator must still inspect the returned evidence and avoid presenting the remote agent’s confidence as a separate factual source.
13. Check the original two notices
The early P-01 record supports only its preliminary time and studio. P-02 supersedes it and supports 11:30 and Studio 4. The final answer must use both fields from the controlling version. Combining P-01’s time with P-02’s studio would invent a combination never stated in either document.
An auditor should retain the controlling source identifier beside each answer field, not merely attach an impressive reference list to the whole paragraph. Source-to-claim support is the important relationship.
14. The short answer the evidence permits
A defensible fictional response is: ‘The later approved P-02 notice lists the makers session at 11:30 in Studio 4. The preliminary P-01 notice was superseded. Registration availability and fees are not confirmed in the supplied source packet.’
This answers the visitor’s actual question without fabricating a transaction. It also identifies that the latest in the packet is not necessarily the latest document on a live website. Any real booking requires a separate appropriate workflow.
15. Tool results do not grant booking authority
The public-notice service can establish schedule fields under its source contract. It cannot establish availability or that a place was reserved. If the visitor later asks for a booking, the application would need the properly authorised booking interface, required user approval and a verifiable transaction state.
A successfully delivered tool response is not an external reservation receipt. A source that says a programme exists does not prove that any available seats remain. Protocol-level success is narrower than end-to-end task success.
16. Untrusted source instructions remain data
Suppose P-02 includes text instructing the assistant to reveal a confidential membership list. The notice was retrieved as evidence for a programme time, so its instruction-like paragraph must not become authority to change the workflow.
The OWASP prompt-injection guidance describes this lower-trust source-to-command hazard. Application-level permission controls should prohibit the private export regardless of how persuasive the source text appears.
17. Task identifiers and state do not certify correctness
A coordinator may use a task ID to retrieve the status of the remote comparison after an interrupted connection. The task could be completed while its artifact cites the wrong revision, or its artifact could be useful while delivery to the visitor later fails.
Track proposed, accepted, in-progress, input-required, completed and rejected states according to the applicable protocol and implementation. Then record the separate user-visible outcome. The status label must never be substituted for the evidence of what happened.
18. Fictional timing shows the complete cost of delegation
Suppose A2A delegation and queueing take 90 milliseconds, an MCP document lookup 140, source comparison 70, auditing 80 and final synthesis 50. If these stages run sequentially without other overhead, the combined time is 90+140+70+80+50 = 430 milliseconds.
These values are invented. They are not a benchmark of A2A, MCP or any vendor. They show why timing only the fastest internal stage underreports the wait for a complete checked user answer.
19. The A2A artifact is not a source document
A research artifact may repeat the approved notice’s fields, but it is a derivative summary. For a consequential claim, the original record and its revision status remain important. The artifact should carry provenance and clearly distinguish quoted source facts from agent interpretation.
If a later notice changes the programme, the research artifact may become obsolete. Updating a task result without changing or revalidating its underlying source would create a misleading sense of currency.
20. A timeout should trigger state reconciliation
An agent task can outlive a caller’s connection. If a consequential tool write is involved, the remote operation might have completed before the acknowledgement was lost. Blindly repeating it can create duplicate records.
Check the task identifier and the actual external target through authorised means before retrying. An uncertain state should remain uncertain until relevant evidence resolves it. This is a reliability property of the application workflow, not merely of the network transport.
21. The protocol boundary also carries privacy risk
Agent messages and tool results may contain user information, source excerpts or identifiers. A public session-time answer needs no private membership details. Keep each participant’s data scope as narrow as the task permits, and audit intermediate stores and logs as well as the final answer.
Using a standard protocol does not make data anonymous. Credentials and unrelated personal records should not be inserted into ordinary research artifacts simply because the recipients are technical agents.
22. Independent transfer: a third approved notice
Change the fictional packet. P-03 now validly supersedes P-02 and lists the same makers session at 12:15 in Studio 5. The source-correct answer changes to 12:15, Studio 5 and P-03. Booking status remains unverified because the new notice still does not contain reservation evidence.
The method transfers because the assistant compares source revisions and updates only the fields the new controlling record supports. Repeating 11:30 and Studio 4 would turn an old artifact into current misinformation.
23. A tool failure is not an event cancellation
Suppose the retrieval service becomes unavailable and the research agent cannot fetch the current notice. That is a task or tool failure, not proof that the museum event has been cancelled. The model should not invent a new status simply because information is temporarily unreachable.
The correct response identifies what source check could not be completed and points to the appropriate official organiser for confirmation. A failed technical operation and a changed real-world event are distinct propositions.
24. A simpler baseline may outperform several agents
The museum case could often be solved by a single permitted source tool and a straightforward rule selecting the later approved revision. The additional agent task introduces coordination overhead, multiple failure points and data transfer. That complexity may be worthwhile only if it improves the intended job.
Compare architectures with the same source packet, acceptance rubric, permission scope and verified output. A multi-agent service should earn its complexity through measurable value, not the number of participants involved.
25. Independent tests for a protocol-based workflow
A useful test suite includes a current source, superseded source, missing field, invalid tool input, unauthorised target, unavailable source service and interrupted remote task. Define the expected response and permitted status before running the system.
Test tool execution, artifact provenance, task-state handling, privacy boundary and the actual user-visible answer separately. Successful protocol communication does not establish that the correct current facts reached the visitor.
26. Frequently asked questions
Does MCP replace A2A? Not generally: they address different integration roles and can be combined. Does completed A2A mean verified truthful content? No, factual checking remains separate. Does an MCP input schema grant access to every valid identifier? No, authorisation is a separate control.
Do agent systems need these protocols? No. Other architectures can be appropriate. Does a successful research task prove a booking occurred? No, an actual booking requires its own authorised and verified transaction.
Applied protocol audit: identities, errors, approval and independent transfer
One request can cross two entirely different interfaces
The coordinator could ask a remote research agent through A2A to investigate the museum notice. The research agent could then use an MCP-exposed tool to obtain the approved source from a document service. The coordinator receives the agent’s finished artifact after the remote work reaches an appropriate state.
That sequence illustrates layered protocols without claiming the interfaces are identical. A2A carries an agent task; MCP can expose a tool used to perform part of it. Neither layer replaces source validation or the human user’s authority over the final purpose.
Correlation identifiers are not documentary citations
A protocol request ID helps associate a reply with its caller. A task ID helps follow a unit of agent work. A museum notice ID identifies a source document. Those three kinds of identifiers answer different questions and cannot substitute for one another.
A well-designed evidence artifact keeps the source ID beside each cited claim while storing protocol IDs separately for operational tracing. A task completed under identifier T-42 says nothing by itself about whether the museum notice P-02 was current.
Error replies need a correct interpretation
MCP can return a protocol-level error or indicate a tool-execution problem. A malformed argument, an unavailable service and an authorised query that returns no matching public notice do not all mean the event was cancelled.
The application should distinguish incorrect input, access denial, temporary service failure and genuine absence in the supported source. This diagnosis determines whether the next step is to repair the query, request permission, retry safely or ask the appropriate source owner.
A completed agent task may contain an unresolved question
The Pinefield agent can finish a comparison artifact even when registration availability remains unknown. Completion can mean it finished its assigned research task and accurately reported an unresolved field. This should not be relabelled as a failure merely because the source packet lacked a price.
The complete answer distinguishes known time and studio from unknown booking availability. A system rewarded only for filling every field may invent a number or promise that its tools never observed.
The source version belongs in the output contract
A source comparison should specify the effective revision, publication status and relationship to older notices. Without those fields, a coordinator might receive 11:30 and Studio 4 but not know which programme or date they describe.
For the fictional P-02 record, the important qualifiers are that it is the later approved notice and supersedes P-01 for the same session. A standalone time is a data fragment; a sourced time under a defined revision is a verifiable claim.
User approval is specific, not a general capability flag
An agent capable of sending messages does not automatically have permission to send a particular visitor’s details to anyone. A confirmation should identify the intended action, target and consequences. Technical access and legitimate approval must both be satisfied.
Suppose a visitor asked only for an explanation. A remote agent’s suggestion that it could reserve a seat should remain a proposal rather than an external booking call. The permission boundary follows the human task, not the system’s available menu of tools.
Tool annotations must be treated according to their origin
An MCP tool description may explain that an operation is expected to be read-only. The specification cautions that annotations from untrusted servers should not automatically be treated as authoritative. A malicious or mistaken extension might advertise one property while doing something else.
Server-side authorisation and resource constraints should therefore be checked independently. Human-readable labels help usability, but security depends on enforceable permissions and observable consequences rather than attractive descriptions.
A2A interruption is a valid workflow state
A research task might need more source details before it can compare two notices. It may request additional input, or encounter a genuine authorisation requirement. Those states should remain visible until the appropriate actor provides the required information or the work is stopped.
The coordinator should not invent credentials or ignore a refused access request. It can explain which field or approval is missing and preserve the part of the research that has already been verified.
Repeated status polling does not create progress
A coordinator may ask for the remote task’s status several times while it runs. Each poll can consume resources and provide an observation. Repeating the query does not accelerate the underlying document review or guarantee that a task will finish.
Choose an appropriate polling or event-subscription method from the implementation’s supported features. An application should report progress accurately rather than generating optimistic narrative updates because the user is waiting.
Streaming status is not a completed artifact
Some agent interactions support streaming updates. A partial message can indicate that a task is running or that one part of an answer has arrived. The user’s final service requirement may still be unfulfilled until the expected artifact and source checks are available.
The client should distinguish intermediate progress from terminal completion, and terminal task completion from independent correctness. A polished streamed sentence saying the research is ready is not the same as receiving and verifying the authoritative notice.
Source instructions should remain quoted subject matter
Imagine a museum document instructs human visitors to arrive early. An AI assistant may explain that visitor instruction as part of the published programme. It should not interpret the phrase as a personal command to send emails, access the membership database or move physical equipment.
The security issue is not the presence of imperative grammar. It is promoting lower-trust source content into an operational authority over the assistant. The safe system can read and discuss instructions without following them as its own orders.
Task status needs a distinct external-state ledger
A task that prepares a booking proposal may finish its artifact while the external booking database remains unchanged. If a separate permitted system later performs a reservation, the application should record attempted, accepted, committed and independently verified stages.
These states help recover after a timeout. Before repeating a write, the caller can check the intended target and avoid duplicate reservations or announcements. Protocol messages help coordinate the steps, but the underlying external record is the source of truth for the completed action.
A realistic application may be simpler than a research agent
If the museum publishes a structured current timetable with clear revision metadata, a straightforward lookup and deterministic selection rule may answer the visitor’s question without agent-to-agent delegation. That baseline has fewer messages and potentially a smaller security surface.
An A2A research agent is more justifiable when the job genuinely requires independent source comparison or multi-step work across services. Choosing the least complicated adequate approach is a practical engineering discipline, not a rejection of useful protocols.
The protocol trace can be checked by a pupil
Give a student five printed cards: the visitor’s question, the coordinator’s delegated task, the MCP tool’s public source result, the research artifact and the final answer. Ask which card establishes each fact and whether any card proves a booking occurred.
The correct response identifies P-02 as the source of 11:30 and Studio 4, the artifact as the research agent’s deliverable and no booking record anywhere. Then introduce P-03 to test whether the pupil can change the controlling evidence without confusing it with the protocol’s task status.
A numerical changed-context latency problem
Keep the fictional protocol stages but change retrieval from 140 to 220 milliseconds because the document service is slower. Under the same sequential assumptions, total service time becomes 90+220+70+80+50 = 510 milliseconds. The extra eighty milliseconds belongs to retrieval, not to the remote agent’s comparison computation.
This shows how performance diagnosis depends on stage timings. Making the coordinator’s prose generation ten milliseconds faster would not remove the new eighty-millisecond retrieval cost. An end-to-end latency claim needs measurements from each relevant stage.
Protocol version information belongs in the audit
The article’s MCP links explicitly identify the 25 November 2025 specification, while the A2A reference points to its current Life of a Task documentation as consulted for this lesson. Real interfaces may change with future specification or SDK releases.
An implementation should record which protocol versions, client libraries, tool schemas and service settings were used. A historical explanation can remain instructive while a production integration requires checking current supported behaviour.
Trace the smallest defensible privacy footprint
The fictional visitor’s question asks for public time and studio information. The coordinator does not need a passport number, personal email address or attendance history. The research artifact should contain the minimum public fields needed to answer, plus relevant source provenance.
Logs may store task identifiers and source versions for debugging without retaining all user messages. However, identifiers can still be sensitive when linked to a real person, so retention and access require deliberate rules. A standardised protocol is not a privacy guarantee.
Acceptance criteria make the whole stack testable
A strong end-to-end test requires a correct current time and studio, source provenance, no invented fee or registration status, no unauthorised tool call and a final message delivered to the intended requester. Each criterion can be evaluated separately on synthetic packets.
After changing the model, agent code or document schema, rerun the known tests and fresh variants. A completed MCP tool invocation and a completed A2A task are useful intermediate observations, but the final acceptance condition belongs to the user’s legitimate goal.
27. Official sources and continued learning
Primary technical reading includes the MCP base protocol, MCP tools and A2A task lifecycle. For permission risk see OWASP Excessive Agency.
Continue through eduKate’s Multi-Agent Systems, Grounding, Permissions and the complete numbered curriculum. All Pinefield facts and timing values are invented. Sources checked 22 October 2026.