MCP Sentinel defines 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (poll, status, attach, read, set_notifier). Descriptions are adequate (80-200 chars) but lack actionable recovery guidance. Parameter descriptions are present but sparse, many lack format/constraint details. Output schemas are undocumented. Error handling is minimal; tools return plain strings but do not guide LLM recovery. No tool annotations (readOnlyHint/destructiveHint). Composition is sound: each tool has one responsibility, and outputs chain (poll returns task ID, status/attach/read consume it). Security: no secrets in params (good), but no audit logging or permission gates visible.

• Document output schemas for all tools. E.g., mcp_sentinel_poll returns {id: string, status: 'running'|'completed'|'failed', result?: unknown, error?: string}. This enables LLM to chain calls and extract IDs.
• Add error classification and recovery hints. E.g., 'Task not found (id=xyz). Possible causes: task expired, invalid ID. Try mcp_sentinel_status list to see active tasks.'
• Add min/max bounds to numeric parameters. E.g., 'interval: milliseconds between polls (minimum 1000, default 5000)' and 'timeout: milliseconds to wait (0 = no timeout, max 3600000 = 1 hour)'.
• Add tool annotations: mark mcp_sentinel_status cancel as destructiveHint=true; mark mcp_sentinel_poll, mcp_sentinel_attach, mcp_sentinel_read as readOnlyHint=true; mark mcp_sentinel_set_notifier_commands as destructiveHint=true.
• Enhance mcp_sentinel_set_notifier_commands description with security warnings: 'Registers shell commands executed on task completion. Commands run with the MCP server's privileges. Validate all input to prevent command injection. Consider sandboxing or allowlisting commands.'

Inferred effective spec: 2025-06-18+.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry