Skip to main content
Glama

AstraNL Crossing

audit_coordination

Audit how a system of agents coordinates against sixteen measured patterns of lost work: duplicated effort, repeated side effects, loops, amplified errors, lost context. Returns verdict, score and the worst finding with its measurement, fix and closing move. Answer the controls with yes, partial, no or unknown; the questions are at https://verify.astranl.com/v1/coordination/protocol.

Input Schema

TableJSON 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

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries the full burden, and it does meaningful work: it discloses the return shape (verdict, score, worst finding with its measurement, fix and closing move) even though no output schema exists. It does not say what happens if some of the sixteen controls are left unanswered, nor whether any permissions are needed.

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?

Three sentences, front-loaded with what the tool does, then the return values, then the answering convention. The pattern list in sentence one is dense but earns its place by conveying the audit's coverage. No filler or repetition.

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?

For a sixteen-parameter tool with no annotations and no output schema, the description does the important compensating work by describing the return payload and the input convention. The remaining gap is optionality: with zero required parameters it never says whether all sixteen controls must be answered or whether omissions are tolerated.

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 all sixteen control questions are already documented in the schema and the baseline is 3. The description restates the accepted answer vocabulary and adds a protocol URL, but adds no per-parameter meaning beyond what the schema provides.

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?

States a specific verb and resource: it audits how a system of agents coordinates, against sixteen named pattern categories (duplicated effort, loops, amplified errors). The scope is concrete, but it never explicitly contrasts itself with the closest sibling audit_budget, leaving the agent to infer the boundary from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It tells the agent how to fill the inputs (answer yes, partial, no or unknown) and points to an external protocol URL for the questions, which is practical. It gives no when-to-use trigger, no when-not, and no guidance on choosing between this audit and audit_budget when a caller is unsure which audit applies.

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