Skip to main content
Glama
Sign In

PlainText Wallet Approval Checker

by io.github.Fizzl13
OverviewDiscussionsAdmin

Check Wallet Approvals

check_wallet_approvals

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).

Input Schema

NameRequiredDescriptionDefault
kindNoApproval type to check (default: token)
chainNoChain to check approvals on (default: ethereum)
addressYesEVM wallet address to check, e.g. 0x...

Output Schema

NameRequiredDescriptionDefault
verdictYesSAFE, CAUTION or RISK
explanationYesPlain-language explanation of what the approval or payload allows

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • 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"
+}
  2. First observed

TDQS

A4/5.0
Behavior4/5

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.

Conciseness5/5

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.

Completeness4/5

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.

Parameters3/5

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.

Purpose5/5

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.

Usage Guidelines3/5

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.

All PlainText Wallet Approval Checker toolsInspect
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.

Resources