Explains wallet approvals and signature requests in plain language: SAFE, CAUTION or RISK.
Scored across 3 tools
The two core tools are clearly separated: check_wallet_approvals performs a live on-chain lookup, while explain_approval processes an approval JSON payload the user already holds. feedback is unambiguously a meta tool, so an agent can select correctly without confusion.
check_wallet_approvals and explain_approval follow a consistent verb_noun snake_case pattern, but feedback breaks the convention as a bare noun. The deviation is minor and still readable.
Three tools is reasonable for a narrow, single-purpose approval checker, with two functional tools plus a feedback channel. It is on the lean side but nothing feels like filler.
The server is a read-only checker, and it covers both the on-chain audit case and the explain-existing-data case, which are the two real entry points. Missing operations like batch or multi-chain checks are minor given its stated scope.
Check an EVM wallet's live token/NFT approvals and get a plain-language safety verdict (SAFE, CAUTION, or RISK) with an explanation. The verdict comes from presign-guard's approval audit (who each spender is, which to revoke).
| Name | Required | Description | Default |
|---|---|---|---|
| kind | No | Approval type to check (default: token) | |
| chain | No | Chain to check approvals on (default: ethereum) | |
| address | Yes | EVM wallet address to check, e.g. 0x... |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | SAFE, CAUTION or RISK |
| explanation | Yes | Plain-language explanation of what the approval or payload allows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that the tool performs a read of live on-chain approvals, that the output is a three-tier verdict with an explanation, and that the verdict comes from presign-guard's audit. It does not explicitly say the operation is read-only or that no transaction is sent, which would be useful given the audit context.
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 core action and outcome, with no wasted words.
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?
Given an output schema exists, the description need not explain return values. It covers purpose, scope, and the source of the verdict, but omits whether the operation is read-only and any rate-limit or permission notes.
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% and all three parameters are self-documented with defaults and enums. The description adds context that the check is on an EVM wallet and that token/NFT is selectable, but does not add syntax or meaning beyond the schema, so the 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 (check) and resource (EVM wallet's live token/NFT approvals), and specifies what it returns (a plain-language safety verdict). It is clearly distinguishable from the siblings explain_approval and feedback.
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?
Usage is implied by the description of what it does, but there is no explicit when-to-use guidance nor a comparison against the sibling explain_approval, which is likely the alternative for approving or explaining a single approval.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explain an arbitrary approval/permission JSON payload in plain language, when you already have the data instead of needing an on-chain lookup.
| Name | Required | Description | Default |
|---|---|---|---|
| data | Yes | Arbitrary approval/permission JSON payload to explain |
| Name | Required | Description |
|---|---|---|
| verdict | Yes | SAFE, CAUTION or RISK |
| explanation | Yes | Plain-language explanation of what the approval or payload allows |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry behavioral information. It discloses that the tool works on provided data without requiring an on-chain lookup, which implies local processing. However, it does not state that the operation is read-only, side-effect-free, or what permissions it needs, leaving gaps that annotations would normally cover.
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?
The description is a single efficient sentence that front-loads the core purpose and follows with the usage condition. No words are wasted.
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?
Given a single-parameter tool with a complete schema and an output schema present, the description is nearly complete for invocation. Missing only explicit behavioral details (e.g., read-only nature) that annotations would have supplied, but these are not critical for an explain 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 the parameter is fully documented in the schema. The description adds no additional semantics about the 'data' parameter beyond restating that it accepts an arbitrary approval/permission JSON payload, matching the schema's own description.
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 (Explain) and resource (approval/permission JSON payload), specifies scope (arbitrary) and output form (plain language). It distinguishes itself from sibling check_wallet_approvals by contrasting with 'an on-chain lookup', allowing an agent to identify the tool without opening schemas.
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?
The description gives a clear condition for use ('when you already have the data') and an implicit alternative ('instead of needing an on-chain lookup'). It does not explicitly name the sibling tool check_wallet_approvals, but the contrast is sufficient for an agent to choose correctly.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Report a bug, a missing feature or anything else about this service, in a structured way. Free. A person reads every report; nothing is run or changed automatically.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | bug, feature (something missing) or other | |
| contact | No | Optional: how to reach you about it | |
| message | Yes | What happened or what you need | |
| endpoint | No | Optional: the route or tool it is about, e.g. /v1/token |
| Name | Required | Description |
|---|---|---|
| id | Yes | Report id, to refer to it later |
| note | No | |
| type | No | |
| service | No | |
| received | Yes | true: a person will read it |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the behavioral profile, and it does: the tool is free, a human reads every report, and no automated side effects occur. What's missing is any note on response behavior or follow-up expectations, but the core non-destructive, human-reviewed nature is disclosed.
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?
Three short sentences, zero padding, with the action and its scope front-loaded ahead of the supporting behavioral notes. Every sentence 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?
An output schema exists, so return values need no explanation. For a simple four-parameter submission tool, the description covers purpose and side-effect profile adequately, though it doesn't tell the agent what to expect after submitting.
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 the schema already documents message, type, contact, and endpoint. The description adds no field-level syntax or format guidance beyond what the schema states, so the baseline of 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 and resource: "Report a bug, a missing feature or anything else about this service." The purpose is unambiguous and the sibling tools (check_wallet_approvals, explain_approval) are unrelated, so no differentiation is needed.
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?
The description makes clear this is the channel for bug reports, feature requests, and general issues, and adds a key condition: nothing is run or changed automatically, so an agent shouldn't expect remediation. No explicit exclusions or named alternatives appear, but the sibling set makes those unnecessary.
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.
check_wallet_approvals1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "explanation": {
+ "description": "Plain-language explanation of what the approval or payload allows",
+ "type": "string"
+ },
+ "verdict": {
+ "description": "SAFE, CAUTION or RISK",
+ "type": "string"
+ }
+ },
+ "required": [
+ "verdict",
+ "explanation"
+ ],
+ "type": "object"
+}explain_approval1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "explanation": {
+ "description": "Plain-language explanation of what the approval or payload allows",
+ "type": "string"
+ },
+ "verdict": {
+ "description": "SAFE, CAUTION or RISK",
+ "type": "string"
+ }
+ },
+ "required": [
+ "verdict",
+ "explanation"
+ ],
+ "type": "object"
+}feedback1 field changedOutput schema / (root)Previous value: -nullNew value: +{
+ "$schema": "https://json-schema.org/draft/2020-12/schema",
+ "additionalProperties": {},
+ "properties": {
+ "id": {
+ "description": "Report id, to refer to it later",
+ "type": "string"
+ },
+ "note": {
+ "type": "string"
+ },
+ "received": {
+ "description": "true: a person will read it",
+ "type": "boolean"
+ },
+ "service": {
+ "type": "string"
+ },
+ "type": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "received",
+ "id"
+ ],
+ "type": "object"
+}feedbackcheck_wallet_approvalsexplain_approvalSafe to sign? EVM/Solana/XRPL/Algorand/Stellar txs, permits, tokens; OFAC screen: green/orange/red
Read-only crypto safety: token honeypot checks, EIP-712 signature decode, approval scans.
Use before signing an EVM tx or EIP-712 message: risk flags + verdict. Informational, no simulation
Pre-sign safety check for agent wallets: tx, EIP-712, EIP-7702, x402. By Crypto Money Maker
Add one secure layer between your agents and this server.