Doormat Capital's paid x402 safety tools (token scan, HTTP security headers) for AI agents.
Scored across 2 tools
The two tools target completely different domains: one for Base ERC-20 token safety reports and one for HTTP security headers reports. Their purposes are clearly distinct, and there is no functional overlap beyond the shared payment workflow.
Both tool names use snake_case and end with the suffix '_report' (apecheck_report, secheaders_report). While the prefixes are noun phrases rather than verbs, the naming pattern is entirely consistent across the set.
With only two tools, the server feels thin, especially given the generic server name 'tools'. The two tools are well-scoped individually, but the overall count is borderline for a server that might be expected to offer a broader set of utilities.
The server covers two specific security report types, but for a security-focused toolkit, notable gaps exist (e.g., SSL/TLS checks, DNS reputation, other blockchain analysis). The surface is not severely incomplete but lacks coverage of common adjacent security operations.
Paid (x402, USDC on Base). Full safety report for a Base ERC-20 token contract: metadata, raw owner address, mint-selector heuristic, approximate recent-activity signal. Call without 'tx' first to receive the exact x402 payment challenge (amount, asset, payTo address, chain); pay that amount in USDC on Base, then call again with the resulting transaction hash in 'tx' to receive the real report.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | No | Optional: 0x-prefixed 64-hex-character Base transaction hash proving payment. Omit on the first call to see the payment challenge. | |
| address | Yes | 0x-prefixed 40-hex-character Base token contract address. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the paid x402/USDC-on-Base model, the exact two-phase challenge/pay/retry flow, and the fields the report returns. It stops short of error handling, refund/failure behavior, or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the cost/payment model before the report contents and the invocation sequence. Dense but every clause carries information; no padding.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema exists, and the description compensates by naming the report's fields and the payment mechanics. A deficiency remains around failure modes (e.g., what happens with an invalid or already-used tx hash) for a paid tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'tx' and 'address' are already documented with format requirements. The description restates the 'omit tx on first call' semantics, which is useful framing but adds little beyond the schema; baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb+resource ('Full safety report for a Base ERC-20 token contract') and enumerates the report contents (metadata, owner address, mint-selector heuristic, activity signal). However, it never mentions the sibling secheaders_report, so an agent cannot tell from this text alone which report to pick.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear procedural guidance: call without 'tx' first to receive the x402 challenge, pay in USDC on Base, then call again with the transaction hash. It does not state when this tool is preferable to secheaders_report, so alternative-selection guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Paid (x402, USDC on Base). Full HTTP security-headers report for a URL: every header checked, raw values, remediation detail. Call without 'tx' first to receive the exact x402 payment challenge; pay, then call again with the transaction hash in 'tx' to receive the full report.
| Name | Required | Description | Default |
|---|---|---|---|
| tx | No | Optional: 0x-prefixed 64-hex-character Base transaction hash proving payment. Omit on the first call to see the payment challenge. | |
| url | Yes | The URL to check (e.g. https://example.com). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden and does well: it discloses the tool is paid, the payment rail (x402, USDC on Base), and the required two-call handshake with a transaction hash. It omits failure/expiry behavior for the challenge and any rate or latency expectations, so it stops short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, zero filler, with the paid/two-step constraint front-loaded before the report contents. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No annotations and no output schema, yet the description supplies both the cost/payment mechanics and a summary of what the report returns, which is exactly what an agent needs to invoke this tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both 'url' and 'tx' are already documented in the schema, including the 'omit on first call' semantics. The description reinforces the tx flow but adds no new syntax, format, or constraint beyond the schema. Baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource ('Full HTTP security-headers report for a URL') and enumerates the payload contents (every header checked, raw values, remediation detail). It does not differentiate from the sibling apecheck_report, so it cannot earn a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It gives an explicit operating procedure: call without 'tx' first to get the x402 payment challenge, pay, then call again with the transaction hash. That is clear when-to-use guidance for this tool, though no alternative/sibling routing or exclusion criteria is offered.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
apecheck_reportsecheaders_reportPay-per-call safety checks for AI agents: screen a crypto address or URL before you transact.
Pay-per-call safety guards for AI agents: injection, tool-call, signing, secret, x402-trust.
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
Free token-safety scans + paid x402 verdicts, signals, radar & EVM swap quotes for AI agents.
Add one secure layer between your agents and this server.
