MCP in Practice: API, Server, and Permission Architecture for AI Agent Tool Calling

Understanding Agent Tool Calling from a Software Architecture Perspective

When an AI Agent needs to actually do things — read code, submit a PR, query a database — it can't simply have unrestricted system access. This is precisely the core problem that MCP (Model Context Protocol) is designed to solve. This article is based on a Session 3 MCP course taught from a software architect's perspective, covering the design relationships between tools, servers, registries, and permissions.

The instructor's entry point is clever: GitHub's API serves as the primary example to illustrate how APIs "expose" GitHub's working model. For an Agent to complete a task, the chain looks like this: Agent + API client → scoped authorization token → Git refs/working branches → content and commits → reviewable Pull Request proposals. In other words, an Agent must first authenticate via a scoped token before it can access code, documentation, or the API itself.

There's a key principle worth remembering here: a tool is only useful when it's correctly configured and its credentials permit the operation. If a tool's credentials don't allow a particular action, the Agent cannot be authorized to use that tool — permissions define the capability boundary.

MCP: Safely Wrapping Tools

The instructor emphasizes that tools should always be encapsulated within MCP servers so they can be safely invoked at runtime. MCP's value lies in enabling tools to be "called on demand" — executing their functionality only when truly needed — thereby ensuring operational safety.

A key design principle is: Discovery, Permission, Policy, and Runtime Assets must be separated — never conflated. Specifically:

• MCP servers must be able to discover tools;
• MCP servers must obtain permission to invoke and deliver tools through permission policies;
• Even after an Agent receives tools delivered by a client, it still needs runtime assets to access those tools.

This chain starts with Organization Policy. It defines the permission level an Agent holds and the list of approved servers within MCP. The organization policy authorizes servers to deliver tools to Agents through the client. Next comes the Registry — which stores the server catalog — along with the AI client, enabling the Agent to discover and invoke tools. Finally, the MCP server generates structured requests containing tools from the server, pointing to the underlying service APIs or local resources.

What's actually delivered to the Agent is the underlying service — functions, APIs, or local resources. You can also store local database APIs, application APIs, or enterprise ERP APIs within an MCP server, allowing Agents to securely retrieve them at runtime.

MCP (Model Context Protocol) is an open standard protocol released by Anthropic in late 2024, designed to provide a unified interface for interactions between AI models and external tools and data sources. Before MCP, every AI application needed to write separate integration code for different external services, creating a sprawling "M×N" integration matrix. MCP simplifies this into a standardized "M+N" connection pattern — models only need to support an MCP client, and tool providers only need to implement an MCP server, and the two can interoperate. Architecturally, MCP draws inspiration from the Language Server Protocol (LSP): it defines a standard JSON-RPC message format, allowing host applications to communicate with servers through a client, with servers then proxying access to underlying resources. This layered design allows permission control, audit logging, and tool version management to be uniformly enforced at the protocol layer, without intruding into each tool's implementation details.

Runtime Differences Between Local and Remote MCP Servers

Local and remote MCP servers use different runtimes — a distinction that must be clarified during deployment:

• Local MCP Server: Accesses locally deployed applications, such as on-prem databases or intranet applications. It runs as a local process or endpoint, can expose local files and custom tools, and commonly uses stdio as its transport. Security is enforced through local process permissions to limit the blast radius.
• Remote MCP Server: Connects to the internet and can interface with applications hosted in the cloud, outside the organization. It runs behind a network endpoint, can only connect to clients via HTTP transport, and uses authentication to authorize service access. Security relies on network controls and dual policies to restrict reachability.

Both share the same requirements: explicit trust and a narrow capability set. An example official remote endpoint the instructor provides is GitHub's MCP endpoint at https://api.github.com.

stdio (standard input/output) transport is the most common communication mechanism for local MCP servers: the host process launches the MCP server as a child process, sends requests via standard input, and reads responses from standard output. This approach naturally inherits the OS's process isolation and user permission model — the files and resources the server can access are limited to the user account that launched it, with no additional network exposure required. Remote MCP servers use HTTP-based Server-Sent Events (SSE) or Streamable HTTP transport, where requests must be TLS-encrypted and authenticated, making them suitable for multi-user sharing or cross-network-boundary scenarios. When choosing a transport method, the key criterion is the physical location of resources and trust boundaries: tools running on the same machine should prefer stdio to reduce the attack surface, while services requiring cross-network access must use HTTP transport with strict authentication.

