Loading ToolBench
AIRLOCK as an MCP server: the agent's only route to production, and it is held for a human. Provides change-control gate tools for irreversible production work with mandatory human approval.
Airlock MCP exhibits strong domain-specific design with clear, action-oriented tool names (airlock_read_policy, airlock_open_change, airlock_request_approval) that convey intent. All 9 tools have descriptions (avg ~120 chars, within 10-1024 baseline). Input schemas are present with type declarations and parameter descriptions. However, output schemas are not documented in the visible source, critical for LLM planning. Parameter descriptions are adequate but lack constraint details (e.g., change_class enum values are stated in description text, not as formal enum constraints). Error handling and recovery guidance are absent. Tool composition is sound (each tool has one responsibility), but descriptions could be more explicit about prerequisites and when to call each tool in sequence.
Attach the proof that your change is safe. Attaches a certificate to a change dossier after verification against a shadow copy.
Confirm whether the change would be approvable. Evaluates the gate decision for a change dossier and reports whether it would open or what is blocking it.
List recent changes to find the one you are working on or check whether it already exists. Returns up to 25 most recent dossiers.
Record what you intend to do and its inverse. Opens a new change dossier with the specified class, description, and optional inverse operation.
Learn what this class of change requires before you plan it. Returns the policy rule for a given change class including certificate requirements, approver quorum, freshness, and any limits or blackout windows.
Output schemas not documented. LLMs cannot plan downstream tool calls or extract required fields (e.g., dossier_id from airlock_open_change, gate status from airlock_check_gate). Responses must include structured field definitions.
change_class parameter accepts enum values ('ddl', 'dml', 'access', 'secret', 'infra', 'billing') stated only in description text, not as formal JSON Schema enum constraint. LLMs cannot parse text-embedded enums reliably.
airlock_attach_certificate and airlock_record_review accept complex nested objects (certificate, findings) with no schema detail visible. Parameter descriptions lack structure, type, and required field guidance.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | <=2025-11-25 | v2 |
Record the facts you looked up for this change, instead of asking a human for them. A fact lives in a system of record — the currency on a Stripe account, a user's country, the schema of a table.
Record a review of the change from an external system. Attaches review findings from security scanners, linters, or other automated systems.
Hand the change to a human for approval. This tool is held for approval by the harness and is the only tool that moves a change towards production.
Stamp a skill onto the change to record that you used a particular capability. Records which skills or capabilities were exercised during the change.
No error handling or recovery guidance documented. Tools like airlock_request_approval (IRREVERSIBLE) and airlock_check_gate lack dry-run, confirmation, or actionable error messages to guide agent recovery.
airlock_list_changes returns 'up to 25 most recent dossiers' but no pagination parameters (limit, offset, cursor) or total count documented. Large result sets risk context window exhaustion.