AI Engineering Living Glossary #017 — Model Context Protocol (MCP): Connecting AI to Tools and Data

AI ENGINEERING | LIVING GLOSSARY | #017

MODEL CONTEXT PROTOCOL (MCP)

Standardizing Connections Between AI Applications and External Capabilities

Chapter 3: Connecting AI to Tools, Workflows, and Agents

Lesson 17 of 24

AIYING — Accomplishing with AI

Imagine an enterprise AI assistant that must answer:

"Find the latest customer support issues for Acme, check the relevant project documentation, and summarize what our team should investigate."

The information may be distributed across a customer relationship management system, a support platform, and a document repository.

Traditionally, engineers might build separate custom integrations for each system and each AI application.

What happens when another AI assistant needs the same integrations? Must the engineering team implement everything again?

Model Context Protocol (MCP) addresses this integration challenge by defining a common protocol through which compatible AI applications can discover and interact with external capabilities.

But interoperability is not the same as trust. A connection may be technically valid while still exposing the wrong data, invoking the wrong operation, or returning misleading information.

Central engineering insight: MCP standardizes how capabilities are exposed and accessed. The surrounding system remains responsible for security, authorization, correctness, and business outcomes.

Contents

1. What Is MCP?
2. Why MCP Matters
3. Core Components and Capabilities
4. How MCP Works
5. MCP vs Tool Calling, APIs, RAG, and Agents
6. MCP Engineering Architecture
7. Security and Trust Boundaries
8. Industry Applications
9. Engineering Design Decisions
10. Industry Case: Enterprise Support Assistant
11. Hands-On Mini Project
12. Connected Glossary Terms
13. Living Update
14. Key Takeaway
15. References

1. What Is MCP?

Model Context Protocol (MCP) is an open protocol that standardizes communication between AI applications and systems that expose external tools, information, and reusable prompts.

Its purpose is to reduce the need for application-specific integration interfaces.

Through MCP, a compatible AI application can discover capabilities exposed by an MCP server and use those capabilities according to the protocol and the application's permissions.

MCP is not itself an AI model, an agent, a database, or a workflow engine.

It is a communication and integration protocol.

Also, MCP does not automatically make an external connection secure. Secure deployment depends on transport protection, identity, authorization, trusted configuration, and appropriate operational controls.

↑ Back to contents

2. Why MCP Matters

AI applications increasingly need access to external information and software capabilities.

Without a common integration approach, each application may require custom code for every external service.

Integration challenge	What MCP can help with
Different connector interfaces.	A shared protocol for exposing capabilities.
Repeated integration development.	Potential reuse of compatible MCP servers.
Inconsistent capability discovery.	Standardized discovery mechanisms.
Different ways to invoke tools.	Common tool invocation structures.
Separate approaches to external context.	Standardized resource access.
Application-specific prompt libraries.	Reusable prompts exposed through servers.

These benefits are conditional. Applications must support MCP, servers must expose useful capabilities, and enterprise security requirements still need to be met.

Industry insight: Standardization can reduce integration friction, but it does not remove the need to engineer the underlying business integration.

↑ Back to contents

3. Core Components and Capabilities

A. MCP Host

The host is the AI application that manages the overall experience and its MCP connections.

Examples may include a compatible desktop AI application, development environment, or enterprise assistant.

B. MCP Client

The MCP client is a protocol component within the host that communicates with an MCP server.

A host can manage multiple client-server connections.

C. MCP Server

An MCP server exposes capabilities to connected clients.

It may wrap an existing API, database access layer, file system interface, or enterprise service.

D. Tools

Tools represent callable operations.

Examples:

• Search support tickets.
• Retrieve an order status.
• Create a draft support ticket.
• Query an approved business service.

Tool definitions include names, descriptions, and input schemas. Implementations may provide additional metadata.

E. Resources

Resources expose information that an application can read through defined resource interfaces.

Examples include documents, reference information, and other accessible content.

F. Prompts

Prompts expose reusable prompt templates or structured message content for supported applications.

G. Protocol messages

MCP uses structured communication, including JSON-RPC messages, to exchange requests, responses, and notifications.

H. Transport

Supported transports include local standard input/output communication and HTTP-based communication, depending on deployment and protocol version.

Remember: Host = application. Client = protocol connection component. Server = capability provider. Tools, resources, and prompts = different capabilities exposed through the protocol.

