Loading ToolBench

Reading the current corpus…

insumer-examples MCP server · F · ToolBench

← Browse

insumer-examples

github.com/douglasborthwick-crypto/insumer-examples

Code examples for InsumerAPI: on-chain verification across 37 blockchains

2026-07-28+STREAMABLE_HTTP2 tools

30/100

Definition Quality36

Protocol Readiness15

SupportabilityNot measured-

Spec posture

Inferred effective spec 2026-07-28+·current baseline 2026-07-28

Static source inference · medium confidence · evidence: Streamable HTTP

Current-spec patterns detected

Summary

This is a code examples repository, not a production MCP server. The two tools (signDelegation, attest) are documented in agent-delegation-verify.js but lack formal MCP registration, structured schemas, and proper error handling. Tool descriptions are present but vague; input schemas are only partially visible in the provided source. No evidence of MCP framework scaffolding, protocol transport, or proper tool composition patterns. This appears to be a blockchain utility library with minimal MCP integration.

Tools (2)

attestread onlyauth42/100

Attest agent standing: registration + delegation, one signed call. Uses X-API-Key when INSUMER_API_KEY is set; otherwise pays per call via x402 with DEMO_PRIVATE_KEY (no key, no signup).

signDelegationread only47/100

Sign an ERC-7710 root delegation from principal → agent

Issues (8)

CRITICALtool ↗

No formal MCP server registration or framework detected. Tools appear to be inferred from code comments and examples, not explicitly registered with the MCP protocol.

signDelegationattest

CRITICALconstrained-input ↗

Input schemas are incomplete and not properly typed. signDelegation.principal is described as 'viem account' but type is 'object' with no properties defined. attest.body has generic 'object' type with no structure.

signDelegationattest

HIGHtool-description ↗

Tool descriptions are under 100 characters and lack actionable context. 'Sign an ERC-7710 root delegation from principal → agent' does not explain WHEN to call this tool, WHAT it returns, or dependencies.

signDelegationattest

HIGHtool ↗

No output schemas documented. It is unclear what signDelegation or attest return, whether they return transaction hashes, signed payloads, attestation tokens, or other data. Downstream tool chaining is impossible.

Recommendations

Formally register this as an MCP server using the current MCP SDK (Node.js, Python, or Rust). Define tools explicitly via StdioServerTransport or HttpServerTransport with proper capabilities negotiation.
Document complete input schemas for both tools. For signDelegation.principal, define whether it expects {address: string, publicKey?: string} or a viem Account object, with explicit JSON Schema properties. For attest.body, document the exact structure required by the InsumerAPI /v1/attest endpoint (required fields, types, enums).
Expand tool descriptions to 80-150 characters following the pattern: WHAT it does, WHEN to use it, and what preconditions apply. Example: 'Sign an ERC-7710 delegation granting an agent permission to act for a principal account. Required: principal viem account, agent wallet address. Returns: signed delegation bytes. Use before calling attest().'
Document output schemas for both tools. Specify exactly what signDelegation returns (e.g., {signature: string, delegationHash: string, expiresAt?: number}) and what attest returns (e.g., {attestationId: string, verdict: boolean, issuedAt: string, proof: {...}}).
Add per-parameter descriptions with types and constraints. For caveats, explain the structure: 'Array of caveat objects: [{enforcer: address, terms: bytes}]. Caveats restrict the delegation scope. Default: [] (no restrictions).'
Remove credential details from tool descriptions. Move 'Uses X-API-Key when INSUMER_API_KEY is set' to server-side initialization; inject the API key via environment variable and do not expose it in the tool description.

Score history

Overall score trend

↑ 9 points across a rubric change (v1 → v2)

30/100

Scored	Grade	Overall	Spec posture	Rubric
2026-09-22	F	30	2026-07-28+	v2
2026-03-09	F	21	-	v1