What is Model Context Protocol (MCP)?
Written By
Sarwat Iftikhar
AI assistants are no longer isolated tools. They read from databases, execute code, call external services, and take actions in external systems on behalf of users. Each of those integrations historically required custom engineering work: a bespoke adapter connecting one AI platform to one data source, repeated for every combination of tool and service a team wanted to expose.
Model Context Protocol (MCP) replaces that custom-adapter approach with a standard interface. A developer building an MCP server for a database exposes it once, and any MCP-compatible AI application can connect to it. A developer building an MCP-compatible AI host integrates the protocol once, and any MCP server becomes available to it. The integration surface collapses from a many-to-many problem to a single standard that each side implements once.
This post covers what MCP is, how the protocol architecture works, what capabilities it exposes to AI agents, and what the security surface looks like when those agents connect to external systems through it. For security teams evaluating AI deployments and developers building MCP infrastructure, understanding the trust model is as important as understanding the functionality.
Key Takeaways
- MCP is an open protocol that standardizes how AI models connect to external tools, data sources, and services through a common interface.
- The protocol defines three primitives: tools (executable functions), resources (readable data), and prompts (reusable instruction templates).
- MCP servers are trust boundaries: every server an AI agent connects to can influence what the agent reads, executes, and produces.
- The attack surface MCP introduces includes prompt injection via tool responses, overprivileged tool scope, supply chain risk from third-party servers, and missing authentication controls.
- AI deployments that include MCP connections require the same security assessment discipline as web applications and APIs.
What Problem Does MCP Actually Solve?
Before MCP, connecting an AI assistant to an external service required building a custom integration for each combination of AI platform and data source. A team with three AI tools and five data sources needed up to fifteen custom integrations, each maintained independently, with no shared patterns for authentication, error handling, or capability description.
MCP addresses this with a protocol that standardizes the interface. An MCP server describes its capabilities once in a structured schema. Any MCP-compatible host can read that schema, understand what the server offers, and make its capabilities available to the AI model it runs. The integration count drops from the product of the two sets to their sum: each side builds to the standard once.
Released as an open standard in late 2024, MCP has since been adopted across AI development environments, coding assistants, and agentic application frameworks. The adoption curve reflects a real infrastructure need: as AI applications move from answering questions to taking actions, the set of external systems they need to connect to grows quickly, and a standard interface significantly reduces the integration overhead on both sides.
How Does the MCP Architecture Work?
MCP defines three roles: the host, the client, and the server. Understanding how these interact is the foundation for understanding both what MCP enables and where its security boundaries sit.
| Component | Role | Example |
| MCP Host | The AI application that manages user interaction | A coding assistant, AI agent, or chat interface |
| MCP Client | The protocol handler inside the host | The component that speaks MCP to connected servers |
| MCP Server | The external service that exposes capabilities | A database connector, file system adapter, or API wrapper |
Host. The host is the AI application: a coding assistant, a chat interface, or an autonomous agent framework. It is the process the user interacts with. The host instantiates one or more MCP clients to connect to external servers and makes the servers’ capabilities available to the AI model it runs.
Client. The client lives inside the host application and handles the protocol mechanics: connecting to servers, requesting capability listings, forwarding tool calls, and returning responses to the model’s context. The client is the component that speaks MCP on behalf of the host.
Server. The server is an external process or service that exposes capabilities through the MCP interface. It declares what tools, resources, and prompts it provides, handles requests from connected clients, and returns structured responses. A server can be a local process on the same machine or a remote service accessed over HTTP. The security properties of the server, and the trust the host extends to it, are the central security concern in any MCP deployment.
What Are the Three MCP Primitives?
Every MCP server exposes its capabilities through three primitive types. These are the building blocks from which MCP integrations are assembled, and each carries different security implications depending on what the server exposes and what level of access it requires.
Tools are executable functions the AI model can invoke. A tool might run a database query, execute a shell command, call an external API, or write a file. Tools return structured output that the model incorporates into its context and uses to inform subsequent responses or actions. Because tools execute code with real effects in external systems, their scope and permissions are the highest-stakes design decision in any MCP server. In Bugstrix’s assessment work, tools with broad execution scope are the most common source of high-severity findings in MCP server implementations: a tool designed to read configuration files that also exposes write and delete operations provides unnecessary attack surface in any deployment.
Resources are data sources the AI model can read. A resource might be a file, a database table, a log stream, or an API response. Unlike tools, resources are read operations: they add data to the model’s context without executing actions. The security consideration is what data is reachable through the resource and what gets loaded into model context as a result.
Prompts are reusable instruction templates the server exposes. A server might provide a prompt template for a common workflow, which the host can use to construct requests in a consistent, server-recommended format. Prompts are the lowest-risk primitive in terms of system access, though they can influence model behavior if an attacker controls their content.
What Security Risks Does MCP Introduce?
MCP connects AI models to external systems with real execution capabilities. Every MCP server an AI agent connects to becomes a potential influence point on the agent’s behavior: it can supply data the model reads, content the model interprets, and function return values the model incorporates into its reasoning. Bugstrix security assessments of AI-integrated environments consistently find that teams deploying MCP focus heavily on functionality and underinvest in assessing the trust model of the servers they connect to.
Prompt injection via tool responses. An MCP server controls what its tools return. If an attacker can influence the content of a tool response, they can inject instructions that the AI model processes as legitimate guidance. A web scraping tool that returns the content of an attacker-controlled page, a database tool that returns user-supplied text, or a file reading tool whose target file has been modified are all potential injection paths. The AI model cannot reliably distinguish between data returned by a tool and instructions from a trusted system prompt.
Overprivileged tool scope. MCP servers that expose file system write access, code execution, or external API calls with broad permissions create a significant blast radius if the AI agent is manipulated or makes an error. The principle of least privilege applies directly: tools should expose the minimum access required for the task, not the maximum access available to the server process. Applying cybersecurity code review to MCP server implementations regularly surfaces permission scope that was set during development and never reduced for production deployment.
Supply chain risk from third-party servers. The MCP ecosystem includes a growing registry of community-maintained servers. An organization that installs and connects a third-party MCP package is extending trust to that package’s code and its maintainers. Software supply chain security practices apply directly: verify the provenance of any MCP server before connecting it to a production AI deployment, and treat unmaintained or unvetted packages the same way you would any other unverified third-party dependency.
Authentication and authorization gaps. Many MCP server implementations default to unauthenticated connections, treating any connecting client as trusted. Remote MCP servers without proper authentication allow any client that can reach the endpoint to invoke their tools and read their resources. Strong identity and access management for MCP connections should enforce which clients can connect, which tools each client can invoke, and what data scope each tool call is authorized to access.
Context exfiltration through chained tool calls. When an AI agent reads sensitive data through one MCP tool and then makes subsequent tool calls, that data travels in the agent’s context. A compromised or malicious MCP server encountered later in a session can observe or manipulate what the agent produces in response to its tool returns, exfiltrating context accumulated from earlier in the session.
How Does MCP Relate to API Security?
Remote MCP servers communicate over HTTP using JSON-RPC 2.0. From a network and protocol perspective, a remote MCP server is a web API: it accepts requests, validates inputs, executes logic, and returns structured responses over standard HTTP transport. The full body of web application and API security practice applies to its design and deployment.
API security testing for MCP servers covers the same test categories as any other API: authentication and session management, authorization and access control, input validation against the JSON-RPC payload, rate limiting, error handling that does not leak server internals, and transport security. The MCP schema that describes available tools also requires assessment: a schema that misrepresents tool behavior or exposes internal implementation details is itself a security signal worth investigating.
Web application penetration testing of MCP server deployments maps the exposed tool and resource endpoints, tests authentication bypass and privilege escalation paths, and evaluates the server’s behavior under malformed or malicious input. Bugstrix applies the same structured methodology to MCP server assessments as to conventional web API testing, extending it to cover the protocol-level behaviors specific to the MCP specification, including tool schema integrity and the prompt injection paths that tool responses introduce.
What Should You Review Before Deploying MCP Servers?
Organizations deploying MCP servers in production should assess three areas before connecting AI agents to them: the server code itself, the deployment environment, and the ongoing configuration of tool permissions.
Code-level review. MCP server code defines what tools are exposed, what permissions those tools use, how inputs are validated, and how errors are handled. A secure code review of the server implementation surfaces injection risks in tool handlers, overprivileged file system or API access, missing input validation on tool parameters, and error paths that expose internal state. Bugstrix code review assessments of MCP server implementations apply the same structured methodology used for any web application backend, adapted to the specific security properties of protocol-level tool handlers.
Deployment and cloud configuration. Remote MCP servers deployed in cloud environments inherit the security properties of that deployment: network access controls, identity-based access to downstream services, secret management for the credentials the server uses, and logging coverage for the tool calls the server handles. Cloud security assessment for MCP deployments covers the full deployment surface, not just the application code.
Tool permission scope. Before deployment, each tool’s required permissions should be reduced to the minimum necessary for its function. A tool that reads from a database should not have write access. A tool that executes a fixed set of commands should not have arbitrary shell execution. Permission scope should be reviewed at deployment and audited periodically as the server’s capabilities evolve.
Frequently Asked Questions
What is Model Context Protocol?
Model Context Protocol is an open standard that defines how AI models communicate with external tools, data sources, and services. It provides a common interface that replaces custom per-integration adapters: developers build to the protocol once, and any compatible host or server can interoperate with any other. The protocol defines three primitives (tools, resources, and prompts) and supports both local and remote server deployments over stdio and HTTP transports.
Is MCP secure by default?
No. MCP is a protocol specification, not a security framework. Security properties depend entirely on how individual servers are implemented and deployed. Bugstrix’s review of community MCP server implementations consistently finds authentication gaps and overprivileged tool scope in production deployments. A server that lacks authentication, exposes overprivileged tools, or fails to validate tool inputs is insecure regardless of whether it correctly implements the MCP specification. Security must be designed into each server implementation.
What is the difference between MCP tools and resources?
Tools are executable functions that take action: they query a database, call an API, write a file, or execute code. Resources are readable data sources: they return content from a file, a database row, or a service response. Tools carry higher security risk because they have real-world effects; resources carry risk through what data they expose and load into model context.
Can MCP servers be penetration tested?
Yes, and they should be before production deployment. Remote MCP servers are HTTP APIs and are testable using standard web application penetration testing methods: mapping exposed endpoints, testing authentication and authorization controls, evaluating input handling in tool parameter processing, and checking transport security. The MCP-specific testing layer adds assessment of tool schema integrity and prompt injection paths through tool response content.
How does MCP handle authentication?
The MCP specification defines an authorization framework for remote servers based on OAuth 2.1, which provides token-based access control for client connections. Local servers using stdio transport operate in the same security context as the host process and rely on OS-level process isolation rather than network authentication. In practice, many community MCP server implementations do not yet fully implement the authorization specification, and organizations deploying remote servers should verify authentication is correctly implemented before connecting production AI agents. Proper identity and access management controls apply to MCP server connections as they do to any other API endpoint.
Does MCP replace existing API integrations?
No. MCP wraps existing APIs, databases, and services rather than replacing them. An MCP server for a database still uses the database’s own connection and query protocols internally; it exposes a standardized MCP interface on top of that. The value is in the standardized AI-facing layer that removes the need for custom integration code in every AI host. The underlying API security testing and hardening that applies to the wrapped service remains equally necessary.
MCP and the Security Program Around It
Model Context Protocol is the infrastructure layer that lets AI agents act in the world rather than just answer questions. That capability shift changes the risk profile of AI deployments in a way that most security programs have not yet fully assessed. An AI model with no external connections can produce incorrect output but cannot execute code, modify files, or call external services on its own. An AI agent with MCP connections can do all of those things, through whatever permissions the connected servers expose.
The security discipline that applies to MCP is not new. Code review, API security testing, access control design, supply chain verification, and cloud security hardening are established practices. What is new is that they now apply to AI infrastructure. Every MCP server is an API that an AI model can invoke, and it should be assessed accordingly. Bugstrix works with organizations deploying AI agents to assess the full MCP security surface: reviewing server code for logic and permission errors, penetration testing remote MCP endpoints, evaluating cloud deployment configuration, and validating that tool permissions in production match the principle of least privilege. The organizations that invest in that assessment before deployment consistently surface issues that would otherwise be discovered through a security incident.