↑ Back to contents

4. How MCP Works

Consider a user asking an AI assistant to retrieve recent support tickets.

User Request
     |
     v
AI Application (MCP Host)
     |
     v
MCP Client
     |
     | Protocol communication
     v
MCP Server
     |
     v
Authorized Support API
     |
     v
Support Ticket Data
     |
     v
MCP Server Response
     |
     v
Host Validates and Processes
     |
     v
AI-Assisted User Response

Representative execution sequence

1. The host establishes a connection with a configured MCP server.
2. The client and server initialize their protocol session and negotiate supported capabilities.
3. The application discovers relevant tools or other exposed capabilities.
4. The user submits a request.
5. The application may provide suitable tool descriptions to the model.
6. The model may propose invoking a tool.
7. The host applies validation, policy, and authorization controls.
8. The MCP client sends an appropriate tool request to the server.
9. The server validates the request and performs its authorized underlying operation.
10. The result returns through the protocol.
11. The host treats the result as external data and processes it appropriately.
12. The model may use the result to produce a response.

The model does not directly gain unrestricted access to an enterprise system merely because an MCP server is available.

Actual access depends on the host, server implementation, identity, permissions, and the underlying service.

↑ Back to contents

5. MCP vs Tool Calling, APIs, RAG, and Agents

Concept	Primary purpose
API	Provides an interface to software or data capabilities.
Tool Calling	Allows a model to request an operation through an application.
MCP	Standardizes how compatible applications connect to exposed tools, resources, and prompts.
RAG	Retrieves relevant information to ground model responses.
Workflow	Coordinates a designed sequence or network of operations.
AI Agent	Uses model-guided decisions to pursue a goal.
Agent Orchestration	Coordinates agent execution, handoffs, and shared task state.

MCP can support several of these patterns.

For example, a RAG application may retrieve documents through an MCP resource or tool. An agent may use tools exposed by MCP servers. A workflow may invoke MCP-connected operations.

However, MCP does not itself perform retrieval ranking, manage an agent's goals, or orchestrate a complete business process.

↑ Back to contents

6. MCP Engineering Architecture

Consider an enterprise assistant connected to three systems.

       Enterprise AI Assistant
               (Host)
                  |
        +---------+---------+
        |         |         |
        v         v         v
     Client A  Client B  Client C
        |         |         |
        v         v         v
     MCP CRM   MCP Docs  MCP Support
      Server    Server     Server
        |         |         |
        v         v         v
     CRM API   Document   Ticket API
               Service

Cross-cutting controls:
Identity | Authorization | Validation
Audit | Monitoring | Error Handling

The host decides which servers to connect to and which capabilities are made available within its application.

Each server must protect access to its underlying systems.

Different servers may have different security requirements and data classifications.

The architecture should also define how the host handles unavailable servers, tool errors, and incompatible capability versions.

Important architectural boundaries

• Application-to-server communication.
• Server-to-underlying-service communication.
• Model-to-application tool requests.
• User identity and delegated permissions.
• External data entering the model context.

These boundaries should be evaluated separately rather than assuming that protocol compatibility provides end-to-end security.

↑ Back to contents

7. Security and Trust Boundaries

Server trust

Connect only to servers that have been appropriately assessed and approved. A malicious server may expose misleading descriptions, request excessive permissions, or return hostile content.

Authentication and authorization

Apply the authentication and authorization mechanisms appropriate to the transport, server, and underlying service. Do not treat discovery as authorization.

Least privilege

Expose only the capabilities needed for the user's legitimate task.

Consent and approval

Use clear confirmation and approval mechanisms for consequential operations.

Prompt injection

Tool descriptions, resources, documents, and tool outputs can carry untrusted instructions. The host must not automatically promote external content into higher-priority instructions.

Data minimization

Avoid transmitting unnecessary customer, employee, financial, or confidential information.

Credential handling

Protect access tokens and secrets. Avoid passing credentials into model prompts or exposing them through tool results.

Tool validation

Validate arguments, access scope, and operation-specific constraints at trusted execution boundaries.

Auditability

Record relevant connection, authorization, and execution events without unnecessarily exposing sensitive data.

Failure handling

Handle unavailable servers, timeouts, malformed responses, and uncertain execution results.

