A Proposed MCP Server Security Evaluation Framework

AI Agents are upon us and without properly mapping out security threats how can you even consider which guardrails to put in place? I’d like to propose a guiding framework for evaluating Model Context Protocol (MCP) Server security using a set of criteria that can be used to assess the security posture of an MCP server implementation.

The audience for this framework is:

• Software developers considering building an MCP server
• Software developers considering using an MCP server in their AI agents (Cursor, Claude Code, etc)
• Security practitioners evaluating the security of MCP servers adoption and integration

MCP Server Configuration

1. Remote MCP Server Relies on Credentials via Query String

Maintaining authentication and authorization for an MCP server is a legitimate use-case, however, the way that credentials are handled is critical.

It’s been a long-standing best practice to avoid passing sensitive credentials in the query string of a URL, as they can be logged across various places (e.g., browser history, server logs). Even though we’re in the age of HTTPS, the PHP developer ecosystem have been repeatedly frowned upon for following this practice of passing cookie session IDs.

Yet, I’ve observed that some remote MCP server configurations still rely on passing API tokens in the query string. This is a security risk, as it can lead to accidental exposure of sensitive information:

2. MCP Server Configuration Secrets via Environment Variables

In another case of insecure storage of sensitive information such as credentials in the form of API tokens, API keys and other secrets is when such information is stored in the environment variables configuration of an MCP Server.

Consider the following example of an MCP server configuration file that stores sensitive information in environment variables:

{
  "mcpServers": {
    "server-name": {
      "command": "executable",
      "args": ["arg1", "arg2"],
      "env": {
        "API_TOKEN": "secret-key"
      }
    }
  }
}

This MCP configuration is often a JSON file on disk at the local project directory ./.vscode/mcp.json for example, or at the user’s home directory ~/.vscode/.mcp.json and is easily accessible by anyone with access to the file system.

These sensitive files become a target for exfiltration by attackers.

MCP Server Implementation

Risks in MCP Server implementation vary and are quite broad. MCP Servers can also be evaluated based on whether they are of a trusted entity or not, therefore opening the risks of malicious code as part of the MCP Server implementation.

In the scope of this proposed MCP Server security evaluation framework, I will assume that the MCP Server is implemented by a trusted entity, and as such, the security risks mostly related to secure coding conventions and practices.

For example, consider the following MCP Server tool implementation that is written in JavaScript using the @modelcontextprotocol/sdk/server package:

import { McpServer } from "@modelcontextprotocol/sdk/server/mcp.js";
import { StdioServerTransport } from "@modelcontextprotocol/sdk/server/stdio.js";
import { z } from "zod";
import { execSync, execFileSync } from "child_process";

const server = new McpServer({
  name: "npm JavaScript package management tools",
  version: "1.0.0",
  description: "Provides tools to get information about open source npm packages from the npmjs registry"
});

server.tool(
  "getNpmPackageInfo",
  "Get information about an npm package",
  {
    packageName: z.string()
  },
  async ({ packageName }) => {    
    const output = execSync(`npm view ${packageName}`, {
      encoding: "utf-8",
    });

    return {
      content: [
        {
          type: "text",
          text: output
        },
      ],
    };
  }
);

MCP Server Assets

The last piece of the MCP Server security evaluation framework ties to the building blocks of an MCP Server which is often a composition of third-party libraries, as is common with many software projects today relying on open source software.

As such, third-party libraries can introduce security risks to pay attention to, just as with any other project:

• Insecure inclusion of third-party libraries
• Incompatible licenses

The above risks of third-party libraries are nothing new to developers and security practitioners, however, they are worth mentioning in the context of MCP Server security evaluation which is often a black box when configuring new MCP Server integrations.