MCP server that closes the feedback loop for AI coding agents — CI results, deployments, test outcomes, file changes
LoopSense has well-structured tool names that follow verb_noun conventions (watch_*, check_*, list_*, cancel_*, poll_*), making intent clear. All 9 tools have descriptions ranging from 62 - 114 characters, which meets the rubric baseline (p10=34, p90=392). However, critical gaps remain: (1) Input schemas are present but lack completeness, many parameters missing descriptions or have overly generic 'optional' text. (2) No output schemas are documented anywhere, forcing LLMs to guess what fields they'll receive. (3) Several tools have parameters with no description guidance (e.g., watch_url's 'expect' object has no guidance on which fields are required or how they interact). (4) Error handling is not visible in the code excerpt, no indication of recovery guidance, retryability classification, or actionable error messages. (5) All tools accept an 'action_id' parameter but this coupling is undocumented, and the 'check_consequences' tool that retrieves linked events has no guidance on when/why to use this pattern. The tools address a real problem (feedback loops for agents), but the definition quality falls short of production confidence.
Stop and remove a watcher
Get events associated with an agent action, or all recent events
List all active watchers
Get new events since a timestamp (push notification fallback)
Watch a GitHub Actions workflow run and emit events on status changes
Watch a file or directory for changes using chokidar
Spawn and monitor a local process, capturing stdout/stderr and exit code
No output schemas documented for any tool. LLMs must guess what fields are returned (e.g., does watch_ci return {status, workflow_id, timestamp}?). This violates pattern:tool-description and forces agents to reason about response structure instead of chaining predictably.
watch_url's 'expect' parameter is an untyped object with no guidance on required vs optional subfields. The inline properties (status, body_contains) lack individual descriptions. Agents cannot determine if both must be present, if they're mutually exclusive, or what happens if neither is set.
watch_webhook's 'filter' parameter is declared as {type: 'object', description: 'Optional filter criteria'} with NO guidance on valid subfields, format, or examples. This is too vague for LLM use, what keys does 'filter' accept?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 55 | 2026-07-28+ | v2 |
Poll an HTTP endpoint and emit events when status or body changes
Start an HTTP server to receive incoming webhooks
'action_id' parameter appears in 5 tools (watch_ci, watch_process, watch_file, watch_url, watch_webhook) with minimal guidance ('Link events to an agent action'). No explanation of how this couples to check_consequences or what happens if action_id is omitted vs provided. The pattern is underdocumented.
No error handling guidance visible. If watch_ci fails to authenticate with GitHub, watch_process cannot spawn a command, or watch_webhook fails to bind a port, what does the LLM learn? No recovery hints, retryability classification, or actionable messages.
poll_events expects 'since' as an ISO 8601 timestamp but no guidance on what happens if 'since' is omitted, is in the future, or is malformed. check_consequences also retrieves events but the distinction between 'get all recent' vs 'filter by action_id' is unclear from the description alone.
No documentation of pagination, rate limits, or result caps. If check_consequences returns all events since the agent was initialized, it could return thousands of records and blow the context window. The description says 'all recent events' but does not define 'recent' or enforce a limit.
watch_process spawns and monitors a local process (IRREVERSIBLE risk). No dry-run or confirmation step. If an agent mistakenly watches 'rm -rf /', the process runs immediately. The description does not warn of the destructive potential or request confirmation.