Security principle: A standardized connection is not a trusted connection by default. MCP integrations require the same disciplined security engineering as other external integrations.

↑ Back to contents

8. Industry Applications

Industry	Potential MCP-enabled capability
Customer support	Retrieve tickets and authorized customer information.
Software engineering	Access repositories, documentation, and approved development tools.
Sales	Query customer and opportunity records.
Human resources	Access permitted policy and employee service information.
Operations	Retrieve inventory and process status.
Knowledge management	Access approved documents and reference content.
Analytics	Invoke governed data-query capabilities.
Enterprise automation	Connect controlled workflow operations to AI applications.

These are architectural possibilities, not guarantees that a particular enterprise application provides an MCP server.

↑ Back to contents

9. Engineering Design Decisions

1. Does MCP provide a useful advantage over a direct API integration?
2. Which MCP hosts and clients will be supported?
3. Which servers are trusted and approved?
4. Which tools, resources, and prompts should be exposed?
5. Which capabilities are read-only?
6. Which capabilities can change enterprise data?
7. How will user identity and permissions be enforced?
8. How will credentials and secrets be protected?
9. What transport is appropriate for the deployment?
10. How will external data be validated?
11. How will prompt injection risks be addressed?
12. Which operations require human confirmation?
13. How will tool failures be detected and handled?
14. How will server versions and compatibility be managed?
15. How will integration quality be evaluated?
16. How will the organization monitor and audit usage?

Engineering principle: Standardize the interface where it creates value, while retaining explicit responsibility for the security and correctness of the integrated operation.

↑ Back to contents

10. Practical Industry Case: The Enterprise Support Assistant

Scenario: A fictional enterprise wants an AI assistant to investigate a customer's unresolved support issues.

The assistant needs access to three approved systems:

• CRM for customer account information.
• Document repository for product support guidance.
• Ticketing system for current incidents.

Proposed MCP architecture

The enterprise deploys or approves MCP servers that expose narrowly scoped capabilities for these systems.

The AI host connects to the relevant servers and discovers permitted operations.

Illustrative tools

crm.get_customer_summary
docs.search_support_guides
tickets.list_open_tickets

These are fictional tool names used for teaching. They are not standardized MCP tool names.

Execution sequence

1. The user asks for a summary of Acme's unresolved support issues.
2. The host verifies the user's identity and permitted customer access.
3. The application selects relevant approved capabilities.
4. The CRM tool retrieves an authorized customer summary.
5. The ticketing tool retrieves open support cases.
6. The documentation tool searches relevant support guidance.
7. The host validates returned structures and handles errors.
8. The AI model summarizes findings with references to available evidence.
9. The application avoids presenting unsupported recommendations as verified facts.
10. Any requested record modification follows separate authorization and approval controls.

Failure scenario A: Unauthorized customer access

The user requests records outside their assigned accounts.

The underlying authorization layer denies access even if the model requests the operation.

Failure scenario B: Untrusted document instructions

A retrieved support document contains text instructing the assistant to disclose unrelated customer information.

The application treats that text as untrusted document content, not as an authorized instruction.

Failure scenario C: Ticket server unavailable

The host reports that ticket information could not be retrieved rather than inventing a current ticket status.

Failure scenario D: Conflicting records

CRM and ticket data disagree on a customer identifier.

The assistant flags the inconsistency and avoids merging records without a reliable matching rule.

What this case demonstrates

MCP can simplify the interface between AI applications and external systems. It does not replace access controls, data quality checks, source verification, or operational accountability.

Industry insight: The value of MCP is interoperability. The value of AI engineering is making that interoperability useful, secure, and dependable.

↑ Back to contents

11. Hands-On Mini Project

Design a Read-Only MCP Support Server

Objective: Design or implement a simple MCP server that exposes fictional customer support information.

Use only synthetic data. No live enterprise credentials are required.

Step 1: Prepare sample data

Create five fictional support tickets with customer IDs, issue descriptions, statuses, and timestamps.

Step 2: Define capabilities

Design a read-only tool named get_ticket_status that accepts a ticket identifier.

Optionally expose a resource containing fictional support policy information.

Step 3: Define the tool schema

{
  "name": "get_ticket_status",
  "description": "Return the status of an authorized fictional support ticket",
  "inputSchema": {
    "type": "object",
    "properties": {
      "ticket_id": {
        "type": "string"
      }
    },
    "required": ["ticket_id"]
  }
}

