Loading ToolBench
MCP server for LidGuard, a system that manages laptop lid state and prevents unwanted sleep/suspend during autonomous work sessions. Provides tools for session management, settings control, and runtime status monitoring.
LidGuard provides 7 tools with explicit schemas and descriptions. Tool naming follows verb_noun convention (provider_start_session, get_settings_status, list_sessions, update_settings). Descriptions are detailed and context-rich (100-300+ chars), explaining WHAT, WHEN, and WHY. Input schemas are present with type definitions and parameter descriptions. However, output schemas are inferred from response model classes rather than explicitly documented in tool definitions. Error handling guidance is minimal, tools lack recovery hints or categorization (retryable vs fatal). Session management tools (provider_start_session, provider_stop_session, provider_set_soft_lock, provider_clear_soft_lock) form a coherent chain but lack explicit documentation of state transitions and prerequisites. The update_settings tool has 20+ parameters with good individual descriptions but no guidance on mutual exclusivity or side effects. No tool declares permissions or security scopes.
Read the stored LidGuard settings file and, when available, the active LidGuard runtime settings, lid state, and session list.
List the active LidGuard sessions and runtime lid/session state without returning the full settings payload.
Call this when a previously soft-locked Provider MCP session can resume autonomous work, typically right after the user has replied and immediately before you continue work. Pass the exact same session identifier that provider_start_session returned earlier. When you are resuming an existing soft-locked session, prefer this tool instead of starting a brand-new session.
Call this immediately before you end a turn because you need the user's next input and want LidGuard to allow suspend. Pass the exact session identifier previously returned by provider_start_session. A soft-locked session stays tracked, but it stops keeping the machine awake. This tool cannot force the turn to end; after calling it, you must actually end or hand back the conversation yourself and stop autonomous work in that turn.
Call this once when you are starting a brand-new LidGuard Provider MCP session before autonomous work begins. Do not invent or supply a session identifier here. LidGuard generates an 8-character lowercase hexadecimal session identifier from the first block of a new GUID, starts tracking it, and returns that exact value in both requestedSessionIdentifier and sessionIdentifierToReuse. Save that returned identifier and reuse it verbatim with provider_set_soft_lock, provider_clear_soft_lock, and provider_stop_session until the work is truly complete. If you are resuming after a previous soft lock, do not call this again; call provider_clear_soft_lock with the earlier returned session id instead.
Output schemas are not explicitly documented in tool definitions. Response models exist (LidGuardSessionCommandToolResponse, LidGuardSettingsStatusToolResponse, etc.) but are not referenced in tool registration. LLMs cannot see what fields to expect without inspecting response classes.
No error handling guidance. Tools lack descriptions of failure modes, recovery steps, or error categorization (retryable vs user-fixable vs fatal). E.g., provider_start_session could fail if LidGuard runtime is unavailable, but no guidance on what to do.
Inferred effective spec: 2025-06-18+.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 62 | 2025-06-18+ | v2 |
Call this only when the work is truly complete and this ongoing Provider MCP session no longer needs LidGuard protection. Pass the exact session identifier that provider_start_session previously returned. Do not generate a new identifier for stop. If you are ending the turn because you need the user's next input, use provider_set_soft_lock instead.
Update one or more LidGuard settings in a single call, save them to the LidGuard settings file, and try to sync a running runtime without starting one.
update_settings has 20+ optional parameters with no guidance on mutual exclusivity, side effects, or ordering. E.g., resetToDefaults + individual changes could conflict. No documentation of which combinations are safe.
No permission or scope declarations. Tools like update_settings and provider_stop_session are destructive but do not declare required permissions (e.g., 'admin:lidguard', 'write:settings'). Agents cannot be configured with least-privilege access.
Session state machine not documented. Tools form a chain (start → set_soft_lock → clear_soft_lock → stop) but descriptions do not explicitly state valid state transitions, prerequisites, or what happens if tools are called out of order.