Skip to main content
Glama

erc8128_sign_request

Sign HTTP requests with ERC-8128 signatures to authenticate and secure API calls using wallet-based cryptography.

Instructions

Sign an HTTP request using ERC-8128 (RFC 9421 + EIP-191). Returns Signature-Input, Signature, and Content-Digest headers for the given HTTP method, URL, headers, and body.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
methodYesHTTP method
urlYesTarget URL to sign for
headersNoHTTP headers to include in signature
bodyNoRequest body (used for Content-Digest)
wallet_idNoTarget wallet ID. Required for multi-wallet sessions; auto-resolved when session has a single wallet.
networkNoNetwork ID (e.g., evm-ethereum-mainnet)
presetNoCovered Components preset (default: standard)
ttl_secondsNoSignature TTL in seconds (default: 300)

Implementation Reference

  • The handler function for the erc8128_sign_request tool that prepares the request and calls the backend API.
      async (args) => {
        const requestBody: Record<string, unknown> = {
          method: args.method,
          url: args.url,
        };
        if (args.headers) requestBody['headers'] = args.headers;
        if (args.body) requestBody['body'] = args.body;
        if (args.wallet_id) requestBody['walletId'] = args.wallet_id;
        if (args.network) requestBody['network'] = args.network;
        if (args.preset) requestBody['preset'] = args.preset;
        if (args.ttl_seconds !== undefined) requestBody['ttlSeconds'] = args.ttl_seconds;
        const result = await apiClient.post('/v1/erc8128/sign', requestBody);
        return toToolResult(result);
      },
    );
  • The registration function registerErc8128SignRequest that adds the tool to the MCP server.
    export function registerErc8128SignRequest(
      server: McpServer,
      apiClient: ApiClient,
      walletContext?: WalletContext,
    ): void {
      server.tool(
        'erc8128_sign_request',
        withWalletPrefix(
          'Sign an HTTP request using ERC-8128 (RFC 9421 + EIP-191). Returns Signature-Input, Signature, and Content-Digest headers for the given HTTP method, URL, headers, and body.',
          walletContext?.walletName,
        ),
  • The Zod schema definition for the input parameters of the erc8128_sign_request tool.
    {
      method: z.enum(['GET', 'POST', 'PUT', 'DELETE', 'PATCH']).describe('HTTP method'),
      url: z.string().url().describe('Target URL to sign for'),
      headers: z.record(z.string()).optional().describe('HTTP headers to include in signature'),
      body: z.string().optional().describe('Request body (used for Content-Digest)'),
      wallet_id: z.string().optional().describe('Target wallet ID. Required for multi-wallet sessions; auto-resolved when session has a single wallet.'),
      network: z.string().optional().describe('Network ID (e.g., evm-ethereum-mainnet)'),
      preset: z.enum(['minimal', 'standard', 'strict']).optional().describe('Covered Components preset (default: standard)'),
      ttl_seconds: z.number().optional().describe('Signature TTL in seconds (default: 300)'),
    },
Behavior3/5

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

With no annotations, description carries burden. It effectively discloses return values (Signature-Input, Signature, Content-Digest headers) and cites the cryptographic standards. However, it omits whether the operation is network-dependent, state-changing, or gas-consuming despite having a 'network' parameter.

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 with zero waste. First sentence states operation and standard; second states inputs and return values. Front-loaded and appropriately sized for the complexity.

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?

No output schema exists, but description adequately covers return format (headers). With 100% schema coverage and 8 parameters, description doesn't need to document each parameter. Could improve by mentioning verification sibling (erc8128_verify_signature) or network requirements.

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 coverage is 100%, establishing baseline 3. Description enumerates method, URL, headers, body without adding semantic depth (e.g., explaining body→Content-Digest relationship or preset implications). Does not compensate for parameters beyond the core four.

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?

Specific verb ('Sign'), resource ('HTTP request'), and distinguishes via standard 'ERC-8128 (RFC 9421 + EIP-191)'. Clearly differentiates from siblings like sign_message (arbitrary data) and sign_transaction (blockchain transactions) by specifying HTTP request signing and return headers.

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?

Implies usage via 'HTTP request' focus but lacks explicit when-to-use guidance or naming of alternatives like sign_message vs erc8128. No mention of when wallet_id is required beyond the schema description.

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