This is an illustrative tool definition, not a complete MCP server implementation.

Step 4: Implement or simulate

Use an MCP-compatible SDK and local test environment, or document the request-response interactions if coding is not yet available.

Step 5: Apply authorization

Ensure the simulated user can retrieve only the tickets assigned to their fictional account.

Step 6: Test normal behavior

Request valid ticket statuses and verify the returned data against the sample dataset.

Step 7: Test failure behavior

• Unknown ticket ID.
• Missing required argument.
• Unauthorized ticket request.
• Simulated server timeout.
• Malformed result.
• Misleading text embedded in a ticket description.

Step 8: Evaluate

Metric	What to measure
Discovery success	Can the client identify the exposed tool?
Schema validity	Are tool arguments correctly structured?
Authorization enforcement	Are unauthorized requests denied?
Result fidelity	Do results match the fictional records?
Failure handling	Are unavailable or invalid results handled correctly?
Prompt injection resistance	Does hostile content remain untrusted data?
Latency	How long do simulated tool calls take?
Audit completeness	Are important operations traceable?

Success criteria

• The tool can be discovered by a compatible client.
• Valid requests return correct fictional data.
• Unauthorized requests are rejected.
• Invalid inputs do not trigger unintended operations.
• Untrusted ticket text does not override application instructions.
• Failures are communicated without fabricated results.

Reflection

What did MCP standardize? Which engineering responsibilities remained outside the protocol? Would a direct API integration be simpler for this particular application?

↑ Back to contents

12. Connected Glossary Terms

• Tool Calling (#013): Allows a model to request an operation that may be exposed through MCP.
• Workflows (#014): Can coordinate MCP-connected operations.
• AI Agents (#015): Can use MCP-exposed capabilities when supported by their host.
• Agent Orchestration (#016): Can coordinate agents that access tools through MCP.
• RAG (#004): Can retrieve information through MCP-connected resources or tools.
• Prompt Engineering (#006): Helps define model behavior when using external capabilities.
• Evals (#007): Tests tool use and end-to-end task outcomes.
• Grounding (#009): Connects responses to retrieved evidence.
• Guardrails (#010): Enforces security and operational restrictions.
• Observability (#011): Tracks tool execution and failures.
• Human-in-the-Loop (#012): Provides oversight for consequential actions.

Previous lesson: #016 — Agent Orchestration: Coordinating Agent Execution and Handoffs

Next lesson: #018 — Structured Outputs: Making AI Responses Machine-Readable and Verifiable.

↑ Back to contents

13. Living Update

Editorial baseline: November 2026

MCP is an evolving protocol ecosystem. Implementations should be checked against the applicable published specification and SDK versions rather than assuming that all hosts and servers support identical capabilities.

Areas to monitor include:

• Protocol version compatibility.
• Transport and authorization guidance.
• Server capability discovery.
• Tool, resource, and prompt interoperability.
• Enterprise server governance.
• Trusted server distribution and approval.
• Credential handling and delegated access.
• Prompt injection and tool-output security.
• Agent and workflow framework integration.
• Testing, tracing, and operational monitoring.

Living Glossary note: Review this entry when the MCP specification or relevant implementation guidance changes.

↑ Back to contents

14. Key Takeaway

MCP standardizes how compatible AI applications connect to external tools, resources, and prompts. Reliable MCP integration still depends on security, validation, authorization, and outcome verification.

MCP can make AI integration more reusable and interoperable.

But the goal is not merely to connect more systems. It is to expose the right capabilities to the right users under the right controls.

Think like an AI engineer: If an MCP server exposes a powerful tool, what prevents an unauthorized user or model-generated request from misusing it?

↑ Back to contents

15. References and Further Reading

• Model Context Protocol — Official Documentation
• Model Context Protocol — Specification
• MCP — Architecture
• MCP — Building a Server
• OWASP — Generative AI Security Project
• NIST — AI Risk Management Framework

↑ Back to contents

AI Engineering — Living Glossary

One Term. One Industry Connection. One Practical Insight. One Action.

AIYING — Accomplishing with AI

Chapter 3 | Lesson 17 | MODEL CONTEXT PROTOCOL

Understand the Term. Connect the Technology. Apply the Knowledge.

↑ Return to top