Skip to main content
Glama

Council of AI GSPC

by io.github.CSOAI-ORG

receipts_batch

PAID (x402 or CSOAI LTD invoice). A historical batch of the estate's measurement receipts via https://councilof.ai/api/receipts/batch: every signed card-v0 leaf whose as_of falls in [from,to] (≤200), each with its Merkle inclusion path and the public root(s) that carried it, plus the root index for the window and one signed manifest card citing the batch sha256. preview=true is free and returns count, span, root count and the sha256 of the exact bytes the paid call returns. Recent leaves are free at /root.json, /cards/ and /api/proof?sha= — the batch sells assembly across history, never a conclusion. No settlement-receipt stream exists (/api/receipts/latest is UNPUBLISHED) and this tool never claims one. Without x_payment the tool returns the 402 challenge.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
toNoWindow end, ISO-8601. Defaults to now.
fromYesWindow start, ISO-8601. Required.
previewNotrue = free: count, span, roots and batch sha256 without the leaves.
x_paymentNoThe X-PAYMENT header value signed against accepts[] from the previous 402. Omit to receive the challenge.

Schema Changelog

Changes observed during successful MCP inspections. Dates show when Glama detected each change.

  1. First observed

TDQS

A4.6/5.0
Behavior5/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. It discloses the paid nature, the preview=true free behavior, the ≤200 leaf cap, the response contents, the signed manifest card, the 402 challenge semantics, and explicitly denies claiming a settlement-receipt stream. This is rich behavioral disclosure beyond parameter names.

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?

The description is dense and front-loaded with the most important fact (paid/402). Every sentence adds information; however it is somewhat lengthy and could be trimmed, but it remains efficient given the complexity of the payment flow and disclaimer.

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?

Given a financial/paid API with no output schema, the description is remarkably complete: it explains what is returned, the limit, the free alternatives, the payment handshake, and what the tool does not do. An agent can invoke this tool correctly without needing additional context.

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 description coverage is 100%, so the schema already documents all four parameters. The description adds useful context by explaining preview=true's free return fields and how x_payment relates to the prior 402's accepts[], but it does not need to compensate for missing schema coverage. It earns a baseline 3 with slight added value.

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?

The description states a specific verb+resource: it retrieves a historical batch of measurement receipts from the councilof.ai API. It clearly differentiates from siblings by naming free alternatives (/root.json, /cards/, /api/proof?sha=) and the absence of a settlement-receipt stream, so an agent can tell it apart from the narrower verification/list tools.

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

Usage Guidelines5/5

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

It gives explicit when-to-use context: use for historical assembly across a date window, and explicitly says free recent leaves are available via listed endpoints. It also warns when not to use it: no settlement-receipt stream exists and /api/receipts/latest is unpublished, preventing misuse. It also explains the 402 payment challenge flow.

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

All Council of AI GSPC toolsInspect
Try in Browser
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A4/5.0
Disambiguation4/5

Each tool has a distinct target resource or action, but some boundaries require careful reading: get_card, verify_card, and verify_inclusion all deal with cards/proofs, while art50_marking_evidence and rwa_evidence are both paid evidence packs. The detailed descriptions help separate them, so misselection is unlikely but not impossible.

Naming Consistency3/5

There are clear verb-prefixed clusters like get_axis/get_card/get_root and verify_card/verify_inclusion, but several tools use bare noun phrases: board_totals, commission_card, receipts_batch, rwa_evidence, and art50_marking_evidence. The naming is readable and snake_case throughout, but the verb/noun convention is mixed.

Tool Count5/5

With 11 tools, the set is well-scoped for a GSPC board, measurement-card, evidence, and verification server. Each tool serves a distinct endpoint or workflow, and none feels redundant or purely decorative.

Completeness4/5

The surface covers board totals, axis details, roots, card retrieval, verification, paid evidence, and historical receipts. A minor gap is the absence of a list_axes tool to enumerate all board axes or a direct get_measurement_card endpoint, but existing tools can work around this via list_cards and verify_card.

Resources