> ## Documentation Index
> Fetch the complete documentation index at: https://docs.arlet.dev/llms.txt
> Use this file to discover all available pages before exploring further.

# Audit your MCP servers

> Check the third-party MCP servers connected to your AI client for MCP-specific security risks

The **MCP Security Audit** server in the Arlet catalog inspects the remote MCP servers you have connected to your AI client — GitHub, Vercel, Notion, or anything else configured by URL — and reports MCP-specific risks such as tool poisoning, missing authentication and over-broad OAuth scopes.

## How it works

1. Turn on **MCP Security Audit** under the **Security** tab in [Arlet tools](https://app.arlet.dev/catalog). No API key is required.
2. Ask your AI client, for example: *"Check the security of the MCP servers I'm connected to."*
3. The client reads its own MCP configuration (for example `~/.claude.json`, `.mcp.json` or `~/.cursor/mcp.json`) and passes the **endpoint URLs** of the HTTP servers to the `audit_mcp_servers` tool. Only URLs are sent — never tokens, headers or tool definitions.
4. Arlet connects to each URL itself and performs read-only protocol calls only: `initialize`, `tools/list` and OAuth discovery (`.well-known`). No tool is executed and no credentials are sent.

Because Arlet reads the tool descriptions directly from the server rather than through the model, a poisoned description cannot hide itself from the audit.

## What is checked

| Check                  | Looks for                                                                                              |
| ---------------------- | ------------------------------------------------------------------------------------------------------ |
| Tool poisoning         | Prompt-injection or data-exfiltration instructions, hidden characters in tool descriptions and schemas |
| Tool shadowing         | A tool's description that names another tool and tries to override its behaviour                       |
| Dangerous tools        | Generic shell execution, environment/secret reads, arbitrary file reads, code eval                     |
| Lethal trifecta        | Untrusted-content intake + sensitive-data access + external sending exposed by one server              |
| Missing authentication | `tools/list` succeeds without any credentials                                                          |
| Session predictability | Sequential, short or low-entropy `Mcp-Session-Id` values                                               |
| SSRF-prone metadata    | OAuth discovery that advertises internal IPs, `localhost` or cloud-metadata addresses                  |
| Scope creep            | Wildcard or omnibus scopes (`*`, `admin`, `full-access`) in `scopes_supported`                         |

## Reading the result

Every result contains `findings` and a per-check `coverage` status:

* `ok` — the check ran.
* `inconclusive` — the check could not run. This is usually an auth-protected server whose tool list is not visible without a token. **It does not mean the server is safe.**
* `not_applicable` — there was nothing to inspect (for example a stateless server that issues no session IDs).

## Limits

* Only `https://` URLs that resolve to public addresses are accepted.
* stdio servers (started with a `command` such as `npx …`) have no URL and cannot be audited here.