ChainHelix for Machines

lexicon_statement

A signed conformance statement for one agent on the BNB Smart Chain ERC-8004 registry, checked against the current ChainHelix Agentic Lexicon version: every argument schema the agent publishes on its own card and on the MCP endpoints its own registration declares, per tool whether canonical names are accepted, an unknown name is refused before payment, and every argument carries a lexicon id (x-vocab); the unmapped arguments are listed. Signed EIP-191 by the ChainHelix statement signer, bound to the lexicon version, the bundle hash and the card hash. An agent that publishes no argument schemas is refused before any charge. Price: 3 dollars per call. A ChainHelix API key does not cover this tool.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	the agent's ERC-8004 token id on BNB Smart Chain

Output Schema

TableJSON Schema

Name	Required	Description	Default
`error`	No
`notes`	No
`result`	No
`signer`	No
`agentId`	No
`message`	No
`conforms`	No
`signature`	No
`statement`	No
`howToVerify`	No
`bundleSha256`	No
`toolsChecked`	No
`toolsPassing`	No
`argumentsTotal`	No
`lexiconVersion`	No
`argumentsMapped`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"670f7504e3de5031beccee25a2d24e4515f68b893295f6d5b0d3a0665498b2c9"New value: +"25cc80db6d8e9eac73d47a50f7ad6333a21f1972d008a8fed0159de8bfb4b519"

Changed2 schema fields changedOct 16, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"New value: +"670f7504e3de5031beccee25a2d24e4515f68b893295f6d5b0d3a0665498b2c9"

changedInput schema / x-lexicon / version

Previous value: -"0.1.0"New value: +"0.2.0"

Changed2 schema fields changedOct 15, 2026

addedInput schema / additionalProperties
```
Added value: +false
```

removedOutput schema / properties / receipt

Removed value: -{
-  "additionalProperties": false,
-  "properties": {
-    "bytes": {
-      "type": "number"
-    },
-    "covers": {
-      "type": "string"
-    },
-    "issuedAt": {
-      "type": "number"
-    },
-    "lookup": {
-      "type": "string"
-    },
-    "network": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "nonce": {
-      "type": "string"
-    },
-    "seq": {
-      "type": "number"
-    },
-    "settleTx": {
-      "type": [
-        "string",
-        "null"
-      ]
-    },
-    "sha256": {
-      "type": "string"
-    },
-    "tool": {
-      "type": [
-        "string",
-        "null"
-      ]
-    }
-  },
-  "type": "object"
-}

Changed1 schema field changedSep 21, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"New value: +"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"

Changed1 schema field changedSep 19, 2026

changedInput schema / x-lexicon / bundleSha256

Previous value: -"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"New value: +"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"

AddedSep 19, 2026

TDQS

A3.6/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden and does well: it discloses signature scheme (EIP-191), signer, bindings (lexicon version, bundle hash, card hash), refusal behavior for agents with no argument schemas, pricing (3 dollars per call), and that an API key does not cover the tool. It doesn't explain return format, but an output schema exists. Side-effect/refusal behavior is explicit.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is one long, dense sentence with a heavy clause list; the key deliverable is front-loaded, but the middle clause about 'per tool whether canonical names are accepted...' is hard to parse. It is appropriately sized for a complex verification tool, but structure could be clearer with sentence breaks.

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 tool's complexity (conformance checking, signing, payment), the description covers scope, refusals, signature binding, pricing, and auth limitation. An output schema is present, so return values needn't be explained. Only minor gaps (no explicit error behavior for invalid id) remain.

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% and the single parameter is fully documented in the schema (type number, ERC-8004 token id on BNB Smart Chain). The description adds no syntax or format beyond what the schema states, so the baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific deliverable: a signed conformance statement for one ERC-8004 agent, checked against the ChainHelix lexicon. It clearly describes what is evaluated (canonical names, unknown-name refusal, x-vocab coverage, unmapped arguments). It is distinguishable from siblings like lexicon_resolve or lexicon_bundle, though those names aren't explicitly referenced.

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 (call this to get a conformance statement for an agent), but there is no explicit when-to-use vs. when-not-to-use, nor are alternatives like lexicon_resolve or agent_standing named. The pricing and API-key exclusion are conditional context, not usage routing.

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

All ChainHelix for Machines 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?