Connect an agent to a business system only after you have named the data and actions the job needs. An API defines how systems exchange requests; MCP standardizes how AI applications connect to servers that expose context and tools; permissions decide which user or agent may use an operation. These choices support one another, but they are not interchangeable.
Sources, instructions, actions, and systems connect to one bounded job.
Separate the protocol, connection, and permission
Each layer answers a different question:
Scroll horizontally to see all columns.
| Layer | What it answers | What it does not decide |
|---|---|---|
| API | What request and response a business system accepts. | Whether this user or agent should be allowed to make that request. |
| MCP | How an AI application connects to a server that offers resources, prompts, or tools. | Whether the server’s data or actions are authorized for a particular workflow. |
| Agent policy | Which public capabilities, tools, and limits an external agent currently exposes. | Whether an arbitrary API or MCP server is available to the agent. |
MCP can make a server’s interface easier to discover and use across compatible applications. The protocol does not enforce your organization’s business permissions by itself; each implementation must apply its own access and consent controls. In the current External Agents SDK documentation, integrations inspect the agent’s public policy and negotiated capabilities. The docs do not describe a general MCP connector, so do not assume that adding an MCP server makes it available through this SDK.
A connection is the configured path from an agent workflow to a system. It includes an owner, an identity, the operation exposed, and the rules enforced by the system. A read-only lookup and an update endpoint may use the same API, but they have different consequences and should receive separate authorization.
Work through one bounded request
Consider a service desk that receives: “Check the inspection status for asset A-104.” The system of record contains one inspection entry, marked complete on September 25. The first job is to return that record; it does not need to edit the inspection or schedule maintenance. Check the identity and permission boundary at each step:
- Verify the requester. Authenticate the person through the application's normal sign-in flow; do not rely on an identity supplied only in browser data. The service-desk owner decides which users may ask.
- Name the source and owner. The maintenance system owns inspection status, and its owner confirms which approved operation can read it.
- Identify the connection identity. Record which user or service identity will make the system call, then confirm its actual access with the system owner.
- Limit the system permission. For this request, allow a read of inspection status for permitted assets. Keep updates or maintenance scheduling outside this connection unless separately approved.
- Check the agent capability. For an external agent, inspect its current public policy and domain-tool details before presenting an action. Confirm the operation's side-effect class and whether approval is required; a protocol name alone does not establish access.
- Verify the result and stop condition. Return the recorded status and date. Route a missing record or conflicting evidence to its owner instead of inferring a result.
Completed lookup (illustrative)
Request: Check inspection status for asset A-104.
Requester: A signed-in service-desk employee authorized by the service-desk owner to ask.
Connection identity: An approved read-only integration identity can read inspection status.
Agent capability: The current policy exposes the lookup; the interface shows no update action.
Source result: Inspection marked complete on September 25.
Allowed action: Read the status; no record change.
Reply: “The latest inspection is marked complete as of September 25.”
This example assumes a read-only lookup is already authorized in the system. It does not imply that the SDK supplies this operation or that MCP grants access to the maintenance data.
Test the boundary before expanding it
Try a permitted request, a user who lacks access, a missing record, and a record with conflicting dates. Confirm that denied or uncertain cases reveal no unrelated data. For any operation that changes a record, identify who approves it and what evidence confirms the change completed.
For the core distinction, read knowledge, skills, tools, and connections. Review agent permissions and boundaries, then check the External Agents SDK’s policy and capabilities guide for the capabilities actually exposed by an agent.