Skip to main content
Glama
Sign In

Keryx

by io.github.tang-vu
OverviewDiscussionsAdmin

Plan and inspect private evidence procurement

evidence_procurement
Read-onlyIdempotent

Assess missing evidence requirements, supplied provider offers, selections, deliveries and caller reviews with the shared private evidence procurement contract. Amounts are exact integer micro-USDC. Signature and content-binding checks do not establish delivery quality, buyer authority, payment or settlement. No fetching, model, provider, database, history, purchase, escrow or reward I/O. Caller selections and reviews are assertions, not financial authorization. Inputs and results may be retained by your MCP client; choose its privacy settings before sharing private material.

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": "evidence_procurement"
  }
}

Input Schema

NameRequiredDescriptionDefault
formatNoOptional receipt format: json (default), markdown or csv. Formatted text is bounded to 524288 UTF-8 bytes and cannot be restored. Structured procurement stays unchanged.
packetNoVersion-1 private-evidence-procurement packet, at most 65536 UTF-8 bytes. Supply original inputs, never a derived procurement result.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Optional receipt format: json (default), markdown or csv. Formatted text is bounded to 524288 UTF-8 bytes and cannot be restored. Structured procurement stays unchanged."
+}
  2. Added

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds genuinely non-redundant behavior: it delimits what signature and content-binding checks do NOT establish (delivery quality, buyer authority, payment, settlement), states selections and reviews are assertions rather than financial authorization, and warns that inputs and results may be retained by the MCP client. That is substantive boundary context beyond the annotations.

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?

Five sentences, all front-loaded on the purpose, and the negative-I/O list is the only real padding. It is dense and jargon-heavy ('shared private evidence procurement contract'), but no sentence is purely redundant and the privacy warning is placed last, which is correct for a caveat.

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

Completeness3/5

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

Annotations cover the safety profile and the schema fully documents both inputs, so the basics are complete. What is missing is the shape of what the assessment produces - there is no output schema, so the description is the only place that could say what the returned receipt or procurement result looks like, and it does not.

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 both parameters carry full inline documentation (format's bound of 524288 UTF-8 bytes and its non-restorability; packet's 65536-byte limit and the 'never a derived result' rule). The description adds essentially nothing about either parameter - the micro-USDC note concerns packet contents, not parameter syntax - so the baseline 3 is appropriate when the schema does all the work.

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

Purpose3/5

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

The description names an act ('Assess') and enumerates the subject matter it operates on (missing evidence requirements, offers, selections, deliveries, reviews) against 'the shared private evidence procurement contract.' But it never states plainly that it evaluates a single version-1 procurement packet supplied by the caller, and it does not name any sibling it differs from - the reader has to infer its role from the schema and the surrounding tool list.

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?

Usage is conveyed only negatively: 'No fetching, model, provider, database, history, purchase, escrow or reward I/O' tells the agent what this tool will not do, implicitly steering it toward the history_* and keryx_purchase_outcomes siblings for those needs. There is no explicit when-to-use statement, no named alternative, and no statement of prerequisites for calling it.

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