Skip to main content
Glama

Coordination boundary check

wever_coordination-boundary-check
Read-only

Agent Coordination: submit how one job is divided between the participating agents: each part of the job with its name, the other names assignments use for it, whether it is worked jointly by design and the agent that leads it, and each agent’s assignment with the parts it is told to do, the parts it is told to leave alone and the assignment as written. The signed report gives every part with the agents whose assignments cover it (owned, overlapping, jointly worked with or without a lead, or unowned), every assignment with the parts it covers, read from its list or else from the parts its statement names, and its wording (bounded, hedged or open-ended), and names territory that collides: parts two agents are told to do, parts in nobody’s assignment and assignments stated so loosely, with anything else, as needed or etc., that overlap is inevitable; then edges stated as help or support, assignments naming parts not on the job’s list, jointly worked parts with no lead and agents with no stated territory, with the fix for each. The access that travels with one handed-off task is wever_handoff-scope-check and the tasks one delegate may do for one principal are wever_delegation-scope-check. Verdict territory_collides, territory_gaps, territory_unverified or territory_clear. POST /api/coordination-boundary-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": {
      "parts": "<parts>",
      "assignments": "<assignments>"
    },
    "name": "wever_coordination-boundary-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
partsYesEach part of the job.
assignmentsYesEach agent’s assignment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.2/5.0
Behavior5/5

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

Annotations already declare read-only, closed-world and non-destructive, and the description goes well beyond them: pricing (0.10 USDC per call on Base via x402 exact, 10 signed-wallet free calls per rolling 30 days), the required X-Wever-Wallet-Proof binding to exact JSON arguments and route, the no-network/no-write guarantee, and the Ed25519 signed receipt on the returned report. It also spells out the verdict space (territory_collides, territory_gaps, territory_unverified, territory_clear), which the agent cannot get from annotations.

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?

Almost all content earns its place, but it is delivered as a single sprawling semicolon-chained sentence that front-loads the input enumeration instead of the tool's purpose. The dense phrasing ('assignments stated so loosely, with anything else, as needed or etc., that overlap is inevitable') makes the collision criteria hard to parse on a first read.

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?

There is no output schema, and the description compensates by describing the report structure, the per-part and per-assignment breakdowns, the four verdicts, and the fix-per-edge output. Payment, auth binding, signed receipt, sibling boundaries and the contract/human reference pages are all present, so an agent has what it needs to invoke the tool correctly.

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 description coverage is 100%, so the baseline is 3, but the description adds real meaning: it explains that a part carries its name, aliases, joint-work flag and lead, and that an assignment's statement is read both for open-ended wording and, when no covers list is given, for the parts it names. That reading rule for `statement` is not stated in the schema and materially changes how the agent should populate the field.

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 this accepts a job partitioning (parts + assignments) and returns a signed report naming colliding territory, gaps and edges. It also distinguishes itself from wever_handoff-scope-check and wever_delegation-scope-check by naming what those cover. It loses a point because the actual verb is never stated crisply — the opening sentence describes the payload rather than saying 'checks whether the division of work between agents overlaps or leaves gaps', so the agent must reconstruct purpose from the enumerated report contents.

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 usable routing context by naming two adjacent checks and the distinct subject each covers (per-task access scope, per-delegate task scope), which implies this tool handles job-partitioning territory. There are no explicit when-to-use/when-not-to-use instructions or prerequisites, and the other coordination siblings (conflict, escalation, roster, plan) are not contrasted.

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