---
title: "Model Context Protocol: tools, resources and boundaries"
description: "Understand MCP clients, servers, tools, resources and prompts, plus the security and reliability controls an enterprise integration still needs."
canonical: "https://zephior.com/glossary/model-context-protocol"
last-updated: 2026-07-28
---

# Model Context Protocol: tools, resources and boundaries

> Understand MCP clients, servers, tools, resources and prompts, plus the security and reliability controls an enterprise integration still needs.

By [Tony Kim](https://zephior.com/authors/tony-kim). Published 2026-07-28; updated 2026-07-28. 6 minute read.

## Definition

The Model Context Protocol, or MCP, is an open protocol that lets an AI application connect to servers exposing tools, resources and reusable prompts through a standardized client-server interface.

## Problem

Teams can mistake a common connection protocol for a complete agent platform or security boundary. MCP can standardize discovery and invocation, but the application still owns user identity, authorization design, tool safety, business policy, result verification, observability and recovery.

## Point of view

MCP is most useful as an integration contract. It reduces bespoke connector work and allows clients and servers to evolve independently. Production quality still depends on the narrower contracts, permissions and operating controls placed around each exposed capability.

## MCP standardizes the connection, not the whole application

An MCP host is the AI application in which the user works. It creates one or more clients that connect to MCP servers. A server advertises capabilities such as tools, resources and prompts. Protocol negotiation lets the participants agree on a supported version and capabilities before those features are used.

The distinction between features matters. Resources expose context that the application can read, tools allow the model to request an operation, and prompts provide reusable interaction templates. The host decides how these capabilities appear to the model and user. Business workflow, memory and final authority can remain outside the protocol.

| Component | Primary job | Control question |
| --- | --- | --- |
| Host | Runs the AI experience and coordinates clients | Which user and policy govern the interaction? |
| Client | Maintains a protocol connection to one server | Which capabilities are accepted and exposed? |
| Server | Adapts data or actions into MCP capabilities | What system and authority sit behind it? |
| Resource | Provides context for the application to read | How is sensitive content scoped? |
| Tool | Offers an operation the model may request | What validates and approves the effect? |

## Enterprise adoption needs controls above and below MCP

Above the protocol, the host needs user consent, policy, approval, model evaluation and a clear display of proposed actions. Below it, the server and target system need authentication, scoped authorization, argument validation, safe transactions, logging and reconciliation. Neither side should assume that a well-formed protocol message is an authorized business instruction.

Treat third-party servers as software dependencies with access. Review their publisher, code or service controls, data handling, update path and incident response. Maintain an inventory of connected servers and capabilities. A protocol makes integration portable, which also makes controlled onboarding and removal more important.

- Bind tokens to the intended audience and never pass them through casually.
- Expose the smallest capability set required for the user and workflow.
- Confirm consequential tool calls before execution.
- Sanitize logs while retaining enough detail for audit and recovery.
- Re-evaluate behavior whenever tools, schemas, servers or models change.

## Workflow

1. **Define the business capability.** Start with the exact information or action the AI application needs. Describe the user, system of record, permitted scope and observable outcome. Decide whether the capability belongs as a resource to read, a tool to invoke or a prompt template to reuse.
2. **Choose client and server boundaries.** Identify which host controls the conversation and permissions, which MCP client maintains the server connection and which server adapts the underlying system. Keep trust boundaries and deployment ownership visible rather than treating every server as an interchangeable plugin.
3. **Constrain and validate the interface.** Use narrow operations, typed arguments, least-privilege credentials and explicit error states. Validate model-generated inputs against business rules. Separate read access from mutations and require approval before effects that are costly, external or hard to reverse.
4. **Test protocol and business behavior.** Test capability discovery, version compatibility, authorization, malformed requests, timeouts and partial failures. Then evaluate whether the agent chooses the right capability, supplies correct arguments and verifies the result in realistic and adversarial cases.

## Key decisions

- Should the capability be represented as a tool, a resource or an application-owned workflow step?
- Where are user identity and authorization enforced for each server and downstream system?
- Can a write operation be made idempotent and reconciled when its response is ambiguous?
- Which server metadata and tool descriptions are trusted as instructions by the AI application?
- Who reviews server updates, protocol versions and newly exposed capabilities?

## Risks

- A broadly described tool can give the model more authority than the user’s task requires.
- Untrusted resource or tool output can contain instructions that attempt to redirect model behavior.
- Token forwarding or weak audience validation can expose credentials beyond their intended server.
- A compatible server can still implement unsafe writes, poor isolation or inadequate audit records.
- Protocol success can be confused with business success when the final system effect is not reconciled.

## Metrics

- successful capability discovery and version negotiation by supported client
- tool calls rejected for invalid arguments, permissions or business policy
- end-to-end action success after reconciliation with the system of record
- duplicate effects prevented after retry or timeout
- security and regression cases passing for each server release

## Frequently asked questions

### Is MCP an API?

MCP is a protocol for how AI applications and capability servers discover and exchange tools, resources, prompts and related messages. A server may adapt existing APIs, databases or local functions behind that protocol. MCP does not replace every underlying business API.

### What is an MCP server?

It is a program or remote service that exposes capabilities through MCP. The capability may read data, provide a reusable resource or perform an action. Its safety depends on the implementation, credentials and target systems as well as the protocol.

### Does MCP make AI agents secure?

No protocol label provides that guarantee. MCP defines interoperable connection behavior and includes authorization mechanisms for applicable transports. The host, server and organization must still enforce identity, least privilege, approval, input validation, isolation, audit and recovery.


## Primary sources

- [MCP architecture overview](https://modelcontextprotocol.io/docs/learn/architecture), Model Context Protocol
- [MCP security best practices](https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices), Model Context Protocol