An MCP server is a standardized JSON-RPC 2.0 endpoint that exposes tools, resources, and prompts so AI agents can discover and call them reliably, introduced by Anthropic on November 25, 2024. It gives an AI application a consistent way to work with external systems instead of relying on a separate custom integration for every model and service.
A support team might recognize the problem immediately. A customer asks an AI agent to explain a billing issue, check the latest account record, update a ticket, and offer a meeting with an engineer. The agent needs access to a knowledge base, a support platform, an internal API, and a calendar. Without a shared interface, developers must wire each capability into the agent separately, define how it should be discovered, and maintain the integration as tools and models change.
MCP servers address that fragmentation, but calling them simple connectors misses the operational issue. The server is better understood as a governed tool gateway. It declares what an AI client can discover, what it can read, and what it can execute. That distinction matters for platform engineers and support leaders deciding whether an agent should merely answer questions or take actions in production.
The ecosystem has moved quickly. Community reporting cited more than 1,000 community-built MCP servers by February 2025, while independent summaries reported downloads growing from roughly 100,000 in November 2024 to more than 8 million by April 2025, an increase of about 8,000% (historical adoption reporting). The speed of that growth makes the basic question, what is MCP server, useful for more than developers experimenting locally. It now affects identity, permissions, observability, and change management.
Table of Contents
- Introduction to MCP Servers and Why They Matter Now
- What an MCP Server Actually Is in Simple Terms
- How MCP Servers Work Under the Hood
- Choosing the Right Transport for Your Deployment
- How AgentStack Uses MCP Servers to Power Support Agents
- Real World Examples of MCP Servers in Action
- What to Consider Before Deploying an MCP Server
Introduction to MCP Servers and Why They Matter Now
Consider a support agent handling a Slack thread. It first needs to retrieve a product article, then search a customer record, then call an endpoint that updates the ticket. If the customer's issue is complex, the agent may also need to schedule a meeting and escalate the conversation to a human.
A conventional implementation often embeds those decisions in application-specific code. The developer defines which API to call, how to format each request, what response fields matter, and which model is allowed to use each operation. That approach can work for a small workflow, but every new tool adds another contract to test and another integration path to secure.
An MCP server creates a common boundary. The AI host connects through an MCP client, and the server presents a structured catalog of available capabilities. The model can then work from declared tools, resources, and prompts rather than guessing how an underlying collection of APIs is organized.
Practical rule: Treat every exposed capability as part of your production interface, not as an informal shortcut for an AI model.
This guide is for developers building agent integrations, platform engineers designing deployment patterns, and support leaders evaluating automation beyond question answering. You'll learn what the server exposes, how JSON-RPC messages and transports fit together, how AgentStack uses MCP alongside its REST API, and which controls should exist before an agent can touch customer or business data.
The timing matters because MCP's specification and operating model are still evolving. The initial specification revision is dated 2024-11-05, and later revisions added capabilities including OAuth 2.1-based authorization and Streamable HTTP on March 26, 2025 (MCP history and specification context). Teams adopting the protocol should therefore evaluate not only whether an integration works today, but also how they'll handle authentication, versioning, auditability, and server ownership.
What an MCP Server Actually Is in Simple Terms
Think of an MCP server as a universal power adapter for AI applications. A normal adapter doesn't perform the work of the appliance. It gives different devices a predictable way to connect to an available power source. An MCP server similarly doesn't replace your CRM, search engine, calendar, database, or internal service. It presents selected capabilities from those systems through a protocol an AI host understands.
Before MCP, a team might build one integration for a particular model and another for a different AI application. Each integration could describe tools in its own way, handle context differently, and make separate assumptions about authentication and errors. The result is a collection of one-off connectors that become harder to test as the agent gains new responsibilities.
MCP changes the connection pattern:
- The server declares capabilities. It tells the client which tools, resources, and prompts are available.
- The client discovers those capabilities. An AI host can understand the interface without relying on undocumented endpoint knowledge.
- The model selects an appropriate capability. It can request a resource for context or invoke a tool for an action.
- The server enforces its boundary. The underlying system remains behind the server's implementation and permission decisions.
The important nuance is that “universal” doesn't mean unrestricted. A server might expose a read-only knowledge search while withholding ticket deletion, customer exports, or arbitrary code execution. That makes the server a deliberate policy surface, not merely a cable between an AI model and every system the company owns.
Teams exploring adopting autonomous AI agents often encounter this distinction quickly. An agent that can reason over information is one thing. An agent that can modify records, send messages, or initiate workflows needs a clearly defined action boundary.
An MCP server also isn't the same thing as an API. An API usually describes direct application-to-application communication, while MCP supplies an AI-oriented discovery and invocation layer around tools, data, and reusable interaction patterns. You can build an MCP server on top of existing APIs, but the server determines which operations become understandable and usable by an AI client.
How MCP Servers Work Under the Hood
At the protocol level, an MCP server exposes three core primitives. Each primitive represents a different relationship between an AI client and the external system.
Tools, resources, and prompts
Tools are executable functions. A support MCP server might offer a search operation, a ticket update action, or a meeting-booking function. A tool includes enough declared information for the client to understand what it does and what inputs it accepts.
Resources are readable information. They might represent documents, files, structured records, or other data that gives an agent context. A resource isn't necessarily an action. It helps the model understand the customer's question, product behavior, or current state before it decides whether an action is appropriate.
Prompts are reusable interaction templates. They can guide a client toward a particular workflow, such as preparing a support reply, reviewing a conversation, or performing a structured investigation. Prompts don't replace the model's reasoning, but they provide a consistent starting pattern.
All client-server messages must conform to JSON-RPC 2.0, according to the MCP basic protocol specification. That requirement gives requests, results, errors, and identifiers a known structure. The server isn't handing an AI an unstructured menu of endpoints. It participates in a message protocol with defined expectations.
Capability negotiation creates a typed boundary
During initialization, the client and server negotiate capabilities. The client learns what the server supports, while the server can account for the client's declared features. After that exchange, the client calls only features the server has explicitly made available.
This is why MCP is structurally closer to a typed tool and data gateway than to a generic REST API. A REST endpoint might exist, but the model still needs a useful description of its purpose, parameters, response behavior, and appropriate use. MCP makes those capabilities part of the protocol interaction.
For developers, the result is a more deterministic path:
- The host creates or manages an MCP client.
- The client initializes a connection to the server.
- The server declares supported primitives and capabilities.
- The client discovers available tools, resources, or prompts.
- The model chooses a permitted operation.
- The server validates the request and returns a structured result or error.
AgentStack documents its developer-facing MCP server and available integration patterns in its MCP server documentation. The implementation details still matter, but the protocol gives the client a repeatable way to discover what the server offers.
Choosing the Right Transport for Your Deployment
MCP currently supports two standard transport bindings, both carrying UTF-8-encoded JSON-RPC messages (transport specification). The choice isn't cosmetic. It affects where the server runs, how the client launches it, how traffic crosses network boundaries, and what operational controls your team must provide.
| Transport | Best For | How It Works | Trade Off |
|---|---|---|---|
| stdio | Local tools and embedded integrations | The client launches the server as a subprocess. The server reads from standard input and writes to standard output. | Simple and low overhead, but it isn't designed as a remote, shared service. |
| Streamable HTTP | Remote, multi-tenant, or internet-facing deployments | Each message travels through HTTP POST to a single endpoint. Responses can be JSON or request-scoped SSE streams. | Easier to operate as a network service and supports streaming, but requires serious identity, authorization, and network controls. |
When stdio fits
Use stdio when the AI application and server live on the same machine or inside the same controlled process environment. A local developer tool can launch a server, exchange messages through stdin and stdout, and avoid exposing an externally reachable endpoint.
That simplicity comes with boundaries. Teams must manage the subprocess lifecycle, local credentials, package updates, and the permissions of the user or service account that launches the process. A local server can still be dangerous if it exposes file access or commands more broadly than the developer expects.
When Streamable HTTP fits
Streamable HTTP is the natural choice when multiple clients need access to a shared service, when the server runs remotely, or when responses may arrive incrementally. A single HTTP endpoint also fits familiar infrastructure for routing, observability, rate controls, and identity enforcement.
It isn't automatically secure because it uses HTTP. The deployment still needs authentication, authorization, input validation, logging, and careful separation between tenants. AgentStack's MCP integration guide is a useful place to examine how an MCP connection fits into an application workflow.
Choose based on the trust boundary, not convenience. A local prototype may begin with stdio, while a production support platform usually needs the operational discipline of a managed remote service.
How AgentStack Uses MCP Servers to Power Support Agents
AgentStack's platform combines knowledge ingestion, model orchestration, customer-facing delivery, analytics, and developer access. Its MCP server fits into that stack as a programmatic interface for AI-compatible clients, while its REST API v1 provides a conventional application interface for developers and dashboards.
The flow starts with information. Teams can ingest website and document content, synchronize Notion material, upload common business files, and add question-and-answer pairs. The platform chunks and indexes that material so a support agent can retrieve relevant context instead of treating every conversation as an isolated prompt.
The agent then needs to do more than retrieve an answer. A customer may need a ticket update, a web search, a meeting booking, lead capture, or escalation. AgentStack's action and integration layer provides those kinds of workflow capabilities, while its MCP server gives compatible clients a standardized way to discover and use the exposed functions.
Where the interfaces differ
A platform engineer might use the REST API to create an application integration, synchronize configuration, or connect a web dashboard. An AI client might use the MCP server to discover available agent data and operations through the protocol's declared capabilities.
AgentStack's developer tooling includes an organization-scoped MCP endpoint at /api/mcp, with a read-only variant that exposes only data-reading tools. MCP-compatible clients can connect to read agents, sources, and conversations, and can perform supported administrative operations such as creating agents, running tests, and adding sources. Those capabilities should still be evaluated against the organization's permission model before they're connected to an autonomous workflow.
The architecture separates several concerns:
- Knowledge preparation supplies source material for retrieval.
- Model routing selects among available models based on the task.
- MCP and REST interfaces provide different ways for software and AI clients to interact with the platform.
- Omnichannel delivery carries responses through website chat, email, Slack, or voice.
- Analytics and shared inbox workflows provide review, escalation, and operational visibility.
Developers can use AgentStack's MCP client documentation when connecting compatible clients. The key design question isn't whether MCP replaces every other interface. It's where an AI-native discovery layer improves access while the REST API remains the better fit for deterministic application code.
Real World Examples of MCP Servers in Action
The clearest way to understand an MCP server is to follow a support request from question to action. In each example, the model doesn't receive unrestricted access to an entire business system. It receives a defined set of capabilities through the server.
Resolving a product question in Slack
A customer asks whether a feature supports a particular workflow. The agent can retrieve a relevant documentation resource, inspect the conversation context, and draft an answer grounded in the available material.
The server might expose a document-search tool and readable knowledge resources. The model decides which resource is relevant, receives the result in the expected format, and responds in Slack without the support application needing a custom tool contract for every model.
Updating a ticket after diagnosis
A customer reports an error, and the agent finds the troubleshooting instructions in an indexed document. Once the customer confirms the fix, the agent can invoke a ticket-update tool.
The important control is the separation between reading and writing. The knowledge resource helps the model diagnose the issue, while the update tool performs a consequential action. A production server should validate the ticket identifier, constrain writable fields, and require whatever confirmation policy the support team has established.
A meeting-booking workflow illustrates the same pattern. The agent reads the customer's context, invokes a booking tool with structured inputs, and returns the result to the conversation. The model shouldn't need to know the calendar provider's private endpoint structure.
This video provides another practical view of MCP server operations and client interaction:
The ecosystem's growth has made these patterns easier to find and reuse. Reference servers have been built for systems including Google Drive, Slack, GitHub, Git, and Postgres (community ecosystem reporting). That variety is useful for experimentation, but it also means teams must inspect ownership, permissions, update practices, and data handling before connecting a third-party server to production systems.
What to Consider Before Deploying an MCP Server
MCP isn't plug-and-play infrastructure. The server sits at a trust boundary between a model and systems that may contain customer records, internal documents, credentials, or operational controls.
Independent security reporting found that 72% of MCPs expose sensitive capabilities, including dynamic code execution, file-system access, or privileged API calls. The same reporting found that 13% accept untrusted inputs, such as web scraping, Slack, email, or RSS feeds, and that when those conditions combine, 9% of real-world setups can become direct paths for prompt injection, command execution, and data exfiltration (security analysis of MCP deployments).
Those findings change the deployment question. Don't ask only whether an MCP server can perform a useful action. Ask what happens when hostile content reaches the model, whether the model can reach a privileged tool, and how the organization will reconstruct an incident afterward.
A minimum governance checklist
- Reduce capability scope: Expose only the tools and resources required for the workflow. Prefer read-only access where writing isn't necessary.
- Separate identities: Give the server a dedicated service identity instead of sharing a broad human credential.
- Validate every input: Treat model-generated arguments as untrusted input, even when the model appears confident.
- Require authorization: Use explicit permissions for sensitive operations, and consider human approval for irreversible actions.
- Record activity: Capture tool calls, requesting identity, inputs, results, failures, and policy decisions in exportable audit logs.
- Test hostile content: Include prompt-injection attempts, poisoned documents, malformed arguments, and unexpected tool responses in evaluation.
- Plan for change: Track protocol revisions, dependency updates, credential rotation, and rollback procedures.
Enterprise readiness is also evolving. Recent coverage says the official registry has surpassed 10,000 servers, while the 2026 roadmap identifies audit trails, SSO-integrated authentication, gateway behavior, and configuration portability as enterprise pain points (MCP ecosystem and roadmap coverage). Security guidance increasingly emphasizes OAuth 2.1 and PKCE, while one ecosystem study reported that only 8.5% of surveyed servers used OAuth, showing the gap between recommended patterns and deployed practice (MCP security guidance).
An MCP server is production-ready only when the surrounding controls are ready too. Start with a narrow, observable use case, use a read-only mode where possible, and expand permissions only after testing the actual workflow.
AgentStack provides an MCP server and REST API v1 for connecting support-agent capabilities to compatible clients and applications, alongside knowledge ingestion, omnichannel delivery, analytics, and escalation workflows. Visit AgentStack to evaluate how a governed MCP integration could fit your support architecture and begin with a narrowly scoped deployment.