MCP: Model Context Protocol for Business

The MCP specification defines a shared protocol for applications that expose context and tools to AI systems. It uses JSON-RPC messages between a host application, a client connector and a server that provides capabilities.

The three roles

The protocol creates a common description and message flow. A company still builds or operates the server, controls credentials and decides which capabilities are exposed.

Tools, resources and prompts

• Resources provide context or data for a user or model to read.
• Prompts provide reusable message templates or workflows.
• Tools expose functions that a model may request, such as querying a system or performing an operation.

The distinction matters during procurement. A read-only resource has a different permission and review path from a tool that changes a record.

MCP and direct function calling

Function calling is a model-provider mechanism for returning a structured request to application code. MCP standardizes how compatible clients and servers describe and exchange capabilities. A team can use direct function calling for one application, or adopt MCP when several clients should reach a shared integration.

MCP reduces one class of integration duplication. It does not guarantee that every client supports every revision, extension or authorization flow.

What the current specification changes

The 28 July 2026 specification defines a versioned protocol, capability negotiation, resources, prompts, tools and optional extensions. It also describes consent, authorization, data privacy and tool-safety responsibilities for implementors. Check the supported protocol version and capabilities on both sides before a production migration.

Security remains a deployment decision

MCP does not decide which user may read a resource, invoke a tool or approve a change. The host should show the capability being used, obtain consent for data access and keep a human able to deny a tool invocation. Use least privilege, input validation, approval for consequential actions and an audit record.

Treat content returned from a document, email or web page as untrusted input. Instructions in that content must not expand server permissions or bypass the host's approval flow.

Decide whether MCP fits your systems

List the data and operations the AI application needs:

• systems and fields to read;
• operations that change records;
• clients that should share the integration;
• user, service and tenant permissions;
• approval and audit requirements;
• version and availability expectations.

MCP is a good candidate when shared capability discovery reduces repeated integration work. A direct integration is simpler when one application and one tool surface already meet the need.

A controlled MCP pilot

Read-only resource

Expose one narrow resource with test data and a documented schema. Review identity, access, retention and source freshness.

Tool discovery

Add one tool with a clear input schema, permission and visible confirmation. Test invalid input, unavailable service and denied invocation.

Client comparison

Connect a second compatible client only after the first path is understood. Compare capability negotiation, authorization and result handling.

Production decision

Keep the integration, permissions, logs and rollback documentation independent of any one host or model provider.

The MCP buyer decision

Adopt MCP when several compatible applications should use a shared, governed tool or resource layer. Use a direct integration when it offers a smaller surface and a clearer owner. In either case, security, authorization and monitoring remain part of the application architecture.

Discuss an AI integration architecture or see custom AI apps.