ScorpTech x402 API

Eip712 Hash

eip712_hash

Read-onlyIdempotent

EIP-712 typed-data hashing and signature check: returns encodeType, typeHash, domain separator, struct hash and the final digest a wallet signs (eth_signTypedData_v4), and with a signature recovers the signer and compares it to an expected address. Summarises common payloads (ERC-2612 Permit, EIP-3009 TransferWithAuthorization used by x402 EVM payments, Permit2) so an agent can see what it is about to sign. POST JSON body. Price: $0.003 USDC per successful call (x402, Solana). Same tool over HTTPS: POST https://scorptech.it.com/api/x402/v1/eip712-hash

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": {
      "typedData": "<typedData>"
    },
    "name": "eip712_hash"
  }
}

Input Schema

Name	Required	Description
`address`	No	Optional expected signer
`signature`	No	Optional 65-byte or 64-byte signature to recover the signer
`typedData`	Yes	The eth_signTypedData_v4 payload: {types, primaryType, domain, message} (EIP712Domain type optional, inferred from domain keys)

Schema Changelog

Changes observed during successful MCP inspections.

AddedOct 23, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Annotations already cover read-only, idempotent, open-world, and non-destructive behavior. The description adds useful context beyond annotations: the returned fields, signature recovery behavior, POST JSON body, per-call pricing, and the HTTPS endpoint. It does not disclose failure semantics or rate limits, but the key behavioral profile is clear.

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?

The purpose and return values are front-loaded, and the remaining details about POST JSON, pricing, and the HTTPS endpoint are relevant. The main sentence is dense and somewhat run-on, but there is little wasted text.

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 the nested typed-data input, three optional/required parameters, and absence of an output schema, the description is largely complete because it lists the returned hashes/digest and explains signature recovery. It could still be clearer about exact response shape or error behavior, but an agent has enough information to invoke it correctly.

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 description coverage is 100%, so the baseline is 3. The description adds meaningful cross-parameter semantics by explaining that a supplied signature recovers the signer and compares it to the optional expected address, and by framing typedData as the eth_signTypedData_v4 payload.

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?

The description states a specific verb/resource pair, EIP-712 typed-data hashing and signature check, and enumerates the exact outputs including encodeType, typeHash, domain separator, struct hash, and final digest. It also names eth_signTypedData_v4 and common payload families, making the tool clearly distinguishable from generic hashing or EVM utilities.

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?

It explains the main usage context: hashing typed data and, when a signature is supplied, recovering and comparing the signer to an expected address. It also mentions common payloads such as ERC-2612 Permit, EIP-3009, and Permit2, but does not explicitly route agents away from siblings like evm_verify_signature or hash_encode.

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?