AI ENGINEERING — ACTIVE CONCEPTS & PRACTICES | #009
Model Context Protocol (MCP): Standardizing AI Connections to Tools and Data
Chapter 2: Engineering AI Applications and Agents
AIYING — Accomplishing with AI
The Big Idea: Tool calling enables AI applications to use external capabilities. Model Context Protocol (MCP) provides a common interface through which compatible AI applications can discover and interact with external tools, resources, and prompts.
Engineering question: How can an organization make its existing systems accessible to multiple AI applications without building and maintaining a separate custom integration for every combination?
Contents
- Why MCP Matters
- UNDERSTAND — What Is MCP?
- CONNECT — Related Engineering Concepts
- MCP Architecture and Lifecycle
- APPLY — Enterprise Procurement Integration
- Worked Example: Purchase Order Lookup
- Engineering Decisions and Trade-offs
- Active Industry Practices
- ACCOMPLISH — Design an MCP Integration
- Student and Practitioner Project
- Check Your Understanding
- Active Connections
- References and Further Reading
1. Why MCP Matters
Imagine an enterprise operating three AI applications:
- A procurement assistant
- A technical-support assistant
- An AI operations assistant
Each application needs information from enterprise databases, document repositories, and business software.
Without a common integration approach, engineering teams may develop separate connectors for each application and external service.
This creates duplicated work, inconsistent interfaces, maintenance costs, and additional security review requirements.
MCP addresses part of this integration challenge by standardizing how AI applications discover and interact with exposed capabilities.
2. UNDERSTAND — What Is MCP?
Model Context Protocol (MCP) is an open protocol for connecting AI applications to external systems that provide tools, resources, and reusable prompts.
Originally introduced by Anthropic, MCP has developed as an ecosystem protocol with implementations across multiple AI platforms and developer tools.
The three architectural roles
| Component | Responsibility |
|---|---|
| MCP Host | The AI application that manages user interaction and MCP connections |
| MCP Client | A protocol component within the host that communicates with an MCP server |
| MCP Server | Exposes capabilities through a standardized MCP interface |
A host can manage connections to multiple servers through separate MCP clients.
The three foundational server capabilities
| Capability | Purpose | Example |
|---|---|---|
| Tools | Expose callable operations | Retrieve a purchase order |
| Resources | Expose contextual information | Read an approved supplier policy |
| Prompts | Expose reusable prompt templates | Supplier delay analysis template |
Tools, resources, and prompts are distinct protocol concepts. A server may expose one or more of them.
How is MCP different from an API?
An API defines how software accesses a particular service. MCP defines a common interface for presenting capabilities to compatible AI applications.
An MCP server can wrap an existing REST API, database, or enterprise service. The original API remains part of the implementation.
How is MCP different from tool calling?
Tool calling is the process through which a model or AI application requests an external operation.
MCP provides a standardized mechanism for discovering and accessing tools and other capabilities.
An AI application may translate a model-generated tool request into an MCP tool invocation.
Neither tool calling nor MCP automatically guarantees that an operation is safe or authorized.
3. CONNECT — Related Engineering Concepts
| Concept | Connection to MCP |
|---|---|
| Tool Calling | MCP tools can be made available for model-requested operations |
| Structured Outputs | Tool arguments and results use structured data |
| JSON Schema | Describes tool input and output structures |
| APIs | MCP servers can expose capabilities backed by APIs |
| Context Engineering | MCP resources can contribute external context |
| AI Agents | Agents may coordinate capabilities exposed by MCP servers |
| Authentication | Establishes identities and access credentials |
| Authorization | Determines which operations and records are permitted |
| Observability | Monitors server interactions, errors, and latency |
| AI Governance | Establishes trust, oversight, and accountability requirements |
An important architectural insight
MCP separates the presentation of external capabilities from much of the application-specific integration code.
This can improve reuse and interoperability when both the host and server implement compatible protocol capabilities.
4. MCP Architecture and Lifecycle
↓
MCP Client↓ Protocol Communication
MCP Server↓
Enterprise API / Database / Service↓
Authorized Result↓
AI ApplicationStep 1 — Connection and initialization
The MCP client and server establish communication and negotiate supported protocol capabilities.
Step 2 — Capability discovery
The client can discover available tools, resources, or prompts using the relevant protocol operations.
Step 3 — Model or application selection
The host determines which available capability is relevant to the task. A model may propose a tool call, but application logic remains responsible for execution decisions.
Step 4 — Invocation
The MCP client sends a request to the server using the defined protocol interface.
Step 5 — External execution
The server may access an underlying API or database, subject to applicable permissions and controls.
Step 6 — Result handling
The result returns to the host, which may validate it, display it, or supply relevant information to the model.
Transport options
MCP supports communication arrangements including local standard input/output (stdio) and remote Streamable HTTP transport.
Transport selection affects deployment, authentication, operational monitoring, and security architecture.
Use the current MCP specification for implementation details because protocol features and transport guidance evolve.
5. APPLY — Enterprise Procurement Integration
Scenario: Multiple Assistants, Shared Enterprise Capabilities
A manufacturing company has purchase-order information in an ERP system, inventory records in a database, and supplier policies in a document repository.
The organization wants multiple AI assistants to access these capabilities through controlled interfaces.
Approach A — Separate integrations
Each assistant implements its own connection logic for the ERP system, inventory database, and document repository.
Changes to an underlying API may require updates across multiple applications.
Approach B — Shared MCP servers
The engineering team develops or deploys MCP servers that expose approved capabilities:
- Procurement server: Purchase-order lookup tools.
- Inventory server: Stock availability tools.
- Policy server: Approved procurement documents as resources.
Compatible AI applications connect through MCP clients.
Server implementations still need to enforce user permissions, data restrictions, input validation, and operational controls.
Engineering outcome
This architecture may reduce duplicated integration work and improve reuse.
However, standardizing the interface does not automatically make business semantics, permissions, or error handling identical across systems.
6. Worked Example: Purchase Order Lookup
The following is a conceptual example using fictional enterprise data. It is not a live MCP connection.
Available MCP tool
{
"name": "get_purchase_order",
"description": "Retrieve an authorized purchase order",
"inputSchema": {
"type": "object",
"properties": {
"po_id": {
"type": "string"
}
},
"required": ["po_id"],
"additionalProperties": false
}
}
Illustrative MCP tool request
{
"jsonrpc": "2.0",
"id": 1,
"method": "tools/call",
"params": {
"name": "get_purchase_order",
"arguments": {
"po_id": "PO-1048"
}
}
}
Illustrative tool result
{
"jsonrpc": "2.0",
"id": 1,
"result": {
"content": [
{
"type": "text",
"text": "PO-1048: delayed; revised delivery 2026-11-23"
}
]
}
}
The tool result is illustrative. Production implementations should use appropriate typed outputs, validation, error reporting, and access controls.
What happens next?
The AI assistant can report the retrieved order status.
If the user also requests a follow-up task, the host may make an additional authorized tool available for that purpose.
The MCP server must not assume that a request from an AI model is automatically permitted.
Key distinction
The model may select the capability. The MCP client transports the request. The server implements the operation. The application and supporting systems remain responsible for authorization and outcome verification.
7. Engineering Decisions and Trade-offs
| Decision | Potential Benefit | Risk or Trade-off |
|---|---|---|
| Shared MCP servers | Reusable integrations | Shared dependency and operational concentration |
| Local servers | Convenient local tool access | Host-machine access and process security risks |
| Remote servers | Centralized services | Network, authentication, and availability concerns |
| Read-only capabilities | Lower operational impact | Limited automation |
| Write-enabled tools | Greater workflow automation | Higher risk of unintended side effects |
| Broad tool catalogs | More capabilities | Selection complexity and attack surface |
| Third-party servers | Faster integration | Supply-chain and trust assessment requirements |
Important security risks
- Malicious or compromised MCP servers
- Excessive tool permissions
- Unauthorized access to enterprise records
- Prompt injection through tool results or resources
- Credential leakage or insecure token handling
- Unapproved data transmission
- Misleading tool descriptions
- Unintended or repeated write operations
Recommended engineering controls
- Maintain an approved server inventory.
- Review server provenance and implementation.
- Use least-privilege credentials.
- Enforce authorization for each sensitive operation.
- Validate tool inputs and outputs.
- Require appropriate approval for consequential actions.
- Restrict access to sensitive resources.
- Log relevant operations without exposing secrets.
- Monitor errors, changes, and unusual tool activity.
- Test resilience and failure recovery.
8. Active Industry Practices
Established foundations
- Client-server protocol architecture
- Structured tool discovery and invocation
- Resource access through standardized interfaces
- Reusable prompt templates
- Local and remote server deployments
- Integration with existing APIs and services
Developing engineering practices
- Enterprise MCP server registries
- Centralized server governance
- Fine-grained tool access policies
- Multi-server agent architectures
- Server trust and provenance assessment
- MCP observability and evaluation
Where MCP is relevant
MCP is relevant to AI coding assistants, enterprise knowledge assistants, data-analysis workflows, business-process automation, agentic applications, and AI-enabled developer environments.
It is particularly useful when multiple compatible AI applications need reusable access to external capabilities.
For a simple application with one stable API integration, a direct API connection may remain the more practical engineering choice.
Practice status: Open integration protocol with an evolving ecosystem and operational practices.
Reviewed: November 2026.
9. ACCOMPLISH — Design an MCP Integration
Exercise: Enterprise Procurement MCP Architecture
Consider a fictional manufacturing company with the following systems:
ERP: Purchase orders and supplier records.
Inventory database: Stock availability.
Document repository: Procurement policies.
AI applications: Procurement assistant and operations assistant.
Your tasks
- Identify the capabilities each AI application needs.
- Decide which capabilities should be tools and which should be resources.
- Design an MCP server architecture.
- Define a purchase-order lookup tool and its input schema.
- Specify how user permissions should be enforced.
- Identify operations requiring approval.
- Describe how errors and unavailable services should be handled.
- Explain how the design reduces duplicated integrations.
Reusable AI-assisted prompt
Act as an enterprise AI integration engineer. Design an MCP-based architecture for a fictional procurement organization. Systems: - ERP purchase orders - Inventory database - Procurement policy repository AI applications: - Procurement assistant - Operations assistant Provide: 1. MCP host, client, and server roles. 2. Proposed tools, resources, and prompts. 3. Tool input schemas. 4. Capability discovery and execution flow. 5. Authentication and authorization controls. 6. Human approval requirements. 7. Failure handling and observability. 8. Integration reuse benefits. 9. Risks and limitations. 10. A small implementation test plan. Do not assume that MCP automatically provides security or business authorization.
Accomplishment: Design an MCP integration architecture that supports reusable capabilities while preserving operational control.
10. Student and Practitioner Project
Mini Project: Build a Read-Only MCP Server
Objective: Build or prototype an MCP server that exposes purchase-order lookup capabilities using fictional data.
Project requirements
- Create a small fictional purchase-order dataset.
- Choose a compatible MCP SDK.
- Implement a read-only purchase-order lookup tool.
- Define and validate tool input parameters.
- Expose a sample procurement-policy resource.
- Connect using a compatible MCP client or inspection tool.
- Test capability discovery.
- Test successful and unsuccessful tool invocations.
- Check that unauthorized or invalid requests are rejected.
- Document execution logs and observed limitations.
Suggested evaluation measures
| Metric | What It Measures |
|---|---|
| Discovery success | Whether the client can discover capabilities |
| Invocation accuracy | Whether valid tool calls return correct results |
| Input validation | Whether invalid arguments are rejected |
| Access control | Whether unauthorized operations are blocked |
| Latency | Time required to complete tool requests |
| Error handling | Whether failures are reported accurately |
| Reuse potential | Whether multiple compatible clients can use the server |
Deliverable: A working demonstration or architecture prototype, tool definition, sample request and response, test results, and an engineering recommendation.
Use fictional data and a local development environment. Do not expose real credentials or production systems during the exercise.
11. Check Your Understanding
- What problem does MCP address in AI engineering?
- What is the difference between an MCP host, client, and server?
- How do MCP tools differ from resources and prompts?
- How is MCP different from a conventional API?
- How does MCP relate to model tool calling?
- Does MCP automatically enforce enterprise authorization?
- What risks arise from connecting untrusted MCP servers?
- When might a direct API integration be preferable?
Reflection: If an MCP server exposes a tool named "approve_payment", should an AI assistant be allowed to invoke it merely because the tool is discoverable? What additional controls are necessary?
12. Active Connections
- #001: Context Engineering
- #002: Token Economics
- #003: Embeddings in Practice
- #004: Retrieval Engineering
- #005: Chunking and Reranking
- #006: Context Management
- #007: Structured Outputs
- #008: Tool Calling
Coming next — #010: Agent Orchestration: Designing Reliable Multi-Step AI Workflows.
13. References and Further Reading
- Model Context Protocol — Introduction
- MCP — Official Specification
- MCP — Documentation and Developer Guides
- MCP — Official GitHub Organization
- MCP — Security Best Practices
MCP specifications, SDKs, transport guidance, and security practices evolve. Consult the latest official documentation before implementing production integrations.
Final Takeaway
AI Engineering — Active Concepts & Practices
Active Concept #009 — Model Context Protocol
AIYING — Accomplishing with AI
Understand → Connect → Apply → Accomplish
