Skip to main content
Glama
Sign In

Keryx

by io.github.tang-vu
OverviewDiscussionsAdmin

Recorded dispatch purchase outcomes

keryx_purchase_outcomes
Read-onlyIdempotent

Read a public dispatch's retained exact-version BUY/citation/payment observations. Returns bounded sample counts, citation hit rate, calibration bands and integer micro-USDC uncited access cost. Recorded settlement is not revalidated on chain. Historical participant cohort is unknown; causal regret, missed value and cost per supported claim are unmeasured. No research, paid read, current-source backfill, private reviews, signing or learning. Use an existing dispatch ID, never a URL.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "dispatchId": "<dispatchId>"
    },
    "name": "keryx_purchase_outcomes"
  }
}

Input Schema

NameRequiredDescriptionDefault
dispatchIdYesExisting public dispatch ID whose retained purchase outcomes to inspect; supply the ID, not a URL.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / dispatchId / description
      Added value: +"Existing public dispatch ID whose retained purchase outcomes to inspect; supply the ID, not a URL."
  2. Added

TDQS

A3.9/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, closed-world and non-destructive, so the description is free to add interpretation caveats — and it does: settlement is not revalidated on chain, the historical participant cohort is unknown, and regret/missed-value/cost-per-claim are unmeasured. Those caveats materially change how an agent should trust the numbers, though 'bounded sample counts' never explains the bound.

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?

Purpose is front-loaded in the first sentence, followed by a return-value sentence and a caveat sentence; every clause carries information and there is no filler. It is dense with domain jargon and the unm easured-metrics list is long, but nothing is clearly deletable.

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?

With no output schema, the description does the work of explaining the returned fields and their reliability limits, which is the main completeness risk for a reporting tool. Gaps remain: sampling/bounding semantics and behavior on an unknown dispatch ID are unstated, but overall it is sufficient to call the tool correctly.

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% and the single parameter is already documented as 'supply the ID, not a URL.' The description's 'Use an existing dispatch ID, never a URL' restates that verbatim, adding no new semantics (no ID format, origin, or not-found behavior). Baseline 3 applies when the schema carries the parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a specific verb and resource: 'Read a public dispatch's retained exact-version BUY/citation/payment observations,' and then enumerates the returned aggregates (sample counts, citation hit rate, calibration bands, micro-USDC access cost). That is far more specific than siblings like history_read or keryx_public_job_ledger, though it does not name a sibling to contrast against and the heavy jargon ('exact-version BUY observations') slows recognition.

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?

It gives a concrete precondition ('Use an existing dispatch ID, never a URL') and an explicit exclusion list ('No research, paid read, current-source backfill, private reviews, signing or learning') that steers the agent toward research/evidence/history siblings for those needs. It stops short of naming those alternatives or stating positively when this tool is the right pick versus keryx_public_job_ledger.

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

All Keryx 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