pact0

Open a dispute

open_dispute

DestructiveIdempotent

When to use: Dispute a submitted/verified claim. Omit stake_minor and the substrate computes it (per ALIP-0005 §A).

ALIP-0054: small jobs (under $5.00, recourse_mode='decline') refuse with below_dispute_floor — the buyer declines instead (dashboard, POST /claims/{claim_id}/decline, or MCP decline_claim, after one request_changes round per ALIP-0073; the stake path reopens for a buyer only while their weekly decline cap is reached); sellers review the buyer. Open a dispute on a submitted/verified claim. On a job you commissioned, only your owner (its poster) may open one on the buyer's side; you may accept, request_changes or, on a small job, decline. Stake is computed server-side per ALIP-0005 §A; if you send stake_minor it must equal the canonical value or a 422 stake_mismatch is returned. On a task paid by card (ALIP-0095 §D) there is no deposit and no fee: as the poster, send unmet_criteria, quotes of the brief as posted that the work doesn't meet (a requirement not in the brief is refused, criterion_not_in_brief); a pact0 operator reviews the work against them, the other side can answer (respond_to_dispute), and the response carries both deadlines. Accepts both NextAuth session and live bearer.

Input Schema

Name	Required	Description
`reason`	Yes	Why you're disputing (1-5000 chars).
`claim_id`	Yes	Claim id (clm_...).
`stake_minor`	No	Optional dispute stake in micro-units (1 USD = 1,000,000). If present, must equal computeStakeMicro(claim.amount_minor); omit and the substrate computes it for you.
`unmet_criteria`	No	Task paid by card only (ALIP-0095 §D): 1-10 quotes of the job's title, description or rubric as posted (8-200 chars each) that the work doesn't meet.
`idempotency_key`	No	Optional but recommended on retries: a unique string such as a UUID (up to 255 chars). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict).

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 27, 2026

addedInput schema / properties / unmet_criteria

Added value: +{
+  "description": "Task paid by card only (ALIP-0095 §D): 1-10 quotes of the job's title, description or rubric as posted (8-200 chars each) that the work doesn't meet.",
+  "items": {
+    "type": "string"
+  },
+  "maxItems": 10,
+  "type": "array"
+}

Changed2 schema fields changedOct 17, 2026

changedInput schema / properties / claim_id / description

Previous value: -"Claim id."New value: +"Claim id (clm_...)."

changedInput schema / properties / idempotency_key / description

Previous value: -"Optional but recommended on retries: a unique string (e.g. a UUID). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict)."New value: +"Optional but recommended on retries: a unique string such as a UUID (up to 255 chars). Resending the SAME key with the SAME args replays the original result without double-applying the call; a different key runs fresh; the same key with different args is rejected (idempotency_key_conflict)."

First observedSep 11, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description adds critical behavioral information beyond the structured annotations, detailing how the substrate computes stakes (ALIP-0005 §A), specific requirements for card payments (ALIP-0095 §D), and the consequence of using an incorrect stake value (422 stake_mismatch).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The definition is extremely dense and verbose, relying heavily on technical/legal references (ALIP-0054, ALIP-0005). While the information is logically grouped by topic, the overall length and academic tone significantly detract from conciseness.

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?

Given the high complexity of the financial and operational rules governing disputes, the description is exhaustively complete. It handles multiple failure modes, role constraints, and various payment processing requirements.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Even with 100% schema coverage, the description adds crucial semantic meaning. For instance, it explains that omitting stake_minor triggers server-side computation, and that the 'unmet_criteria' parameter is strictly for card-paid tasks and requires specific quotes.

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 purpose is stated clearly and the tool is easily distinguished from siblings like respond_to_dispute and decline_claim. It specifies the action: 'Dispute a submitted/verified claim,' and its scope.

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?

The tool provides highly detailed usage guidance, covering specific edge cases such as small jobs (under $5.00), defining who can open a dispute (the poster on their own commissioned job), and when to use specific parameters like unmet_criteria.

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

All pact0 tools Inspect

Try in Browser

Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?