MCP Manifest Audit: What to Check Before Agent Access

Before granting an AI agent access to an MCP server, audit the server’s manifest and configuration for identity, capabilities, permissions, and trust boundaries. Confirm what the server can do, what data it can reach, how it is launched, and whether each declared tool is safe and necessary; a manifest describes access, but does not by itself prove that the implementation is trustworthy.

What an MCP manifest tells you

Model Context Protocol (MCP) is a way for an application—often an AI client—to communicate with a server that exposes capabilities such as tools, resources, and prompts. The exact configuration format depends on the client and deployment. In common local setups, a client configuration identifies a server and how to start it, often using a command, arguments, and environment variables. Remote deployments may use a URL and transport-specific settings. Do not assume every client uses one universal manifest schema.

A configuration entry is a starting point for an audit, not a complete inventory of behavior. The server’s implementation determines what a tool actually does, while client policy and operating-system controls determine what it can access. Review the configuration together with the server source or documentation, deployment environment, and relevant logs.

Check identity, source, and launch behavior

Establish exactly which server the agent will connect to and whether that identity can be verified. For a local server, inspect the executable or package, its publisher or repository, version, installation path, and integrity through your normal software-supply-chain process. For a remote server, verify the hostname, transport, certificate handling, and who controls the service. A familiar display name is not proof of identity.

Review the launch command and every argument. Look for shell wrappers, scripts fetched from the network, unexpected package installers, or commands that run with elevated privileges. Prefer a pinned, reviewed version and a stable executable path over an unpinned package or a command that silently retrieves changing code. If the configuration invokes a shell, determine how arguments are interpreted and whether user-controlled values could become executable input.

• Confirm the command and arguments match the intended server and environment.
• Check whether startup can execute additional scripts or update itself.
• Identify the operating-system account and privileges used to run it.
• For remote endpoints, check ownership, encryption, and the expected authentication method.

Inventory tools and their real effects

List every tool the server exposes and read its description, input schema, and implementation or authoritative documentation. Treat descriptions as hints, not enforcement: a tool called “read-only search” might still disclose sensitive information, and a tool named “preview” might make changes if its implementation does so.

Classify effects, not just names. A tool may read files, query a database, send messages, modify records, run commands, or trigger an external service. Check whether the agent can invoke it without confirmation, whether actions are reversible, and what happens with malformed, oversized, or unexpected inputs. Look for broad tools such as arbitrary command execution or unrestricted file access, because their possible impact can exceed what a short description suggests.

For example, a server offering a “search project files” tool should be checked for its actual root directory, treatment of symbolic links, and whether it can read files outside that root. A “create issue” tool should be checked for the destination account, fields it can change, and whether submission is immediate. These checks reveal the practical authority granted to the agent.

Review permissions, secrets, and data flow

Map each capability to the data and systems it can reach. Apply least privilege: grant only the directories, accounts, API scopes, and network destinations needed for the intended task. Where possible, use a dedicated account or isolated environment instead of the operator’s full personal or administrative access.

Inspect environment-variable references and secret handling without copying secret values into audit notes. Determine where credentials come from, who can read them, whether they are sent to the server or a remote service, and how they are rotated or revoked. Avoid placing tokens directly in command arguments or configuration files that may be logged, synchronized, or shared. Check whether tool inputs, outputs, prompts, and errors may contain confidential data and where those records are stored.

• Limit filesystem access to specific working directories.
• Use narrowly scoped credentials and remove unused permissions.
• Restrict network access to destinations the server needs.
• Check retention and logging for sensitive inputs and returned data.

Validate trust boundaries and runtime controls

An agent’s instructions, tool descriptions, and retrieved content are not security boundaries. Untrusted content can influence an agent’s choices, so the server and surrounding system should enforce access restrictions independently of what the agent is told. Require human approval for consequential actions where appropriate, and ensure approval covers the specific action rather than granting open-ended authority.

Test the setup in a non-production environment with harmless data. Confirm the client connects to the intended server, exposes only expected tools, rejects unauthorized operations, and handles failures safely. Check whether the server can reach unrelated files or networks, whether it continues running after the client closes, and whether logs show enough information to investigate activity without unnecessarily recording secrets. Keep a way to disable the connection and revoke credentials quickly.

Common audit mistakes

A frequent misconception is that a valid manifest, schema, or successful connection certifies a server as safe. These only show that the configuration can be parsed or the protocol can communicate; they do not establish code integrity, benign behavior, or appropriate permissions. Another mistake is reviewing only tool names while overlooking command arguments, environment variables, inherited permissions, and remote destinations.

Also avoid granting broad access “temporarily” without an owner and expiry plan. Temporary permissions often persist. Record the approved server identity, version, exposed tools, allowed data, reviewer, and review date. Re-audit after changing the server version, endpoint, launch command, credentials, or permissions, since any of these can change the effective access.

A practical pre-access checklist

1. Identify the exact local executable or remote endpoint, source, and version.
2. Read the full configuration, including arguments, environment references, transport, and authentication settings.
3. Inventory tools, resources, and prompts; verify their actual behavior and side effects.
4. Map reachable files, services, accounts, credentials, and network destinations.
5. Reduce privileges, isolate the runtime, and require approval for sensitive actions.
6. Test expected and denied behavior, review logging, and document how to revoke access.

Approve access only when the server’s identity is established, its capabilities match a defined task, and the controls limit the impact of misuse or compromise. If you cannot explain what a tool can reach or change, do not expose it to the agent yet.

Frequently Asked Questions

Does an MCP manifest prove a server is safe?
No. It describes configuration or advertised capabilities, depending on the client and server. Safety also depends on the implementation, its permissions, the data it handles, and the runtime environment.

What is the most important thing to check before connecting?
Verify the server’s identity and inspect the effective capabilities and permissions. A trusted name is not enough if the command, endpoint, or access scope is unexpected.

Should an MCP server have access to my whole filesystem?
Usually, grant only the specific directories required for the task. Broad filesystem access increases the impact of mistakes, malicious inputs, or compromised server code.

Are tool descriptions reliable security controls?
No. Descriptions help people and agents understand intended behavior, but the implementation and external permissions determine what a tool can actually do.

When should I repeat an MCP manifest audit?
Review it whenever the server version, source, launch command, endpoint, credentials, exposed tools, or permission scope changes, and periodically under your organization’s review process.

Related

• Fire Tablet as a Second Screen: How to Set It Up
• Power Bank Buying Guide: Do You Need One?
• Get Temperature Apple Silicon Mac?