Skip to main content
Glama

Coordination plan check

wever_coordination-plan-check
Read-only

Agent Coordination: submit a multi-agent work plan as recorded: optionally the agents in it, each with its id and the role it holds, and each task with its id, its title, the agents that own it, the outputs or deliverables it produces (the task itself when none is named), the outputs of other tasks it needs and the tasks it waits for. The signed report lists every task with its owners, the tasks it waits on and the inputs nobody produces, every deliverable with the agents that own it (single owner, contested or unowned) and every circular wait, and names a plan that cannot run as written: tasks with no owner, deliverables two agents own, circular dependencies and tasks that need an output no task in the plan produces; then dependencies on tasks not in the plan, owners not among the listed agents, listed agents with no task and agents with no role, with the fix for each. This reads how several collaborating agents divide one job: one principal handing work to one agent is wever_delegation-scope-check, a chain of delegations is wever_delegation-chain-check and one handoff record between two parties is wever_handoff-record-check. Verdict plan_unworkable, plan_gaps, plan_unverified or plan_workable. POST /api/coordination-plan-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": {
      "tasks": "<tasks>"
    },
    "name": "wever_coordination-plan-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
labelNoOptional name recorded in the report.
tasksYesEach task in the plan.
agentsNoEach agent the plan names.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description reinforces this with "no network request, fetch, money movement, message, sharing, configuration change or external write." It adds genuinely useful context beyond the annotations: the verdict vocabulary (plan_unworkable/plan_gaps/plan_unverified/plan_workable), the Ed25519 signed receipt, the x402 price and free-call allowance, and the X-Wever-Wallet-Proof binding requirement. That is real behavioral disclosure, but it sits alongside restatement of the read-only hints.

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?

Purpose is front-loaded, but the opening sentence is a very long run-on clause chain that is hard to parse, and the core report contents are packed into a second dense sentence. Payment, auth, contract, and human-page details each earn their place, but the prose could be structured as discrete sentences without losing content.

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 a 3-parameter tool with no output schema, the description covers everything an agent needs: cost and payment path, wallet-proof signing requirement, endpoint, verdicts, the contents of the returned report, and pointers to the contract spec and human documentation. Nothing material is missing for correct invocation.

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 baseline is 3. The description largely restates schema field meanings (ids, titles, owners, produces, needs, after) and only marginally adds semantics, such as the default that a task produces itself when no output is named — which the schema also states. It does not clarify ID cross-referencing rules or the meaning of `label` beyond "recorded in the report."

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 and resource ("submit a multi-agent work plan as recorded") and then enumerates exactly what the resulting report contains: per-task owners, waits, unproduced inputs, deliverables, and circular waits. It explicitly contrasts itself with wever_delegation-scope-check, wever_delegation-chain-check, and wever_handoff-record-check, so an agent can tell it apart from siblings without opening schemas.

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?

Gives concrete routing guidance: one principal handing work to one agent is the scope check, a chain of delegations is the chain check, and a single handoff record is the handoff record check, implying this tool is for the whole multi-agent allocation. It doesn't give explicit exclusion conditions beyond that contrast, but the context of use is clear.

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