Skip to main content
Glama

admissibility_preconditions

Check whether a store can answer applicability questions by verifying key agreement, observation channel aliveness, and receipt chain coverage. Reports when a precondition does not apply.

Instructions

Is this store in a state where an applicability question can be ANSWERED at all?

The layer BELOW applicability. evaluate_applicability asks whether a record is admissible now; this asks whether the machinery that answer rests on is still working. Three store-scoped invariants, no new statuses:

key_agreement every key the store holds resolves through the read path observation_channel_alive if records carry locators, some carry a read-time observation receipt_chain_covers_records if this store was WRITTEN with receipts (its .receipts.json sidecar exists) and records exist, the chain is not empty

"Enabled" is this server's INSPEXIMUS_RECEIPTS or a receipt sidecar beside the store; either one makes an empty chain over existing records a failure, as it is for verify_writes on this server. A precondition that cannot apply reports applicable: false and does NOT count as holding -- a question that did not arise has not been answered.

The layer and the first two invariants are @Stratogain's (safal207/Causal-Memory-Layer#289); the third is the same shape: a mechanism switched on and producing nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv2.20.1

TDQS

A4.5/5.0
Behavior4/5

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

No annotations are present, so the description takes on the safety/behavior burden. It states that it creates 'no new statuses', lists the exact invariants, defines when the receipt invariant is enabled, and clarifies the applicable:false semantics. It does not explicitly declare read-only behavior or give the full response shape, so it is strong but not exhaustive.

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?

The main question is front-loaded and the invariants are presented as a clean list, making the structure easy to parse. The provenance sentence about @Stratogain and the issue link adds little for an agent invoking the tool, but it is a single minor detraction in an otherwise dense definition.

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 no-argument tool with no output schema, the description explains the invariant names, the enabling conditions, and the meaning of applicable:false, so an agent can decide when to call it and interpret a false result. An explicit statement of the expected response object would make it fully complete, but it is inferable from the named invariants.

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?

The schema has zero parameters and the description correctly treats the tool as store-scoped, so there are no parameter semantics to add. Per the 0-parameter baseline this is a 4 rather than a 5.

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 description starts with the exact question the tool answers and immediately names the three store-scoped invariants it checks, so the tool's job is concrete. It also distinguishes itself from evaluate_applicability by explaining this is the layer below that check, not a duplicate.

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

Usage Guidelines5/5

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

It gives an explicit alternative (evaluate_applicability) and states the relationship between the two: evaluate_applicability asks whether a record is admissible now, while this tool asks whether the machinery underneath is working. It also warns how to interpret a non-applicable result, which prevents an agent from treating applicable:false as an invariant failure.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools