Skip to main content
Glama
Sign In

VerifyLite

by io.github.SecondShotAI
OverviewDiscussionsAdmin

Token approval check on Base: how much each spender can move from a wallet, incl. Permit2

token_allowance_check
Read-only

Approval check for one wallet and one ERC-20 token on Base: how much each spender (up to 10 app or router addresses) is allowed to move, flagging unlimited approvals and approvals covering the full balance, plus approvals made through Uniswap Permit2 with their expiry. Defaults to checking Permit2 itself. Useful before signing, for wallet hygiene, and for spotting approvals to revoke. Read-only. Not charged for invalid addresses or non-tokens. Paid via x402; see list_prices.

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": {
      "owner": "<owner>",
      "token": "<token>"
    },
    "name": "token_allowance_check"
  }
}

Input Schema

NameRequiredDescriptionDefault
ownerYesWallet 0x address on Base.
tokenYesToken contract 0x address on Base.
spendersNoOptional: up to 10 spender addresses (array or comma-separated). Defaults to Uniswap Permit2.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / spenders / items / anyOf
      Previous value: -[
-  {
-    "maxLength": 512,
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  },
-  {
-    "items": {
-      "anyOf": [
-        {
-          "maxLength": 512,
-          "type": "string"
-        },
-        {
-          "type": "number"
-        },
-        {
-          "type": "boolean"
-        }
-      ]
-    },
-    "maxItems": 200,
-    "type": "array"
-  }
-]New value: +[
+  {
+    "maxLength": 512,
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "items": {
+      "anyOf": [
+        {
+          "maxLength": 512,
+          "type": "string"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "boolean"
+        }
+      ]
+    },
+    "maxItems": 200,
+    "type": "array"
+  },
+  {
+    "additionalProperties": {},
+    "type": "object"
+  }
+]
  2. Changed1 schema field changed
    • changedInput schema / properties / spenders / items / anyOf
      Previous value: -[
-  {
-    "maxLength": 512,
-    "type": "string"
-  },
-  {
-    "type": "number"
-  },
-  {
-    "type": "boolean"
-  }
-]New value: +[
+  {
+    "maxLength": 512,
+    "type": "string"
+  },
+  {
+    "type": "number"
+  },
+  {
+    "type": "boolean"
+  },
+  {
+    "items": {
+      "anyOf": [
+        {
+          "maxLength": 512,
+          "type": "string"
+        },
+        {
+          "type": "number"
+        },
+        {
+          "type": "boolean"
+        }
+      ]
+    },
+    "maxItems": 200,
+    "type": "array"
+  }
+]
  3. Added

TDQS

A4.3/5.0
Behavior4/5

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

Consistent with readOnlyHint=true ('Read-only'), and it adds context the annotations cannot: the spender cap of 10, the Permit2 default, unlimited/full-balance flagging, and the x402 billing plus no-charge-on-invalid-input policy. Lacks detail on latency or how many calls a check consumes.

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?

Front-loaded with what is checked, followed by output semantics, defaults, use cases, and billing. Dense but nearly every clause carries actionable information; the billing sentence is slightly tacked on but still relevant to an agent deciding whether to call.

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?

With no output schema, the description usefully sketches the return content (per-spender allowance, unlimited flags, full-balance coverage, Permit2 expiry). For a read-only 3-parameter tool this is close to sufficient; a brief note on response shape would make it complete.

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 real meaning: the effective limit of 10 spenders (versus the schema's maxItems of 1000) and the Permit2 default when spenders is omitted. It also pins both inputs to Base, reinforcing the schema's address constraints.

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+resource+scope: an ERC-20 allowance check for one wallet/token pair on Base, per spender. It is clearly separable from siblings such as token_safety_check, wallet_transfers, and contract_call, which do not report approvals or Permit2 allowances.

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

Usage Guidelines4/5

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

Gives explicit use contexts ('before signing, for wallet hygiene, and for spotting approvals to revoke') and a default behavior when spenders are omitted. It does not name an alternative tool or state when not to use it, so it stops short of the top score.

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

All VerifyLite 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