API keys are not on sale at the moment and buy_key creates no order, so there is no key to claim. Claim the API key for a paid buy_key order. Takes the claim token. The key is returned exactly once, save it. Payments usually become claimable within 30 minutes of confirming on chain
| Name | Required | Description | Default |
|---|---|---|---|
| claim_token | Yes |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Input schema / x-lexicon / bundleSha256Previous value: -"670f7504e3de5031beccee25a2d24e4515f68b893295f6d5b0d3a0665498b2c9"New value: +"25cc80db6d8e9eac73d47a50f7ad6333a21f1972d008a8fed0159de8bfb4b519"Input schema / x-lexicon / bundleSha256Previous value: -"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"New value: +"670f7504e3de5031beccee25a2d24e4515f68b893295f6d5b0d3a0665498b2c9"Input schema / x-lexicon / versionPrevious value: -"0.1.0"New value: +"0.2.0"Input schema / additionalPropertiesAdded value: +falseInput schema / x-lexicon / bundleSha256Previous value: -"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"New value: +"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"Input schema / x-lexicon / bundleSha256Previous value: -"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"New value: +"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"Input schema / x-lexicon / bundleSha256Previous value: -"c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4"New value: +"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"Input schema / x-aliasesAdded value: +{
+ "claim_token": [
+ "claimToken"
+ ]
+}Input schema / x-lexiconAdded value: +{
+ "bundleSha256": "c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4",
+ "name": "ChainHelix Agentic Lexicon",
+ "resolve": "lexicon_resolve",
+ "spec": "lexicon_spec",
+ "version": "0.1.0"
+}Input schema / x-vocabAdded value: +{
+ "claim_token": "agent.claimToken"
+}Output schema / (root)Previous value: -nullNew value: +{
+ "additionalProperties": true,
+ "description": "the issued key for a paid order, once",
+ "type": "object"
+}Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. It usefully discloses that the key is returned exactly once and must be saved, plus typical claimability timing. It omits other important traits such as permissions, failure handling, idempotency, or what happens if the token is invalid.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is short and mostly on topic, but the first sentence is a confusing status message that is not front-loaded toward the tool's action. The key behavioral warning ('returned exactly once, save it') is present but buried after the contradictory opening.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a one-param claim tool with an output schema, the description covers the core action, timing, and one-time key return. It still leaves gaps around prerequisites, token source, authentication, and failure modes, and the contradictory first sentence reduces trust in the guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% for the single required parameter. The description only says 'Takes the claim token,' which names the parameter but does not explain where the token comes from, its format, or how to obtain it after a buy_key order.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The second sentence states a clear verb and resource: 'Claim the API key for a paid buy_key order.' It distinguishes the tool from buy_key and key_order_status by tying it to a paid order. However, the opening sentence ('API keys are not on sale... so there is no key to claim') directly contradicts that purpose and leaves the agent uncertain whether the tool is currently usable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives timing guidance ('Payments usually become claimable within 30 minutes of confirming on chain') and indicates the tool applies after a paid buy_key order. But the same opening sentence says there is currently no key to claim, creating a confusing when-not signal without a clean alternative path.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.