Choosing integration contracts
Tool integration, remote task delegation, and reusable instructions solve different problems. Pick the contract for the boundary you actually have.
Do not turn a protocol choice into a product goal
A normal HTTP API may be sufficient for your own order database. MCP can standardize tool and context discovery for compatible clients. A2A addresses communication between agent systems. Skills package reusable instructions and supporting assets. None of these removes the need for a clear application-level contract.
How it works
Compare interfaces on identity propagation, authorization, transport, version compatibility, error semantics, observability, and deployment constraints. A protocol's existence is not evidence that adopting it improves your specific system. Start with the smallest integration that meets the requirements and document why.
A concrete example
The support assistant needs a read-only database lookup, a specialist shipping investigation, and a reusable refund-policy procedure. Those are three different boundaries. The procedure does not become an authorized refund endpoint simply because it is packaged as a skill.
Apply it to your assistant
Add an integration and state whether it returns data, runs a remote task, or provides instructions. Before running the exercise, predict the result. Afterward, explain which assumption changed and add one case where the system should refuse, ask for clarification, or escalate.
All exercise inputs and outputs are deterministic teaching examples. No language model is called. Run the same idea against a versioned dataset before making a production claim.
Key takeaway
Match contracts to boundaries; keep business permissions outside descriptive metadata.
JavaScript exercise: Choosing integration contracts · code experiment
Add an integration and state whether it returns data, runs a remote task, or provides instructions.
const boundaries = [
{ need: 'Read order status', kind: 'data API or tool' },
{ need: 'Investigate lost parcel', kind: 'remote task' },
{ need: 'Follow refund procedure', kind: 'instruction package' },
];
for (const item of boundaries) console.log(item.need + ' -> ' + item.kind);
Knowledge check
Which question should guide an integration choice first?
- Which acronym is most popular?
- Can every component use the same protocol?
- What boundary, identity, and lifecycle must this integration support?
Answer and explanation
What boundary, identity, and lifecycle must this integration support?
Requirements determine the appropriate interface. Popularity or uniformity alone does not solve authorization and lifecycle needs.
Sources
- Model Context Protocol specification — MCP contributors, 2026-07-28. Versioned protocol reference. Implementation details should be checked against the version you deploy.
Continue learning
- Model Context Protocol — MCP standardizes how applications connect to tools and context. It does not replace authorization or validate the truth of a tool result.
- Agent-to-agent communication — When work crosses agent-system boundaries, explicit tasks and artifacts are more dependable than an informal chat transcript.
- Choosing integration contracts — Tool integration, remote task delegation, and reusable instructions solve different problems. Pick the contract for the boundary you actually have.
- Reusable agent skills — A skill packages instructions and supporting resources for a repeatable task. It is executable guidance, not a new trust level.