Skip to main content
Glama

Public Merkle root

get_root
Read-onlyIdempotent

GET the permissionless public-root at https://councilof.ai/root.json. Returns merkle_root, card_count, as_of, and UNMEASURED notes. Separate from GSPC. Three states: VALID (fetched), UNREACHABLE (could not fetch), UNCHECKABLE (body unreadable). Never a certificate.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
kindNo
as_ofNo
stateYesVALID, UNREACHABLE or UNCHECKABLE
sourceNo
not_gspcNo
card_countNo
merkle_rootNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "as_of": {},
      +    "card_count": {},
      +    "kind": {},
      +    "merkle_root": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "not_gspc": {
      +      "type": "boolean"
      +    },
      +    "source": {
      +      "type": "string"
      +    },
      +    "state": {
      +      "description": "VALID, UNREACHABLE or UNCHECKABLE",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "state"
      +  ],
      +  "type": "object"
      +}
  2. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -{
      -  "properties": {
      -    "as_of": {},
      -    "card_count": {},
      -    "kind": {},
      -    "merkle_root": {
      -      "type": [
      -        "string",
      -        "null"
      -      ]
      -    },
      -    "not_gspc": {
      -      "type": "boolean"
      -    },
      -    "source": {
      -      "type": "string"
      -    },
      -    "state": {
      -      "description": "VALID, UNREACHABLE or UNCHECKABLE",
      -      "type": "string"
      -    }
      -  },
      -  "required": [
      -    "state"
      -  ],
      -  "type": "object"
      -}New value: +null
  3. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "properties": {
      +    "as_of": {},
      +    "card_count": {},
      +    "kind": {},
      +    "merkle_root": {
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    },
      +    "not_gspc": {
      +      "type": "boolean"
      +    },
      +    "source": {
      +      "type": "string"
      +    },
      +    "state": {
      +      "description": "VALID, UNREACHABLE or UNCHECKABLE",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "state"
      +  ],
      +  "type": "object"
      +}
  4. First observed

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the readOnlyHint and idempotentHint annotations, the description discloses operational states (VALID, UNREACHABLE, UNCHECKABLE), clarifies that it never returns a certificate, and notes the permissionless nature. This adds meaningful behavioral context about failure modes and output guarantees.

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

Conciseness5/5

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

The description is three sentences with no filler. The main action and URL are front-loaded, followed by return fields and states. Every sentence earns its place and the text is highly efficient.

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?

For a zero-parameter GET tool with an output schema (as indicated), the description covers the endpoint, return fields, and state behavior. The term 'UNMEASURED notes' is cryptic and could be clarified, and usage guidance is minimal, but overall the tool is simple enough that this is sufficient.

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?

The tool has zero parameters, so the description need not elaborate on parameter semantics. The baseline for no-parameter tools is 4, and the description correctly omits any irrelevant parameter detail.

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 clearly states the tool fetches the permissionless public Merkle root from a specific URL, lists the exact return fields (merkle_root, card_count, as_of, UNMEASURED notes), and distinguishes it from GSPC and from being a certificate. The verb 'GET' plus resource and expected output make the purpose unambiguous.

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?

The description notes 'Separate from GSPC' which hints at a distinction, but it does not explicitly state when to use this tool over its siblings (e.g., get_axis, verify_inclusion). No alternative tools are named and no conditions for selection are given, leaving usage inference largely to the agent.

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