Skip to main content
Glama

GAIP Witness Agent

by io.github.tjcgraham-rgb
OverviewDiscussionsAdmin

Accept registered terms (the other party)

witness_accept_terms

Use this when you are the other party to terms a buyer registered. Pass the terms_id, your own continuity_handle and business_purpose_statement true (businesses only); the buyer confirms it with the agreement_id. Returns an agreement_id naming both parties. Free, no account; records a GAIP receipt only. Inputs must be public and non-personal.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
terms_idYeswt_... from witness_register_terms.
agreement_idNoOnly on an existing agreement: the buyer confirms business purpose or expert determination, or either party declares a consumer contract.
finding_modeNoEVIDENCE_ONLY, or EXPERT_DETERMINATION (needs the buyer's confirmation).EVIDENCE_ONLY
acceptance_ruleNoWhat counts as delivered, by when, and who may ask for the finding.
seller_key_proofNoOptional: {jwk, jws over the terms_id, host}; GAIP checks the signature and whether the host published that key.
consumer_contractNotrue if either party is a consumer: evidence summary only, no finding.
continuity_handleNoRequired: your own continuity handle (continuity_id, token).
agreement_cancelledNoOnly with agreement_id: either party records that it cancelled the agreement (recorded as that party's statement and published in GAIP's revocation feed).
data_classificationNoPUBLIC or NON_PERSONAL_PUBLIC.
mandate_check_receiptNoOptional: the gaip_check_mandate receipt you obtained (or {receipt_sha256, state}) if you act for a person; its state is recorded beside the acceptance as a fact and shown in the finding.
business_purpose_statementNoRequired true from the seller at acceptance and from the buyer (with agreement_id): you act for purposes relating to your trade, business, craft or profession and the deal is not with a consumer. No finding until both parties have stated it.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / agreement_cancelled
      Added value: +{
+  "default": false,
+  "description": "Only with agreement_id: either party records that it cancelled the agreement (recorded as that party's statement and published in GAIP's revocation feed).",
+  "type": "boolean"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / mandate_check_receipt
      Added value: +{
+  "description": "Optional: the gaip_check_mandate receipt you obtained (or {receipt_sha256, state}) if you act for a person; its state is recorded beside the acceptance as a fact and shown in the finding.",
+  "type": "object"
+}
  3. Changed3 schema fields changed
    • changedInput schema / examples
      Previous value: -[
-  {
-    "continuity_handle": {
-      "continuity_id": "<continuity_handle.continuity_id returned by any GAIP tool>",
-      "token": "<continuity_handle.token returned by any GAIP tool>"
-    },
-    "terms_id": "<terms_id from witness_register_terms>"
-  }
-]New value: +[
+  {
+    "business_purpose_statement": true,
+    "continuity_handle": {
+      "continuity_id": "<continuity_handle.continuity_id returned by any GAIP tool>",
+      "token": "<continuity_handle.token returned by any GAIP tool>"
+    },
+    "terms_id": "<terms_id from witness_register_terms>"
+  }
+]
    • changedInput schema / properties / agreement_id / description
      Previous value: -"Only to confirm expert determination (buyer) or declare a consumer contract on an existing agreement."New value: +"Only on an existing agreement: the buyer confirms business purpose or expert determination, or either party declares a consumer contract."
    • addedInput schema / properties / business_purpose_statement
      Added value: +{
+  "description": "Required true from the seller at acceptance and from the buyer (with agreement_id): you act for purposes relating to your trade, business, craft or profession and the deal is not with a consumer. No finding until both parties have stated it.",
+  "type": "boolean"
+}
  4. Changed1 schema field changed
    • addedInput schema / properties / seller_key_proof
      Added value: +{
+  "description": "Optional: {jwk, jws over the terms_id, host}; GAIP checks the signature and whether the host published that key.",
+  "type": "object"
+}
  5. Added

TDQS

A4.1/5.0
Behavior4/5

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

Adds real context beyond the annotations: cost and auth ('Free, no account'), the side effect ('records a GAIP receipt only'), the return value ('an agreement_id naming both parties'), and a data constraint ('Inputs must be public and non-personal'). It does not clarify re-invocation behavior despite idempotentHint=false, which for a two-party acceptance flow would be useful.

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 trigger condition, then packs invocation, return, and constraints into three dense but purposeful clauses. The semicolon-heavy style is compact; nothing is obviously wasteful, though the density trades off some readability.

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?

For an 11-parameter, nested-object tool with no output schema, the description covers the purpose, trigger, core inputs, return value, and constraints adequately, and the schema carries the full parameter burden. It omits the optional higher-complexity paths (finding_mode, seller_key_proof, mandate_check_receipt, consumer_contract), which are left entirely to the schema.

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 schema already documents all 11 parameters in detail, including the nested acceptance_rule and seller_key_proof objects. The description reinforces a few key params (terms_id, continuity_handle, business_purpose_statement, agreement_id) and their cross-parameter relationship, but adds little that isn't already in the schema. Baseline 3 applies.

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 (accept), resource (registered terms), and the caller's role ('the other party'), which cleanly separates it from witness_register_terms. An agent can distinguish it from its siblings without opening any schema.

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?

Opens with an explicit trigger ('Use this when you are the other party to terms a buyer registered') and explains the two-sided flow where the buyer later confirms with an agreement_id. It doesn't explicitly state when not to use it or name the alternative tool for the registering party, so it stops short of a 5.

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

All GAIP Witness Agent 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