SAAX Protocol

Accept a signed proposal and create exactly one authenticated commitment

accept_commitment

Accepts a signed preflight proposal with explicit buyer authorization and creates exactly ONE authenticated SAAX commitment. Revalidates the proposal (trusted provider key, profile version, expiry, combination, manifest digest), verifies the BUYER'S SIGNATURE over the exact proposal digest and terms digest, durably accepts once (single-writer store), and returns the operation + commitment. Creates NO payment authorization, custody funding, service execution, or release. A buyer acceptance is NOT a payment authorization or evaluator release verdict. Errors are typed DSC_* codes. Idempotent: same idempotencyKey + same request returns the same operation; same key + different request -> DSC_NONCE_CONFLICT; a single-use proposal cannot be re-accepted under a new key -> DSC_PROPOSAL_REUSED.

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": {
      "proposal": "<proposal>",
      "acceptance": "<acceptance>",
      "idempotencyKey": "<idempotencyKey>"
    },
    "name": "accept_commitment"
  }
}

Input Schema

Name	Required	Description
`proposal`	Yes	The signed proposal returned by prepare_commitment (full object incl. signature)
`acceptance`	Yes	The buyer acceptance contract (schemaVersion acceptance-v1, action accept_commitment, domain saax:acceptance:v1, signed by the buyer)
`idempotencyKey`	Yes	Caller-scoped idempotency key (>= 8 chars)

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 6, 2026

TDQS

A4.6/5.0

Behavior5/5

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

With no annotations, the description carries the full burden and does so: it lists the exact revalidation checks (provider key, profile version, expiry, combination, manifest digest), the buyer signature verification, the single-writer durable accept, and the returned payload. It also discloses idempotency semantics and the precise DSC_* error codes for key reuse and single-use proposal reuse.

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 core action and result, then layered with validation, exclusions, and error semantics in a logical order. The negative framing ('NOT a payment authorization or evaluator release verdict') restates an earlier exclusion, which is slightly redundant but justified as a common misread.

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

Completeness5/5

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

For a three-required-parameter mutation with nested objects, no annotations, and no output schema, the description supplies prerequisites, validation behavior, idempotency rules, error taxonomy, and the return shape ('operation + commitment'). Nothing an agent needs to invoke it safely is missing.

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 adds real meaning beyond the schema by explaining that the proposal must include its signature, that the acceptance is buyer-signed over proposal and terms digests, and that idempotencyKey scopes replay versus conflict behavior.

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 pair ('Accepts a signed preflight proposal ... creates exactly ONE authenticated SAAX commitment') and anchors the input to prepare_commitment, distinguishing it from siblings like create_commitment and get_commitment. The scope negatives sharpen the boundary further.

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?

Clearly implies the precondition (a signed proposal produced by prepare_commitment plus an explicitly authorized buyer signature) and enumerates what this tool must not be used for (payment authorization, custody funding, execution, release). It stops short of naming a specific alternative sibling for the excluded cases, so it is strong context without explicit routing.

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

All SAAX Protocol tools Inspect

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

Need Help?