Lockout-Tagout for agent infrastructure

Server Details

Personal-lock maintenance isolation for agent infrastructure: hasp-quorum refusal + try-start proof.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.

Status: Healthy
Last Tested: 2026-10-23 06:58
Transport: Streamable HTTP · MCP 2025-03-26
URL

TDQS

B3/5.0

Scored 2026-10-23 05:15 across 2 tools

Disambiguation5/5

lock_check and place_lock target clearly different actions (inspect vs. acquire), so an agent can easily distinguish them despite the shared 'lock' domain. No overlap in purpose.

Naming Consistency4/5

Both names use consistent snake_case and concise lowercase style, but the ordering convention deviates: place_lock is verb_noun while lock_check is noun_verb. Minor inconsistency, still readable.

Tool Count3/5

Only 2 tools for a lockout-tagout domain feels thin; a real lifecycle typically needs release/remove and list operations. The count is borderline rather than clearly wrong.

Completeness2/5

The surface supports checking and placing locks but provides no way to release or remove a lock, creating a dead end where operators can acquire locks they can never clear. This is a significant lifecycle gap that will cause agent failures.

Available Tools

2 tools

lock_checkCInspect

Check locks on a component ($0.01/query x402 — send the payment as the X-PAYMENT header on the JSON-RPC POST, same authorization format as REST)

ParametersJSON Schema

Name	Required	Description	Default
`component`	Yes

TDQS

C2.9/5.0

Behavior3/5

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

With no annotations, the description carries the behavioral burden and does disclose important payment/auth behavior: cost, x402 payment, X-PAYMENT header, and JSON-RPC POST format. However, it does not state whether the operation is read-only, what the response contains, or any permission requirements beyond payment.

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 description is a single efficient sentence with no wasted wording. The payment details are included compactly, though the core action could be separated more clearly from the payment mechanics.

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

Completeness2/5

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

For a tool with no annotations, no output schema, and 0% schema description coverage, the description is incomplete. It explains payment mechanics but omits parameter format and return-value behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the undocumented 'component' parameter. It only repeats that locks are checked on a component and gives no identifier format, expected value, or semantic detail.

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?

The description states a specific verb and resource: 'Check locks on a component.' It is clear what the tool does, though it does not explicitly contrast with the sibling place_lock.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus place_lock or other alternatives. Usage is only implied by the verb 'Check locks.'

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

place_lockCInspect

Place a personal lock + try-start proof ($0.05 x402 via the X-PAYMENT header, first placement free once per operator)

ParametersJSON Schema

Name	Required	Description	Default
`scope`	Yes
`shared`	No
`component`	Yes
`adapter_class`	No
`adapter_target`	No
`energy_sources`	Yes
`expected_duration_s`	No

TDQS

C2.7/5.0

Behavior3/5

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

With no annotations, the description carries the full behavioral burden. It usefully discloses cost details ($0.05 x402 via X-PAYMENT, first placement free once per operator), but omits mutation side effects, lock lifecycle, permissions, and error behavior.

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 description is a single front-loaded sentence with no wasted text. The parenthetical is dense but directly adds payment context.

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

Completeness2/5

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

For a 7-parameter tool with no annotations, no output schema, and 0% parameter description coverage, the one-sentence description is far from complete. It explains the core action and payment cost but leaves most invocation-critical semantics undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0% across 7 parameters, and the description does not explain any of them: component, scope, energy_sources, shared, adapter_class, adapter_target, or expected_duration_s. The only related term, 'operator', is not even a parameter.

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?

The description states a specific verb and resource: 'Place a personal lock' plus a 'try-start proof'. The purpose is understandable at a high level, but it does not distinguish this tool from the sibling lock_check or explain what 'try-start proof' means.

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

Usage Guidelines2/5

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

There is no guidance on when to place a lock versus when to use lock_check, nor any stated prerequisites or exclusions. The payment/free-placement note is a condition, not usage guidance.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

2 tool updatesOct 23, 2026
- Changedlock_check1 field changed
  - addedInput schema / required
```
Added value: +[
+  "component"
+]
```
- Changedplace_lock6 fields changed
  - addedInput schema / properties / adapter_class
```
Added value: +{
+  "type": "string"
+}
```
  - addedInput schema / properties / adapter_target
```
Added value: +{
+  "type": "string"
+}
```
  - addedInput schema / properties / energy_sources / items
```
Added value: +{
+  "type": "string"
+}
```
  - addedInput schema / properties / expected_duration_s
```
Added value: +{
+  "type": "number"
+}
```
  - addedInput schema / properties / shared
```
Added value: +{
+  "type": "boolean"
+}
```
  - addedInput schema / required
```
Added value: +[
+  "component",
+  "scope",
+  "energy_sources"
+]
```
2 tool updatesOct 23, 2026
- First observedlock_check
- First observedplace_lock

Related MCP Connectors

Fleet succession: dead-man's switch for agent fleets
com.textforagents
Dead-man's switch for agent fleets: tranche-gated succession on multi-channel absence proof
1
quorum A
io.github.terradev-cloud
Attested multi-agent consensus: proposals, votes, and outcomes stamped and traced.
Agent Orchestration Autonomous Agents
71
PriorSeal A
io.github.imokokok
Bounded authorization and independently verifiable execution evidence for agents.
Security Autonomous Agents Observability
1016
Hive Log A
io.github.srotzin
Tamper-evident audit log service for agent-to-agent transactions
Security Observability
2

Related MCP Servers

DOS Kernel
Agent Orchestration Autonomous Agents Command Line
anthony-chaudhary
A
license
Not graded
quality
A
maintenance
The kernel that doesn't believe the agents — a domain-free trust substrate for fleets of autonomous agents: verify what shipped, arbitrate collisions, refuse with structured reasons.
Updated a month ago (2026-09-27 03:53 UTC)
406 PyPI
20
MIT
Agent Coherence — Stale Writeofficial
File Systems Autonomous Agents
Cohexa-ai
A
license
A
quality
A
maintenance
Coherence guard for shared files: when two agents write the same file, the stale writer is denied instead of silently overwriting, then reacquires and retries. Single-host, TLA+-verified.
Updated 2 days ago (2026-10-21 19:27 UTC)
10
423 PyPI
11
Apache 2.0
agentic-ops
AI & Machine Learning Observability Agent Orchestration
nolll77
A
license
Not graded
quality
A
maintenance
Deterministic Multi-Agent System (MAS) control plane for SRE governance, failure taxonomy diagnosis, and cryptographic WORM trust ledger audit.
Updated 3 days ago (2026-10-20 17:05 UTC)
MIT
cafecitoofficial
Version Control Developer Tools
Cafecitohq
A
license
Not graded
quality
B
maintenance
Enables AI agents to coordinate on a shared repository using commutativity-proven parallel landing and regenerative merge, avoiding rebase conflicts through symbol-level leases.
Updated 22 days ago (2026-09-30 20:31 UTC)
Apache 2.0