Screen the manifest before granting access

An MCP tool named delete_file tells you what it does. Its input schema and deployment permissions tell you how much damage a mistaken call could cause.

mcp-tool-risk-score returns per-tool risk scores with reasons, plus an overall score for the submitted manifest. It costs 0.02 USDC per call, paid through x402 on Base mainnet. Use it when you're reviewing a new MCP server or checking a changed tool definition before an agent gets access.

Start with the manifest. The endpoint reviews the definitions you submit, so its findings depend on what those definitions disclose. A low score means the tool looks lower-risk on paper. It doesn't certify the running server as safe.

Include the permissions the agent will have

The required tools field accepts a non-empty JSON array, with at most 50 entries and 60,000 characters when serialized. Include each tool's name and description, along with its inputSchema.

The optional context string accepts up to 500 characters. Use that space to describe the deployment's effective permissions. “Production service account with filesystem write access” gives the review more useful information than “file management assistant.”

Here's an example request body for a POST to mcp-tool-risk-score: 

{
  "tools": [
    {
      "name": "delete_file",
      "description": "Deletes a file at the given path",
      "inputSchema": {
        "type": "object",
        "properties": {
          "path": {
            "type": "string"
          }
        },
        "required": ["path"]
      }
    }
  ],
  "context": "Runs with production filesystem write access. No path restriction or approval step is configured."
}

That path field accepts a string without describing an allowed directory. Combined with production write access, it's a specific issue to investigate before granting the tool.

And context should describe controls that already exist. If you're planning to restrict deletion to a temporary directory, make that restriction real before presenting it as a deployment fact.

Read the reasons beside the numbers

Scores run from 0 to 100. Higher means riskier.

Each tool entry includes these fields:

| Field | What it estimates | | --- | --- | | permission_scope_score | How broad the tool's access or capability appears | | injection_surface_score | Exposure to prompt injection through untrusted content the tool receives or returns | | destructive_action_score | Potential damage from a wrong or malicious call | | overall_score | The tool's combined risk assessment |

The per-tool overall_score isn't necessarily the arithmetic average of the other scores. The response also has a top-level overall_score for the submitted manifest, with a short summary.

Look at reasons first. Each tool's entry is intended to include one to four short explanations tied to its definition. For delete_file, a reason about an unrestricted path gives the reviewer a concrete follow-up: inspect which paths the service account can delete.

A read-only tool deserves inspection too. Fetching arbitrary pages can bring attacker-controlled text into an agent's context even if the tool can't write a file. Its injection score addresses a different concern from destructive-action risk.

Treat the overall score as a way to prioritize review. One tool with broad destructive access deserves attention even when the rest of the manifest contains narrow lookups.

Turn a finding into an access decision

Before screening, your router knows that delete_file accepts a path. After screening, it has a reason to hold that tool for review while allowing a separately approved read-only tool.

That's a useful place for this endpoint in an x402 workflow: after collecting the manifest, before granting permissions. Payment buys the assessment; your application still owns the access decision.

For the deletion example, restrict the service account's writable directory and require approval for destructive calls. Update the manifest to describe the enforced boundary, then submit it again with the revised context. Compare the reasons against the change you made. A lower number alone doesn't prove the restriction works.

Keep the reviewed manifest and deployment context with the resulting assessment. If the server later adds a tool or gains broader credentials, run another review before carrying forward the old access decision.

If a screening request fails or returns an incomplete assessment, keep the tool pending. Your router should distinguish “review completed” from “request attempted” before it grants access.