Quickstart
MCP Guard checks a tool call before your agent runs it. You send the action and what the user asked for; you get back a verdict (allow, ask or block), the reasons, and calibrated scores for nine questions, from one forward pass of a small model.
1. Create a key
Create an account. Every workspace starts with 1,000 free requests (a batch counts once); after that it is $0.20 per 1,000 checks, 1 credit per check. In the dashboard, open API keys and create one. It is shown once; store it as MCP_GUARD_API_KEY.
2. Check an action
Base URL https://api.mcp-guard.ai. Send the key as Authorization: Bearer mcpg_live_…. Here an agent that was asked to list tables proposes dropping one:
| Request field | Description |
|---|---|
actionrequiredstring | {tool, args} | The tool call about to run: "db.drop_table(users)" or {"tool": "db.drop_table", "args": {"table": "users"}}. |
intentstring | What the user asked the agent to do. The most useful field after the action: most unsafe calls are only unsafe relative to the request. |
triggerenum | user_request (the default when omitted), tool_result, correction or user_override. Send tool_result whenever the action was suggested by a tool output, a web page, an email or a document: that is how prompt injection is caught, and without it an injected action looks user-requested. |
constraintsstring[] | Rules the action must respect, e.g. "staging only", "never email outside acme.com". Up to 32. |
contextstring | Agent role, environment (production / staging), anything else worth knowing. |
user_string | The latest user message, when it differs from the intent. |
conversation{role, content}[] | Recent turns, oldest first, up to 50. The model reads about 384 tokens per check in total: longer input is trimmed (newest turns and recipient or target fields are kept) and the response says truncated: true. Put the decisive part in action and intent, and send only relevant context. |
3. Read the verdict
Run the action on allow, ask a human on ask, do not run it on block. Values above are illustrative.
| Field | Description |
|---|---|
verdictallow | ask | block | The default policy applied to the scores. See the verdict rule. |
p_number 0–1 | 1 − scores.safe. |
reasonsstring[] | Short reasons, e.g. "destructive", "possible data exfiltration". Empty when nothing stands out. |
scoresobject | Nine calibrated answers. See scores & verdicts. |
idstring | Request id (grd_…), also in the x-request-id header. |
latency_number | Model time for the check. Add your network round trip. |
truncatedboolean, optional | True when the check was longer than the model reads and was trimmed. Send less context if you see it often. |
tokens_integer, optional | Tokens the model read for this check. |
model_string, optional | Identifies the exact model weights that answered; changes when the model is updated. |
triggersobject[], optional | What drove the verdict: a policy rule or a score over its threshold. See triggers. |
Every response, errors included, carries x-request-id; quote it when you contact support. A check also reports x-credits-charged (0 on a free request or a failure) and x-free-runs-remaining. Failed calls are free.
Many actions at once
When a plan or a generated script is about to fire several tool calls, send them together to POST /v1/guard/batch as {"checks": [...]} (up to 64). You get one result per check, in order; it costs 1 credit per check.
Next
- Wire it into your agent: integrations (agent loop, Claude Code hook, code-mode sandbox).
- Give it to an MCP client instead: MCP server.
- Handle errors, limits and retries.
- Everything else is in the API reference.
MCP Guard reduces risk; it does not guarantee safety. Keep deterministic rules (allow-lists, sandboxes, least privilege) for the patterns you already know are bad, and use the guard for the rest.