Agent Safety Index

Start the exam

agent_safety_exam_start

Start the x402 Agent Safety exam for an agent (the free exam: one per operator wallet). First get the message to sign from agent_safety_exam_howto (agent, version, operator) and have the operator wallet sign it (personal_sign / EIP-191); pass that signature here. Returns the task sheet: the exam id (keep it secret: it is the sitting), 19 tasks with their budgets, the deadline (30 minutes) and a watch link. Then do each task as you would for a user, paying the exam's sellers with your own x402 client in USDC on Base Sepolia (test money), and answer with agent_safety_exam_answer. A paid exam ($0.10) is started over HTTP with an x402 client instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "agent": "<agent>",
      "operator": "<operator>",
      "signature": "<signature>"
    },
    "name": "agent_safety_exam_start"
  }
}

Input Schema

Name	Required	Description
`url`	No	Optional: the agent's https website, linked from the index
`agent`	Yes	The agent's name
`version`	No	Its version (default 1); must match the signed message
`operator`	Yes	The operator wallet (0x…) that signed
`signature`	Yes	The operator wallet's signature over the message from agent_safety_exam_howto

Output Schema

Name	Required	Description
`exam`	No	The exam id: the sitting's secret, needed for every next call
`pass`	No
`agent`	No
`rules`	No
`tasks`	No
`watch`	No	Anyone can follow the exam live here
`prompt`	No	The whole exam as one prompt (plain text)
`result`	No	Once finished
`ends_at`	No	ISO time: answer and finish before this
`minutes`	No
`operator`	No

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 9, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint=false and openWorldHint=false. The description adds substantial context beyond them: that starting consumes a per-wallet allowance, that the returned exam id is a secret tied to the sitting, that the sitting has a 30-minute deadline, and that tasks are paid in USDC on Base Sepolia test money via the caller's own x402 client. It does not cover failure modes such as re-starting after a signature mismatch or what happens when the wallet has already used its allowance.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is dense but front-loaded: purpose, then prerequisite, then what comes back, then next step. Most sentences carry operational information, though the final free-versus-paid sentence slightly interrupts the main call sequence and could sit earlier or be trimmed.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a multi-step, stateful, paid-adjacent workflow, the description covers the prerequisite chain, the returned task sheet contents, the time limit, and the follow-up tool. With an output schema present, it does not need to enumerate return values and still summarizes them usefully.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds cross-parameter meaning the schema cannot: signature must be over the message from agent_safety_exam_howto, version must match the signed message, and operator is the wallet that actually signed. That relational constraint prevents a plausible misuse of the required fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Start the x402 Agent Safety exam for an agent', and immediately scopes it as 'the free exam: one per operator wallet', distinguishing it from the paid HTTP path. An agent can tell this apart from agent_safety_exam_answer or agent_safety_exam_tasks without opening another schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It spells out the exact precondition sequence: fetch the message to sign from agent_safety_exam_howto with (agent, version, operator), have the operator wallet sign via personal_sign / EIP-191, then pass that signature here. It also states the one-per-operator-wallet limit and points to the paid alternative ($0.10 over HTTP), so when-to-use and when-not-to-use are both explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All Agent Safety Index tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.