Skip to main content
Glama
Sign In

SAAX Protocol

by io.github.bryantrudy24
OverviewDiscussionsAdmin

Get recovery status and pending actions for a commitment

get_recovery_status

Returns the authoritative commitment state, the caller's authorization status (active/revoked/expired), whether the commitment is recoverable, and the caller's permitted next actions. Reconciles the durable commitment row and the caller's authorization record before returning. The caller must present an EIP-712 authority proof. Read-only. For the raw journal, use get_commitment_history; to continue a workflow, use resume_commitment.

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": {
      "commitmentId": "<commitmentId>",
      "agentId": "<agentId>",
      "role": "<role>",
      "proof": "<proof>"
    },
    "name": "get_recovery_status"
  }
}

Input Schema

NameRequiredDescriptionDefault
roleYesThe caller's role on this commitment
proofYesEIP-712 AuthorityProof signed by the caller (issuer = signer)
agentIdYesThe caller's durable agent identifier
commitmentIdYesThe commitment id

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden, and it does most of it: it declares read-only semantics, discloses that the durable commitment row and the caller's authorization record are reconciled before returning, and states the EIP-712 proof requirement. It stops short of describing failure behavior when the proof is invalid or the authorization is revoked, which is the one remaining behavioral gap.

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?

Front-loaded with the return payload, then prerequisites, then sibling routing — a sensible order with no filler. Four sentences and every one carries information, though 'Read-only' sits slightly awkwardly after the reconciliation sentence rather than with the other behavioral facts.

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 and no annotations, the description must describe the return payload itself, and it does so precisely enough for an agent to know what to expect. Given the reconciliation complexity it adequately covers preconditions and results; only error/edge-case behavior is left unstated.

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%, so the four parameters (commitmentId, agentId, role enum, proof) are already documented. The description's mention of the EIP-712 authority proof largely restates what the schema says for 'proof', and it adds only the implicit framing that the authorization status returned is scoped to the calling agent and role. Baseline 3 is warranted.

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 (returns) and enumerates exactly what is returned: authoritative commitment state, caller's authorization status (active/revoked/expired), recoverability, and permitted next actions. It differentiates itself from get_commitment_history and resume_commitment by naming them with their distinct roles, so an agent can route without opening a 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?

Gives explicit alternative routing with conditions: raw journal goes to get_commitment_history, workflow continuation goes to resume_commitment. It also states the precondition (caller must present an EIP-712 authority proof), which tells the agent when this call will fail rather than just what it does.

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

All SAAX Protocol 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