Skip to main content
Glama
Sign In
agent-passport-system-mcp

agent-passport-system-mcp

by agent-passport-system
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript

Verify Settlement Record

aps_verify_settlement
Read-onlyIdempotent

Verify a signed SettlementRecord against S1-S5 checks: signature, Merkle roots, conservation, residual shape, and optional input-receipt cross-check. Returns valid status and failure reason.

Instructions

Verify a signed SettlementRecord under S1-S5 (signature, Merkle roots, conservation, residual shape, optional input-receipts cross-check). S3 conservation is the strongest invariant: a gateway cannot inflate or suppress any contributor's share without breaking it. Returns {valid: true} or {valid: false, reason, detail}. Pass inputReceipts to also recompute input_receipts_hash.

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": {
      "record": "<record>",
      "gateway_public_key": "<gateway_public_key>"
    },
    "name": "aps_verify_settlement"
  }
}

Input Schema

NameRequiredDescriptionDefault
recordYesA signed SettlementRecord
input_receiptsNoOptional — the input Attribution Primitives that fed the settlement. When supplied, S5 cross-checks input_receipts_hash and verifies each receipt individually.
gateway_public_keyYesGateway Ed25519 public key hex

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv4.0.0
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / input_receipts / items
      Added value: +{}
    • changedInput schema / required
      Previous value: -[
-  "gateway_public_key"
-]New value: +[
+  "record",
+  "gateway_public_key"
+]
  2. Addedv2.8.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, so the bar is lower, yet the description adds real value by naming the S1-S5 check set, flagging S3 conservation as the strongest invariant, and disclosing the return contract ({valid: true} or {valid: false, reason, detail}). It stops short of noting failure semantics like error vs invalid result, but this is a solid addition.

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?

Three dense sentences, front-loaded with the core verify action and its checks, then the invariant rationale, then the return/optional-param facts. No filler, though the invariant sentence is marginally verbose.

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 compensates by stating the return shape and the S1-S5 verification scope, and by clarifying the optional cross-check path. It leaves no major gap for calling the tool correctly, though failure-mode specifics (e.g., malformed record handling) are absent.

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?

Schema coverage is 100%, so the baseline is 3, but the description goes beyond the schema by explaining the functional consequence of supplying input_receipts (S5 cross-check plus individual receipt verification) rather than just restating the field. gateway_public_key and record semantics stay purely in the schema.

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 (Verify) and resource (signed SettlementRecord) and enumerates the checks performed (signature, Merkle roots, conservation, residual shape, input-receipts cross-check). This clearly separates it from siblings like generate_settlement and aps_aggregate_settlement that produce rather than validate settlements.

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 gives one conditional usage cue ('Pass inputReceipts to also recompute input_receipts_hash') but never states when to reach for this tool versus generate_settlement/aps_aggregate_settlement, nor any when-not conditions. Usage is implied rather than spelled out.

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

Deploy Server

Other Tools