Skip to main content
Glama

Audit coordination

audit_coordination
Read-onlyIdempotent

Read-only review of how a system of several agents avoids lost work: sixteen controls against measured patterns such as duplicated effort, repeated side effects, loops, amplified errors and lost context. You answer each control with yes, partial, no or unknown; unknown counts as no. Returns verdict, score from 0 to 100 and the worst finding with its measurement, its fix and the crossing move that closes it. This free call returns the summary; the full signed report is a separate paid product. For money controls of one agent use audit_budget.

Input Schema

NameRequiredDescriptionDefault
receiptsNoyes, partial, no or unknown. Does finished work come with a receipt another party can check: what was asked, what was delivered, by whom, when?
hop_limitNoyes, partial, no or unknown. Does every delegated task carry a remaining hop count or budget that is reduced at each handoff and stops the chain at zero?
leases_expireNoyes, partial, no or unknown. Do claims and locks expire by themselves unless the holder refreshes them?
context_budgetNoyes, partial, no or unknown. Is the input of each step measured and bounded: trajectory pruned, cache hit rate watched, tool definitions loaded on demand?
stop_conditionNoyes, partial, no or unknown. Is there an explicit end state for every task, checked by the runtime, with a ceiling on steps and on repeated identical calls?
parallelise_gateNoyes, partial, no or unknown. Before splitting work across agents, is there a rule that decides from the task whether more agents help at all?
claim_before_workNoyes, partial, no or unknown. Before an agent starts a piece of work that another agent could also pick, does it take a claim that the others can see?
shared_experienceNoyes, partial, no or unknown. Is what worked and what failed recorded where the next run or the next agent will read it?
variance_measuredNoyes, partial, no or unknown. Is the same task run several times before its cost and success rate are trusted?
policy_not_promptsNoyes, partial, no or unknown. Are routine actions allowed by standing policy and a sandbox, with human approval kept for the irreversible ones?
structured_handoffNoyes, partial, no or unknown. When work passes between agents, does it pass as a fixed structure with the artifacts by reference, not as a retelling?
backoff_and_admissionNoyes, partial, no or unknown. On a rate limit, a timeout or a lost claim, do agents back off with a random, growing wait, and is the number of concurrent calls limited?
idempotent_side_effectsNoyes, partial, no or unknown. Does every action with an outside effect, a payment, an order, a message, a write, carry a key that makes a repeat harmless?
fresh_state_before_writeNoyes, partial, no or unknown. Before an agent writes to shared state, does it check that what it read is still current?
independent_verificationNoyes, partial, no or unknown. Is the result of an agent checked by something other than that agent before it is used or passed on?
counterparty_and_venue_checkNoyes, partial, no or unknown. Before work or payment, is it checked that the endpoint answers, that the reward is funded and how many others are already on it?

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnly=true, idempotent=true, destructive=false, so the safety profile is covered. The description adds genuinely useful context the annotations lack: the answer vocabulary, the rule that 'unknown counts as no', the returned fields (verdict, 0-100 score, worst finding with measurement and fix), and the commercial boundary that the free call returns only the summary while the full signed report is paid.

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

Conciseness4/5

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

Front-loaded with purpose, then the answer mechanics, then the return shape, then the routing line to audit_budget. Dense but each clause carries information; the list of failure patterns is slightly enumerative but justifies the controls' framing.

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?

No output schema exists, and the description compensates by describing the return (verdict, score 0-100, worst finding with measurement, fix, and crossing move) and the free-vs-paid split. Combined with 100% schema coverage across all sixteen controls, an agent has enough to invoke it correctly; only minor operational details are unstated.

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 coverage is 100% and every one of the sixteen controls carries its own question in the schema, so the baseline is 3. The description adds a meaningful cross-cutting semantic rule beyond the schema: each control is answered yes/partial/no/unknown and unknown is treated as no, which changes how an agent should fill the values.

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 ('Read-only review of how a system of several agents avoids lost work') and defines scope precisely: sixteen named controls against measured failure patterns. It explicitly names the sibling it is not ('For money controls of one agent use audit_budget'), so an agent can route without opening either 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?

Clear context for use (multi-agent coordination failures such as duplicated effort, loops, lost context) and it names the alternative audit_budget with the condition that selects it. It does not state when a coordination audit is unnecessary or not applicable, so it stops short of full when/when-not guidance.

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