Skip to main content
Glama

standing_bulk

Read-only

The standing of up to 25 ERC-8004 agents on BNB Smart Chain in one call, one payment, one signature: for each id the same fields as agent_standing (evidence tier from the paid hires ChainHelix funded and the sealed delivery checks, whether it answers now, the registry feedback rows graded by pattern, the evidence links), and one signed statement over the whole list (EIP-191, the published ChainHelix statement signer, valid 24 hours) with one line per agent: id, tier, reachability, feedback grade. 25 cents for the list against 2 cents per agent one at a time. ChainHelix agents come back as first_party with no verdict and are left out of the statement. Ids are read in the order given; an id that is not a positive integer is refused before payment. Price: 25 cents per call.

Input Schema

NameRequiredDescriptionDefault
idsYesup to 25 ERC-8004 token ids on BNB Smart Chain

Output Schema

NameRequiredDescriptionDefault
countYes
errorNo
agentsYes
statementNo
howToVerifyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"670f7504e3de5031beccee25a2d24e4515f68b893295f6d5b0d3a0665498b2c9"New value: +"25cc80db6d8e9eac73d47a50f7ad6333a21f1972d008a8fed0159de8bfb4b519"
  2. Changed2 schema fields changed
    • 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"
  3. Changed3 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedOutput schema / properties / meta
      Removed value: -{
      -  "additionalProperties": false,
      -  "properties": {
      -    "contentHash": {
      -      "type": "string"
      -    },
      -    "generated": {
      -      "type": "number"
      -    },
      -    "priceUsd": {
      -      "type": "number"
      -    },
      -    "validUntil": {
      -      "type": "number"
      -    }
      -  },
      -  "type": "object"
      -}
    • 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"
      -}
  4. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"New value: +"e5b4290024a229f2bdf97f8fc6a0079c3fe13b77267f41fdcffeb8b26aa1c41e"
  5. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"New value: +"a1c2e10fd3177d6b4d59ca78693e8fb36880165cf0f735f680dd86a510411178"
  6. Changed1 schema field changed
    • changedInput schema / x-lexicon / bundleSha256
      Previous value: -"c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4"New value: +"1eeb782ee15fe69fc80776948e0556fa6b795e210e6305935b2c97b73d955cda"
  7. Changed3 schema fields changed
    • addedInput schema / x-aliases
      Added value: +{
      +  "ids": [
      +    "_ids",
      +    "ids[]"
      +  ]
      +}
    • addedInput schema / x-lexicon
      Added value: +{
      +  "bundleSha256": "c014292cad7497ce9fd68c33345ac32cb42b672c8e77d6c749c26e162cc207e4",
      +  "name": "ChainHelix Agentic Lexicon",
      +  "resolve": "lexicon_resolve",
      +  "spec": "lexicon_spec",
      +  "version": "0.1.0"
      +}
    • addedInput schema / x-vocab
      Added value: +{
      +  "ids": "data.ids"
      +}
  8. Added

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only declare readOnlyHint, so the description carries the heavy behavioral load and does so richly: pricing/payment model, EIP-191 signature by the published signer valid 24h, ChainHelix agents returned as first_party with no verdict and excluded from the statement, ordering preserved, and invalid ids refused before payment. This is exactly the context annotations cannot convey.

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

Conciseness4/5

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

Dense and front-loaded — the core verb+scope leads, followed by field contents, signing, pricing, and edge cases. It is long and heavily comma-packed but each clause (pricing, exclusion, ordering, refusal) earns its place; some tightening would help readability.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, the description needn't explain return formatting, and it doesn't waste effort there. It covers pricing, signing, exclusions, ordering, and validation — everything an agent needs to call correctly and understand cost/behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the single ids param is documented. The description still adds genuine meaning: ids are read in the order given and non-positive-integer ids are refused before payment, which the schema does not state. Marginal but real value on top of a well-covered schema.

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?

States a specific verb+resource with scope: bulk standing of up to 25 ERC-8004 agents on BNB Smart Chain in one call. It anchors field parity against the sibling agent_standing ('same fields as agent_standing') and makes the bulk-vs-single distinction explicit via the pricing contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Clearly signals the batch use case and quantifies the tradeoff: '25 cents for the list against 2 cents per agent one at a time.' This effectively routes the agent to agent_standing for single ids and this tool for batches. It stops short of naming a hard threshold or exclusion beyond the cost comparison.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources