Skip to main content
Glama
Sign In

The White Report

by io.github.CYAN-ECLIPSE-TECHNOLOGIES-LLC
OverviewDiscussionsAdmin

List Calls (Machine Format)

calls_list
Read-onlyIdempotent

Machine format (wr.calls.v1, testnet): sealed per-call envelopes from the graded-calls ledger. Optional filters: state (grade_state), asset (substring of asset_or_event). Historical record only. Use calls_get for one call's full envelope once you have its call_id, calls_since to sync only what is new, and get_scoreboard instead for the human-readable track record.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "calls_list"
  }
}

Input Schema

NameRequiredDescriptionDefault
assetNoSubstring match on asset_or_event, e.g. BTC.
stateNoFilter by grade_state, e.g. OPEN.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, and the description still adds real context: the wire format and version (wr.calls.v1), testnet scope, and that results come from a sealed historical ledger rather than live data. It stops short of disclosing result limits, pagination, or ordering, which are the main remaining behavioral unknowns for a list tool.

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?

Three sentences, front-loaded with the format/scope that governs how to read everything downstream, then filters, then routing. Every clause carries information an agent needs.

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 two-optional-filter read tool with full schema coverage and no output schema, this covers scope, format, and routing well. The gap is that 'sealed per-call envelopes' is never unpacked and list-shape concerns (counts, limits, ordering) go unmentioned.

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%, so the baseline is 3. The description restates the filter mapping (state→grade_state, asset→substring of asset_or_event) that the schema properties already document, adding no syntax, casing, or matching-behavior detail beyond what is structured.

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 (list sealed per-call envelopes from the graded-calls ledger) and ties it to the machine-format variant, which cleanly separates it from the human-readable track record. An agent can distinguish this from calls_get and get_scoreboard without opening any schema.

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?

Names three alternatives with the exact condition that selects each: calls_get once a call_id is known, calls_since for incremental sync, get_scoreboard for the human-readable view. It also scopes the tool with 'Historical record only'.

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

All The White Report toolsInspect
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