ScorpTech x402 API

Evm Verify Signature

evm_verify_signature

Read-onlyIdempotent

Verify an Ethereum signature offline: recovers the signer address (secp256k1 ecrecover) from an EIP-191 personal_sign message (UTF-8 or hex) or a raw 32-byte digest (e.g. an EIP-712 hash), compares it with an expected address, flags malleable high-s signatures, accepts 65-byte r,s,v and 64-byte EIP-2098 compact signatures, and parses Sign-In with Ethereum (EIP-4361) messages (domain, nonce, chain, expiry). For smart-contract wallets (EIP-1271) recovery does not apply. Price: $0.003 USDC per successful call (x402, Solana). Same tool over HTTPS: GET https://scorptech.it.com/api/x402/v1/evm-verify-signature

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": {
      "signature": "<signature>"
    },
    "name": "evm_verify_signature"
  }
}

Input Schema

Name	Required	Description	Default
`hash`	No	Raw 32-byte digest that was signed (no prefix added), e.g. an EIP-712 digest
`address`	No	Expected signer, to get match true/false
`message`	No	Signed message for personal_sign (EIP-191); give message or hash
`signature`	Yes	0x signature: 65 bytes r,s,v or 64 bytes EIP-2098
`messageEncoding`	No	How to read message: UTF-8 text or 0x-hex bytes	utf8

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Goes well beyond the annotations: states the operation is offline/secp256k1 ecrecover, flags malleable high-s signatures, discloses cost ($0.003 USDC per successful call, x402 on Solana), and provides an HTTPS alternative endpoint. Annotations already cover safety, but the payment, malleability and EIP-1271 caveats are genuinely additive.

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?

Dense but front-loaded: capability, then formats, then caveats, then price/endpoint. The opening sentence is a long run-on, yet each clause carries information an agent needs; nothing is filler.

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 implies a match boolean via the address parameter and mentions high-s flagging and SIWE field parsing, but never spells out the full response shape (e.g. recovered address, valid flag, parsed SIWE fields). Otherwise complete for a read-only verification tool.

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 baseline is 3, but the description adds real semantics the schema leaves implicit: signature length determines 65-byte r,s,v vs 64-byte EIP-2098, message can be UTF-8 or hex, the digest gets no prefix, and message/hash are alternatives. That linkage between parameters is value beyond the field-level descriptions.

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 and resource — recover the signer address from an Ethereum signature and compare it to an expected address — and enumerates the exact supported inputs (EIP-191 personal_sign, raw 32-byte digest, 65-byte r,s,v, 64-byte EIP-2098, EIP-4361). This is unmistakable against siblings like eip712_hash or evm_read.

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 clear triggering conditions (message or digest input) and an explicit exclusion: EIP-1271 smart-contract wallets are out of scope because recovery does not apply. It stops short of naming which sibling to use instead (e.g. eip712_hash to produce the digest), so it falls just below the top band.

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

All ScorpTech x402 API 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.

Resources

Need Help?