AI Engineering Active Concepts #009 — Model Context Protocol (MCP): Connecting AI to Tools and Data

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

1. Why MCP Matters
2. UNDERSTAND — What Is MCP?
3. CONNECT — Related Engineering Concepts
4. MCP Architecture and Lifecycle
5. APPLY — Enterprise Procurement Integration
6. Worked Example: Purchase Order Lookup
7. Engineering Decisions and Trade-offs
8. Active Industry Practices
9. ACCOMPLISH — Design an MCP Integration
10. Student and Practitioner Project
11. Check Your Understanding
12. Active Connections
13. 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.

MCP standardizes the interface between compatible AI applications and external capabilities. It does not eliminate the need to implement, secure, and maintain the underlying integrations.

↑ Back to Contents

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.

↑ Back to Contents

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.

↑ Back to Contents

4. MCP Architecture and Lifecycle

Enterprise AI Assistant — MCP Host

↓

MCP Client

↓ Protocol Communication

MCP Server

↓

Enterprise API / Database / Service

↓

Authorized Result

↓

AI Application

Step 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.

↑ Back to Contents

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.

↑ Back to Contents

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.

↑ Back to Contents

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.

MCP standardizes connectivity. Security, trust, and governance must still be engineered around every connection.

↑ Back to Contents

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.

↑ Back to Contents

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

1. Identify the capabilities each AI application needs.
2. Decide which capabilities should be tools and which should be resources.
3. Design an MCP server architecture.
4. Define a purchase-order lookup tool and its input schema.
5. Specify how user permissions should be enforced.
6. Identify operations requiring approval.
7. Describe how errors and unavailable services should be handled.
8. 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.

↑ Back to Contents

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

1. Create a small fictional purchase-order dataset.
2. Choose a compatible MCP SDK.
3. Implement a read-only purchase-order lookup tool.
4. Define and validate tool input parameters.
5. Expose a sample procurement-policy resource.
6. Connect using a compatible MCP client or inspection tool.
7. Test capability discovery.
8. Test successful and unsuccessful tool invocations.
9. Check that unauthorized or invalid requests are rejected.
10. 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.

↑ Back to Contents

11. Check Your Understanding

1. What problem does MCP address in AI engineering?
2. What is the difference between an MCP host, client, and server?
3. How do MCP tools differ from resources and prompts?
4. How is MCP different from a conventional API?
5. How does MCP relate to model tool calling?
6. Does MCP automatically enforce enterprise authorization?
7. What risks arise from connecting untrusted MCP servers?
8. 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?

↑ Back to Contents

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.

↑ Back to Contents

13. References and Further Reading

1. Model Context Protocol — Introduction
2. MCP — Official Specification
3. MCP — Documentation and Developer Guides
4. MCP — Official GitHub Organization
5. MCP — Security Best Practices

MCP specifications, SDKs, transport guidance, and security practices evolve. Consult the latest official documentation before implementing production integrations.

---

Final Takeaway

MCP helps make external tools, data, and reusable prompts accessible through a common protocol. Effective AI engineering combines this interoperability with explicit security, authorization, validation, and operational accountability.

AI Engineering — Active Concepts & Practices
Active Concept #009 — Model Context Protocol

AIYING — Accomplishing with AI

Understand → Connect → Apply → Accomplish