LLPRO Campus

When two parties to one deal disagree, record both signed positions and what they agree on and contest. Records; never rules

dispute_record

Read-onlyIdempotent

Neutral record when two parties to one deal disagree. Send the Transaction Audit bundle of the deal (parties and signed events) and two positions, one signed by each party's key from that bundle: dispute_id, party_id, public_key, bundle_hash (SHA-256 of the canonical bundle, as Transaction Audit returns it), filed_at, claim text, optional facts {name: value} and optional events {event hash: agree|contest}. Get back recorded or invalid, every check, what both agree on, what is contested, what only one states, and a record signed by LLPRO with the time we saw it, checkable offline. It records; it never rules or awards. Nothing is kept (the A2A door keeps a result for 7 days). Free.

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": {
      "bundle": "<bundle>",
      "positions": "<positions>"
    },
    "name": "dispute_record"
  }
}

Input Schema

Name	Required	Description	Default
`bundle`	Yes	the Transaction Audit bundle exactly as audited: {parties, events}
`positions`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Beyond the readOnly/idempotent annotations, the description discloses retention ('Nothing is kept; the A2A door keeps a result for 7 days'), output shape (recorded or invalid, every check, agreements, contests, single-party claims), a signed timestamped record verifiable offline, and cost ('Free'). It never states authentication requirements or what happens on an invalid signature beyond the 'invalid' outcome.

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?

Purpose and the 'never rules' boundary are front-loaded, then inputs, then outputs, which is a sensible order. The middle sentence is long and packs many items together, but every clause carries operational content rather than filler.

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 two-parameter tool with nested objects and no output schema, the description covers inputs, validation outcomes, the structure of the returned record, its signature and offline verifiability, and retention. Nothing an agent needs in order to call it correctly appears to be 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?

With only 50% schema coverage, the description supplies real meaning: bundle_hash is the SHA-256 of the canonical bundle as Transaction Audit returns it, each position is signed by a party's key from that bundle, facts are {name: value}, events map hash to agree|contest, and positions are exactly two. It omits envelope-level fields like sig canonicalization and max sizes, which the schema covers.

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?

The first sentence names the specific verb and resource ('neutral record when two parties to one deal disagree') and states scope: the Transaction Audit bundle plus two positions, one signed by each party's key. The closing clause 'It records; it never rules or awards' sharply separates it from any adjudicating sibling such as outcome_dispute.

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?

It gives a clear trigger ('when two parties to one deal disagree') and states the required input provenance: positions must be signed by keys taken from the same bundle. Exclusions are implied rather than enumerated — it doesn't say when to prefer a ruling or verification tool instead — but the context is unambiguous.

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

All LLPRO Campus 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?