Appendix D from The AI Contact Center Handbook by Sho Shimoda. Available on Amazon.
Who this appendix is for
This appendix is written for the technical reader — the platform engineer, the AI developer, the CX architect — who is going to build or integrate the agentic AI systems this book has discussed. Readers who are not in that role can safely skip it. Readers who are will find this a starting map of the specific integration surface the industry has converged on in 2025 and 2026.
D.1 What is the Model Context Protocol?
The Model Context Protocol — MCP — is an open specification, first published by Anthropic in November 2024, that standardizes how AI models connect to external tools, data sources, and systems.
Before MCP, every integration between an AI model and an external system was custom. If you wanted your AI agent to read from Salesforce, you wrote Salesforce-specific code. If you also wanted it to read from Zendesk, you wrote Zendesk-specific code. If you switched from Claude to GPT-4, you rewrote both. The N-by-M problem — N models times M systems — meant that any nontrivial AI deployment was mostly integration code, and any change to either side broke things.
MCP solves this the same way USB solved peripheral connections. It defines a common interface — a small, well-specified protocol — that any AI client can implement to talk to any MCP server. The N-by-M problem becomes N-plus-M.
The core primitives of MCP are three: Tools (functions the AI can invoke), Resources (data the AI can read), and Prompts (reusable prompt templates the server exposes). The protocol runs over standard transports — stdio for local processes, HTTP with server-sent events for remote services. Authentication is handled at the transport layer (OAuth 2.1, API keys, mTLS). The message format is JSON-RPC, chosen because it is boring, well-understood, and works everywhere.
Adoption in the AI industry has been rapid. As of mid-2026, MCP is implemented natively by Anthropic's Claude, OpenAI's models via first-party server support, Google's Gemini, Microsoft's Copilot Studio, and every major open-source model runtime.
D.2 Curated MCP Server Integrations by Category
The MCP ecosystem in 2026 includes several hundred publicly available servers, plus many more that enterprises build for internal systems. The list below covers the ones most directly relevant to contact center and CX use cases.
File systems and document repositories
| Server | Status | Contact center use |
|---|---|---|
| Google Drive | Official | Access to policy documents, product specs, or shared knowledge that lives in Drive rather than a formal KB. |
| OneDrive / SharePoint | Official (Microsoft Graph) | Enterprise-critical for Microsoft 365 shops. Most operational documents and shared workspaces live here. |
| Box | Community | Collaboration, retention, legal hold on top of standard file operations. Regulated industries. |
| Dropbox | Community | Simpler feature surface; useful for smaller organizations. |
| Filesystem (local) | Reference | Local files; heavily used in development, rarely in production. |
Customer relationship management (CRM)
| Server | Status | Contact center use |
|---|---|---|
| Salesforce | Official (2025, w/ Agentforce) | Contacts, Accounts, Cases, Opportunities, custom objects. Also Flow invocation — AI triggers existing automations. |
| Zendesk | Official (early 2026) | Tickets, users, organizations, KB articles. Ticket routing and macro invocation specifically tooled. |
| HubSpot | Official | Full CRM/marketing/service coverage. Strong in SMB and mid-market. |
| Dynamics 365 | Official (Microsoft Graph) | Customer Service, Sales, Field Service. Deep Microsoft 365 integration. |
| ServiceNow | Official | Incidents, requests, changes, problems, CMDB. Critical for hybrid customer/employee support. |
Developer workflows and knowledge
| Server | Status | Contact center use |
|---|---|---|
| GitHub | Official | Technical support — search issue trackers, look up commits, reference documentation. Table stakes for B2B SaaS support. |
| Jira | Official (Atlassian) | Support-to-engineering handoffs, especially in software companies. |
| Linear | Official | The Linear-native alternative to Jira; modern startups and mid-market software. |
| Confluence | Official (Atlassian) | Wiki content. The go-to KB for many enterprises. |
Communication and collaboration
| Server | Status | Contact center use |
|---|---|---|
| Slack | Official | Escalate to human specialists via channels, look up prior discussion, post ops updates. |
| Microsoft Teams | Official (Graph) | Microsoft-stack counterpart to Slack. Chat, channel, meeting operations. |
| Discord | Community | Community-support contact centers (gaming, crypto, developer relations). |
Data platforms and analytics
| Server | Status | Contact center use |
|---|---|---|
| PostgreSQL | Reference + community | Direct SQL access. Query operational data — case counts, agent metrics, customer profiles — without a purpose-built API layer. |
| MySQL / MariaDB | Community | Similar functionality to Postgres reference. |
| Snowflake | Official | Analytical data — customer lifetime value, historical trends, cohort analysis. |
| Databricks | Official | Notebook execution, table queries, job triggering. |
| BigQuery | Official (Google) | BigQuery-standardized enterprises. |
Specialized CX and operations
| Server | Status | Contact center use |
|---|---|---|
| Twilio | Official | Send SMS, initiate voice, look up numbers, manage phone pools. Exposes the underlying comms layer to the AI. |
| SendGrid | Official | Email send, templates, delivery stats. AI-agent equivalent of a marketing automation trigger. |
| Stripe | Official | Payment ops, subscription management, refund processing. What enables an AI agent to actually issue the refund it authorizes. |
| Notion | Official | Pages, databases, blocks. Common KB and process documentation in modern operations. |
| Airtable | Official | Base and record operations. Widely used for the ad-hoc databases that grow up around CX teams. |
Identity, access, and search
| Server | Status | Contact center use |
|---|---|---|
| Okta | Community (formalizing 2026) | User lookup, group membership, session mgmt. Employee identity verification. |
| Auth0 | Official | Customer identity rather than employee identity. |
| Elasticsearch | Community | Full-text search over the internal KB the AI actually queries. |
| Algolia | Official | Managed search-as-a-service; common for public docs. |
| Glean | Official (2026) | Enterprise search across Drive, SharePoint, Confluence, Notion, Slack. For AI agents that need to search the full corporate surface. |
D.3 Patterns for Composing MCP Servers
Beyond the individual server catalog, three architectural patterns are worth naming.
| Pattern | How it works | Best for |
|---|---|---|
| Gateway | Single MCP gateway presents a curated tool/resource surface to the AI, while internally routing to backends. Handles authentication, authorization, audit logging, rate limiting. | Large enterprises — centralizes security and observability. Most common in production. |
| Service mesh | Multiple MCP servers deployed alongside each other, with a discovery layer that lets the AI find and invoke the right one. | Organizations with strong platform engineering that prefer distributed architectures. |
| Vertical | A single MCP server dedicated to a specific business process (e.g., "the refunds server") exposing only the four or five tools that process needs. | Well-defined, high-frequency operations. Simpler to reason about, easier to secure. |
Most production deployments end up using some mix. The gateway handles cross-cutting concerns. Vertical servers handle high-frequency business processes. And a small number of direct integrations serve specialized cases that do not fit either.
D.4 Building Your Own MCP Server
Sooner or later every contact center engineering team decides that some internal system needs its own MCP server. A working sketch of what building one looks like.
| Discipline | What it looks like in practice |
|---|---|
| Start with the tool contract, not the model | Before writing code, write out the specific functions the AI needs to invoke — inputs, outputs, error modes, side effects. "Give the AI access to billing" is not a tool contract; initiate_refund(case_id, amount, reason_code) returning a confirmation ID is. This exercise typically reveals gaps in the underlying system's API that need to be closed first. |
| Auth is a decision, not a default | Service account? Machine identity? On-behalf-of-user? Each has trade-offs for audit and blast radius. Service account plus specific role scoped to just the operations the AI needs is most common; solve for the audit-attribution problem with explicit context propagation. |
| Idempotency matters more than in normal API design | AI systems retry. LLMs sometimes generate the same tool call twice due to hallucination or transient errors. Every action should be idempotent. For actions that inherently cannot be (payment execution, message send), require an explicit idempotency token from the caller. |
| Return errors the model can reason about | A raw HTTP 500 tells the model nothing. A structured error like {"error": "insufficient_permissions", "required_role": "refund_authorizer", "customer_message_suggestion": "This action requires manager approval..."} gives the model a chance to recover gracefully. |
| Rate limit, and mean it | A misbehaving AI can generate hundreds of tool calls per second. Prefer per-session limits (so one runaway does not starve legitimate traffic) plus overall throughput caps. |
| Log everything — including the AI's reasoning if you can capture it | Full parameters, full response, latency, session identifier, and (when available) the model's stated reason for making the call. This log becomes the primary source of truth when a production incident is investigated. |
| Test with adversarial inputs | Every MCP server will eventually be called with parameters no human would supply — negative amounts, strings where numbers were expected, injection attempts. Fuzz-test before shipping. |
How to use this appendix
Use D.1 to explain MCP to an executive stakeholder. Use D.2 as the initial shortlist when planning your integration surface — pair it with what your organization already runs. Use D.3 to pick the architectural pattern before you start deploying servers. Use D.4 as a pre-shipping checklist for any server your team builds.