What Is an MCP Server?

Definition#

A Model Context Protocol (MCP) server is a program that gives an AI application structured access to external capabilities such as files, databases, APIs, software tools, or reusable prompts. It communicates with an MCP client, usually an AI assistant or agent, using the MCP protocol and an underlying transport such as standard input/output or a network connection.

MCP servers make AI applications more useful because they allow models to work with systems beyond the conversation itself. They also create a new security boundary: a model’s request can lead to file access, API calls, database queries, or other real-world actions.

How an MCP server works#

MCP separates the AI application from the systems it needs to use.

The main components are:

• MCP host: The application containing the AI experience, such as a desktop assistant, coding environment, or agent platform.
• MCP client: The component inside the host that maintains a connection to an MCP server.
• MCP server: The program that exposes capabilities to the client.
• Underlying system: The file system, API, database, SaaS platform, or command-line utility that the server accesses.

An MCP server typically advertises available capabilities during an initialization or discovery exchange. These capabilities can include:

• Tools: Actions the model can request, such as querying a database, creating a ticket, or calling an API.
• Resources: Data that can be read by the AI application, such as documents, repository files, or records.
• Prompts: Reusable prompt templates or workflows that help structure model interactions.

When a user asks an AI assistant to perform a task, the host decides whether a tool or resource is relevant. The client sends a structured request to the server. The server validates the request, performs an operation against its underlying system, and returns structured results.

The model does not automatically gain unrestricted access to everything the server can reach. In a well-designed deployment, the server has a defined scope, the client requests approval for sensitive operations, and operating-system or API permissions limit what the server can actually do. In practice, the effective security boundary depends on the server implementation, its runtime identity, its configuration, and the host application’s approval model.

MCP connections can be local or remote. A local server may run as a process on a developer workstation and communicate over standard input/output. A remote server may be hosted elsewhere and communicate over a network transport. These models have different risks: local servers raise software execution and workstation access concerns, while remote servers add authentication, authorization, transport security, and service trust questions.

Analyst’s Take: The server is the practical control point in an MCP deployment because it connects model decisions to files, APIs, databases, and other systems. Review its runtime identity, permissions, exposed tools, and data destinations before focusing on the protocol itself. Local and remote deployments require different checks, so the connection model should shape the review.

When you’ll encounter MCP servers#

MCP servers appear in several common environments.

Developer tools

Coding assistants can use MCP servers to inspect repositories, query issue trackers, interact with package systems, run tests, or access documentation. A server may be installed from a package manager, a source repository, or an IDE integration.

Enterprise AI assistants

Organizations may connect assistants to internal knowledge bases, ticketing systems, cloud platforms, identity systems, or business applications. MCP can provide a consistent interface for these integrations without embedding every connector directly into the AI product.

Security and IT automation

An MCP server can expose read-only security data, vulnerability management systems, cloud inventory, endpoint information, or incident response actions. Write access creates substantially greater impact if an agent or server is compromised.

MCP integrations may also interact with credentials, API keys, or other secrets. Teams should define where those credentials are stored and how they are accessed; see this glossary of secrets management for the underlying concept.

Local desktop workflows

Some assistants allow users to configure local MCP servers for file access, browser automation, databases, or command execution. These configurations can be convenient, but they may also run third-party code with the user’s operating-system privileges.

Internal application development

Engineering teams can build MCP servers around proprietary APIs or workflows. The server then becomes a new application interface that requires authentication, authorization, validation, logging, and maintenance.

MCP server security risks#

The most important risk is not the protocol alone. It is the combination of an AI model, untrusted or ambiguous instructions, powerful tools, sensitive data, and permissions that may be difficult for users to understand.

Key risks include:

• Prompt injection: Malicious instructions in a document, web page, repository, email, or database result can attempt to influence the model into misusing an MCP tool.
• Tool poisoning: A server’s tool description, resource content, or returned data may contain instructions designed to manipulate the model or conceal a dangerous action.
• Excessive permissions: A server running with broad file-system, cloud, database, or operating-system access can create a high-impact path from a model decision to a real-world action.
• Data exfiltration: A tool may read sensitive information and send it to an external API, log destination, or attacker-controlled endpoint.
• Confused deputy behavior: An agent may use the user’s authority to perform an action the user did not intend, especially when approval prompts are vague or absent.
• Untrusted code and supply chain risk: Installing an MCP server can mean downloading and executing third-party code. A compromised package, repository, dependency, or update process can affect every connected user.
• Weak remote authentication: A network-accessible server without strong identity checks, authorization, and encrypted transport may expose tools to unauthorized callers.
• Unsafe tool design: Poor input validation, command injection, path traversal, insecure deserialization, or unrestricted API access can make the server vulnerable independently of the model.
• Insufficient auditability: If tool calls, parameters, identities, approvals, and results are not logged, investigating misuse becomes difficult.

