Skip to main content
Glama

Coordination progress check

wever_coordination-progress-check
Read-only

Agent Coordination: submit a joint progress report from several agents with the plan it reports against: each plan task with the agent the plan gives it to; each progress claim with the task, the agent making it, its status (done, in progress, blocked or not started) and the evidence behind it (a link, a commit, a test run, a file or a record id); and each blocker with its id, the task it blocks, what it is and who is clearing it. The signed report gives every plan task with the agents claiming it and its status (done, in progress, blocked, not started, claimed done twice, disputed or unclaimed), counts the claims, the done claims with evidence and the claims off the plan, lists every blocker as owned or unowned, and names progress that is misreported: tasks claimed done by two agents, plan tasks nobody claims and blockers with no owner; then done claims with no evidence attached, tasks agents report differently, claims off the plan, claims by an agent other than the plan’s owner and tasks reported blocked with no blocker, with the fix for each. A delegate’s duty to report to one principal is wever_delegation-reporting-check, partly done work in one task system is wever_partial-state-check and one run’s trace is wever_observability-trace-check. Verdict progress_misreported, progress_gaps, progress_unverified or progress_accounted. POST /api/coordination-progress-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": {
      "plan": "<plan>",
      "claims": "<claims>"
    },
    "name": "wever_coordination-progress-check"
  }
}

Input Schema

NameRequiredDescriptionDefault
planYesEach task in the plan.
labelNoOptional name recorded in the report.
claimsYesEach progress claim in the joint report.
blockersNoEach blocker the report names.

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 readOnlyHint=true, openWorldHint=false, destructiveHint=false, and the description goes well beyond them: it states the tool reads only the material in the call with no network request, fetch, money movement, message, sharing or external write, and it discloses the auth and cost model (0.10 USDC via x402 exact, 10 free signed-wallet calls per 30 days, X-Wever-Wallet-Proof bound to the exact JSON arguments and route). The Ed25519 signed receipt is also disclosed, which matters for a non-idempotent POST to a paid endpoint.

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 opening clause is front-loaded correctly, but the middle is one long semicolon chain, and the return description is a dense list of eight-plus report elements run together with the violation list. Much of it is necessary content, yet it could be broken into shorter sentences without losing information, and the closing pricing/contract/URL lines are appended without clear separation from the behavioral content.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description carries the return-value burden and does so thoroughly: it describes the signed report contents, blocking ownership, and the misreporting categories with fixes. The main gap is that the four verdicts (progress_misreported, progress_gaps, progress_unverified, progress_accounted) are named but never defined, so an agent cannot predict which verdict a given input will produce.

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 and the schema already documents plan, claims, blockers and label. The prose restates the same meaning — status values spelled out as 'done, in progress, blocked or not started' and evidence as 'a link, a commit, a test run, a file or a record id' — without adding format, cross-field, or validation guidance beyond what the schema holds.

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 definition names a specific verb and resource — 'submit a joint progress report from several agents with the plan it reports against' — and enumerates exactly what the payload contains (plan tasks, claims, blockers) and what the signed report produces. It also distinguishes itself from three named sibling checks (delegation-reporting-check, partial-state-check, observability-trace-check), so an agent can place it without opening the schema.

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?

Usage routing is present for adjacent cases: delegation duty to one principal, partly-done work across task systems, and single-run trace each get pointed at a different tool. What is missing is any explicit contrast with the nearest-looking siblings in the list, wever_coordination-report-check and wever_coordination-state-check, and no 'when-not-to-use' condition is stated. The context is clear but the exclusion set is incomplete.

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