Registry Policy: Controlling Server Access

The registry stores a list of tools the Agent can invoke along with their capability descriptions — essentially containing three elements: name, description, and capabilities. The instructor specifically notes that only registry-level policies require a successful server identity: when you design policies for an MCP server and its tools, and want the server to have the right to deliver those tools to an Agent at runtime, you must assign a server identity to execute actions.

The course lists several registry API requirements and their practical meanings:

• GET /v0.1/servers: Lists discoverable servers;
• GET /v0.1/servers/{name}/versions/latest: Returns the current entry;
• GET /v0.1/servers/{name}/versions/{version}: Returns a specific version;
• registry-only + matching server id: Restricts usage to registered entries.

The core choice here is between allow all and registry-only. allow all means servers can perform any operation in the registry, but you'll have no traceability over which tools the Agent actually called. registry-only achieves "narrowed access" — once server identity and permissions are enforced at the registry level, you can easily trace the tools delivered to a specific Agent back to their exact source. The instructor's recommendation is clear: enforce server identity at the registry level — don't use allow all.

Controlling the "Blast Radius" of MCP Servers

The final section discusses a security metaphor: MCP servers expand the "blast radius." Once a server is authorized, it can connect to applications (whether secure enough or not), effectively bridging your on-prem/remote applications and the Agent. This means every new server is a new pathway to data and operations. Consequently, when developing a new server, you must simultaneously define the tools it's permitted to expose at runtime.

The instructor offers several design principles for reducing the blast radius:

Tool Namespacing: Precise Authorization, Not Wildcards

Don't use broad wildcards to cram a large number of operations into a single unnamed tool. Give every tool a name, description, and capability — when a tool is invoked and performs an action, you can immediately identify what it did by name, enabling auditing and traceability.

Authentication: Inject Runtime Credentials Only for Components That Need Them

A server should not be able to authenticate against every API or tool it stores — it should only authenticate the specific one needed at the current runtime. For example, if an Agent only needs information from database A, but the MCP server exposes content from databases A, B, and C, the Agent receives excess information and the server risks leaking content it shouldn't expose. The correct approach is to have the server authenticate and invoke only the specific tool needed at that moment.

Change Control and Read-Only by Default

Apply scrutiny to networks, data destinations, sensitive inputs, and returned content; apply change control to server updates and tool list expansions; and be wary of risky dependencies. The key takeaway in this section is: approve read-only issue queries, but don't enable repository write permissions. A server should not be permitted to modify tools, databases, or applications — it should only authenticate, check out, and retrieve the required information, then deliver it to the client.

In doing so, you're implementing a bounded context under strong development governance — which is the engineering foundation for an AI Agent that can get work done without spiraling out of control.

"Blast radius" is a common term in security engineering describing the scope of impact from a failure or attack event, rooted in zero-trust security architecture design philosophy. In AI Agent scenarios, blast radius expansion primarily comes from two directions: over-permissioning (the Agent holds more permissions than needed to complete its task) and blurry tool boundaries (a single MCP server exposes too many unrelated operations). The Principle of Least Privilege requires that each component be granted only the minimum set of permissions needed to complete its specific task — a mature practice in traditional software systems, but harder to enforce in Agent systems because Agent behavior paths are difficult to predict, making it easy to grant broad permissions out of "convenience." Splitting servers by functional domain (e.g., deploying a "read-only query server" separately from a "write operations server") and requesting separate credentials for each server are concrete ways to operationalize the Principle of Least Privilege within an MCP architecture.

Summary

Session 3's main thread is clear: APIs expose working models, MCP wraps and safely delivers tools, registries control access, and permission design determines the boundary of an Agent's capabilities. For developers looking to connect Agents to real systems, these three principles are the most important engineering disciplines to implement first: "separate discovery/permission/policy/runtime," "registry-only instead of allow all," and "read-only instead of write permissions."