Reduce exposure with allowlists, least-privilege service accounts, read-only access where practical, isolated runtimes, pinned and reviewed dependencies, explicit approval for destructive actions, and egress controls. Treat tool descriptions and returned content as untrusted input. Do not assume that a model can reliably distinguish trusted instructions from hostile data.

For credentials used by MCP integrations, use controlled storage and narrowly scoped access rather than embedding secrets in configuration files or prompts. A managed password tool such as Try 1Password → may help teams centralize access while limiting unnecessary credential exposure, but it does not replace server authorization or runtime controls.

Technical notes: reviewing an MCP server before deployment#

A practical review should identify the server’s origin, entry point, dependencies, runtime identity, exposed tools, data destinations, and required permissions.

For a local server, inspect the configured command rather than executing it blindly:

Server name: repository-tools
Command: /opt/mcp/repository-tools
Arguments: --root /srv/projects
Runtime user: mcp-readonly
Network egress: documentation.example, api.internal
Capabilities: list_files, read_file, create_issue

A safer policy might separate read and write operations:

{
  "server": "repository-tools",
  "allowed_tools": ["list_files", "read_file"],
  "approval_required": ["create_issue", "delete_file"],
  "filesystem_scope": ["/srv/projects/docs"],
  "network_egress": ["api.internal"],
  "run_as": "mcp-readonly"
}

The exact configuration varies by host and implementation. The security objectives are consistent: narrow the scope, make sensitive actions visible, and ensure the operating system or API enforces the policy.

Monitor for unexpected tool use, unusual destinations, repeated denied requests, and sensitive data in parameters or results:

2026-10-12T14:22:08Z tool_call server=repository-tools tool=read_file
path=/srv/projects/docs/credentials.txt result=denied reason=scope_policy

Logs should support correlation with the user, host, model session, approval event, server version, and downstream identity. Avoid logging secrets or full sensitive payloads merely for convenience.

Security teams can also use MCP activity as an input to broader threat hunting workflows. Useful signals include unexpected server processes, unusual tool combinations, access outside approved paths, new outbound destinations, and repeated attempts to bypass approval or scope policies.

A practical MCP server review checklist#

Before allowing an MCP server to access production systems, verify:

1. Provenance: Who publishes and maintains the server? Are its source code, packages, and dependencies reviewed?
2. Runtime identity: Which user, service account, or cloud role does it use?
3. Permissions: Can access be limited to specific files, APIs, databases, repositories, or actions?
4. Tool behavior: Are inputs validated and destructive actions separated from read-only operations?
5. Authentication: How does a remote client prove its identity?
6. Authorization: Are permissions evaluated for every request, rather than only at connection time?
7. Data handling: Where can the server send data, and are outbound destinations restricted?
8. Approval workflows: Are high-impact actions clearly described and explicitly approved?
9. Logging: Are calls, parameters, identities, approvals, results, and server versions recorded without exposing secrets?
10. Maintenance: How are updates reviewed, tested, pinned, and rolled back?

Related terms

• MCP host: The AI application that manages one or more MCP connections.
• MCP client: The host component that communicates with an MCP server.
• MCP tool: An action exposed by a server that an AI application can request.
• MCP resource: Data exposed to the client through the protocol.
• MCP prompt: A reusable prompt or workflow definition supplied by a server.
• AI agent: A system that can plan and perform multi-step actions using tools.
• Tool calling: A model interaction pattern in which the model requests a structured function or action.
• Prompt injection: An attack that places instructions in model-visible content to alter intended behavior.
• Least privilege: Granting only the access required for a specific task, identity, or integration.
• Confused deputy: A security failure in which a trusted component misuses its authority on behalf of an untrusted request.

This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.