@runhooks/mcp
Related Servers
Alternatives to @runhooks/mcp
No user-submitted related servers found.
Related Servers
- AlicenseNot gradedqualityDmaintenanceAn MCP server that lets AI agents manage cron jobs through natural language — adding, listing, pausing, removing, running, and viewing logs of scheduled jobs with plain-English schedule parsing, automatic log capture, missed-run detection, and failure alerts.MIT
- AlicenseNot gradedqualityDmaintenanceAn MCP server for scheduling and executing Claude Code CLI tasks via cron expressions, featuring a web dashboard and webhook support. It enables users to dynamically create custom MCP servers, manage recurring AI jobs, and track execution history with token and cost analytics.24MIT
- AlicenseNot gradedqualityBmaintenanceEnables AI agents to expose and control local and self-hosted tools via MCP, with isolated workers, long-running task management, persisted state, and modular integrations for reverse engineering and development workflows.MIT
- AlicenseAqualityAmaintenanceAn MCP server that surfaces scheduled-job state and detects silent failures (exit 0 but no useful output) for cron, systemd timers, and OpenClaw schedulers, enabling AI agents to query job health and overdue status directly.635 PyPIMIT
- FlicenseNot gradedqualityAmaintenanceEnables AI agents to execute real-world API actions with exactly-once reliability, deduplication, auditing, and human-in-the-loop safeguards via MCP.2-
- FlicenseNot gradedqualityCmaintenanceAn MCP server that enables AI agents to execute real-world actions through 10 specialized engines covering authenticated API calls, browser automation, visual QA, shell commands, file operations, job scraping, and parallel task execution.-
TDQS
Scored across 18 tools
Each tool maps to a distinct resource+action: account lifecycle (provision/whoami/rotate), job CRUD plus pause/resume, execution history vs. replay, and alert CRUD. The only mild adjacency is whoami (identity/plan) vs. get_usage (limits/consumption), but their descriptions make the boundary clear. No tool pair appears to do the same thing.
Nearly everything follows a clean snake_case verb_noun pattern (create_job, list_alerts, replay_execution, rotate_key). The single deviation is 'whoami', a conventional command-style name that breaks the pattern but remains instantly readable.
18 tools across five coherent sub-domains (account, jobs, executions, usage, alerts) is reasonable, and each tool earns its place. It sits at the upper edge of comfortable scope, but the job and alert CRUD sets justify their members rather than padding the surface.
Jobs and alerts have full CRUD plus lifecycle controls (pause/resume), which is strong. Executions, however, only offer list and replay — there is no get_execution or log/output retrieval, so an agent that needs to diagnose why a job failed hits a dead end despite logs being referenced in create_job.