Skip to main content
Glama

Coordination conflict check

wever_coordination-conflict-check
Read-only

Agent Coordination: submit two or more collaborators’ recorded actions and decisions on the same job: each with its id, the agent, its kind (a commitment of a resource, an output, a decision, a reversal or other), the resource it commits or the subject it is about, what it says or decides, when it was taken, the action it reverses, whether an output shipped outside the group, the agents told about it and whether it was withdrawn; optionally the agents on the job; and the rule that settles a collision (the lead decides, the principal decides, the first claim wins, the agents vote, or no rule) with who decides. The signed report counts the live, reversed and withdrawn actions, lists every collision, and names direct collisions: the same resource committed twice, contradictory outputs shipped and a decision one agent reversed without telling the others; then decisions and unshipped outputs that diverge on one subject, no resolution rule and a lead or principal rule with no one to decide, with the fix for each. Collaborators here share one goal: parties with opposing interests stuck on terms are wever_negotiation-deadlock-check, and knowledge entries that contradict each other are wever_knowledge-conflict-check. Verdict collaborators_collide, collision_gaps, collisions_unverified or no_collisions. POST /api/coordination-conflict-check. Reads only the material in the call: no network request, fetch, money movement, message, sharing, configuration change or external write. Paid URL: 0.10 USDC per call on Base via x402 exact, with the shared 10 signed-wallet free calls per rolling 30 days. Bind X-Wever-Wallet-Proof to the exact JSON arguments and the tool route. Returns a report with an Ed25519 signed receipt. Contract: /api/agent-coordination-contract. Human page: https://weverlabs.com/agent-coordination/.

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": {
      "actions": "<actions>"
    },
    "name": "wever_coordination-conflict-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
ruleNo
labelNoOptional name recorded in the report.
agentsNoThe agents working on the job, to read who a reversal must reach.
actionsYesEach recorded action or decision on the job.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.1/5.0
Behavior5/5

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

Well beyond the annotations, it discloses that the call reads only the supplied material with no network request, fetch, money movement, message, sharing, config change or external write; that it costs 0.10 USDC per call via x402 with ten signed-wallet free calls per rolling 30 days; that X-Wever-Wallet-Proof must bind to the exact JSON arguments and route; and that the return carries an Ed25519 signed receipt. These are exactly the behavioral facts an agent cannot infer from readOnlyHint/destructiveHint and it also enumerates the four possible verdicts.

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 content is dense and nearly all of it is substantive (verdicts, sibling routing, payment, auth, receipt), but it is delivered as a chain of semicolon-joined clauses with the payload fields enumerated at the front, which duplicates the schema and delays the actual purpose statement. Reordering to lead with the purpose and collapsing the field list would lose nothing.

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 nested, multi-field conflict checker with no output schema and no output description in the annotations, the description still explains what the report contains (counts of live/reversed/withdrawn actions, every collision, direct collisions, divergent decisions and unshipped outputs, missing resolution rule, and the fix for each) and names all four verdicts. Payment, auth binding, contract path and human page are also supplied, so an agent has everything needed to call it and interpret the result.

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 75% with rich per-field descriptions and examples already in the schema (resource 'such as the 3 PM demo slot', subject 'such as the launch date', the resolution enum with all five values). The description restates the same field list and the same rule semantics in prose without adding syntax, defaults, or cross-field constraints, so it adds little beyond the schema; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description makes clear that this tool takes collaborators' recorded actions and decisions on one shared job and returns a report of collisions among them, and it names the sibling conflict-checkers it is not (negotiation-deadlock-check, knowledge-conflict-check). The verb-plus-resource statement is sound, but it is buried inside a long parameter enumeration rather than front-loaded, so the agent has to read several clauses before learning what the tool does.

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 explicitly scopes usage by contrast: 'Collaborators here share one goal' while opposing parties stuck on terms go to wever_negotiation-deadlock-check and contradicting knowledge entries go to wever_knowledge-conflict-check. That is real routing guidance against two named alternatives, though it never states a positive 'use this when' trigger and gives no exclusions for the many other coordination-* siblings.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources