Skip to main content
Glama

erc8128_verify_signature

Verify ERC-8128 HTTP message signatures by checking RFC 9421 validity, recovering Ethereum signer addresses, and validating expiry timestamps.

Instructions

Verify an ERC-8128 HTTP message signature. Checks RFC 9421 signature validity, recovers the signer's Ethereum address, and validates expiry.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP method
urlYesRequest URL
headersYesHTTP headers from the signed request
signature_inputYesSignature-Input header value
signatureYesSignature header value
content_digestNoContent-Digest header value

Implementation Reference

  • The handler logic for the erc8128_verify_signature tool, which formats the request and calls the backend API.
    async (args) => {
      // Merge signature headers into the headers dict (REST API extracts from headers)
      const headers = { ...args.headers };
      headers['signature-input'] = args.signature_input;
      headers['signature'] = args.signature;
      if (args.content_digest) headers['content-digest'] = args.content_digest;
    
      const requestBody: Record<string, unknown> = {
        method: args.method,
        url: args.url,
        headers,
      };
      const result = await apiClient.post('/v1/erc8128/verify', requestBody);
      return toToolResult(result);
    },
  • The input schema for the erc8128_verify_signature tool defining the required parameters.
    {
      method: z.enum(['GET', 'POST', 'PUT', 'DELETE', 'PATCH']).describe('HTTP method'),
      url: z.string().url().describe('Request URL'),
      headers: z.record(z.string()).describe('HTTP headers from the signed request'),
      signature_input: z.string().describe('Signature-Input header value'),
      signature: z.string().describe('Signature header value'),
      content_digest: z.string().optional().describe('Content-Digest header value'),
    },
  • The registration function for the erc8128_verify_signature tool.
    export function registerErc8128VerifySignature(
      server: McpServer,
      apiClient: ApiClient,
      walletContext?: WalletContext,
    ): void {
      server.tool(
        'erc8128_verify_signature',
        withWalletPrefix(
          'Verify an ERC-8128 HTTP message signature. Checks RFC 9421 signature validity, recovers the signer\'s Ethereum address, and validates expiry.',
          walletContext?.walletName,
        ),
        {
          method: z.enum(['GET', 'POST', 'PUT', 'DELETE', 'PATCH']).describe('HTTP method'),
          url: z.string().url().describe('Request URL'),
          headers: z.record(z.string()).describe('HTTP headers from the signed request'),
          signature_input: z.string().describe('Signature-Input header value'),
          signature: z.string().describe('Signature header value'),
          content_digest: z.string().optional().describe('Content-Digest header value'),
        },
        async (args) => {
          // Merge signature headers into the headers dict (REST API extracts from headers)
          const headers = { ...args.headers };
          headers['signature-input'] = args.signature_input;
          headers['signature'] = args.signature;
          if (args.content_digest) headers['content-digest'] = args.content_digest;
    
          const requestBody: Record<string, unknown> = {
            method: args.method,
            url: args.url,
            headers,
          };
          const result = await apiClient.post('/v1/erc8128/verify', requestBody);
          return toToolResult(result);
        },
      );
    }
Behavior4/5

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

With no annotations provided, the description carries the full disclosure burden. It successfully reveals key behavioral traits: RFC 9421 compliance check, Ethereum address recovery, and expiry validation. It appropriately implies this is a read-only verification operation, though it omits error handling specifics and full output structure.

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 tightly constructed sentences with zero redundancy. Front-loaded with the core verb and standard, followed by specific verification behaviors. Every word earns its place.

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?

For a 6-parameter cryptographic verification tool with no output schema, the description adequately covers the domain specifics (RFC 9421, ERC-8128) and hints at the primary output (signer's address). Minor gap: does not detail the verification failure modes or complete return structure.

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%, establishing a baseline of 3. The main description adds high-level context (these parameters constitute an HTTP message signature per ERC-8128) but does not augment individual parameter semantics beyond what the schema already provides.

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?

Excellent specificity: states the exact action (Verify), the standard (ERC-8128), the mechanism (RFC 9421), and the outputs (recovers Ethereum address, validates expiry). Clearly distinguishes from sibling erc8128_sign_request through the verify vs. sign verb contrast.

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 functionality—you use this when you need to verify ERC-8128 signatures. However, it lacks explicit when-to-use/when-not guidance or direct reference to the signing tool as its counterpart.

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

Install Server

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/minhoyoo-iotrust/WAIaaS'

If you have feedback or need assistance with the MCP directory API, please join our Discord server