@runhooks/mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| RUNHOOKS_API_KEY | No | Your Runhooks API key (rh_live_...). Required for all tools except provision_account. If omitted, you can use the provision_account tool to create an account and obtain a key. | |
| RUNHOOKS_API_URL | No | Runhooks API origin. | https://api.runhooks.app |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| provision_accountA | Create a new anonymous Runhooks account (no email required) and save its API key locally for reuse. Idempotent: if this server already has a key (from RUNHOOKS_API_KEY or a previous provision), it returns the EXISTING account instead of creating a duplicate. Call this at most once — never to recover from an auth error. |
| whoamiA | Show the currently authenticated Runhooks account (name, plan, API key prefix). |
| rotate_keyA | Rotate the API key. The old key stops working immediately; the new key is returned, saved locally, and used for the rest of this session. |
| create_jobB | Create a new scheduled job — an HTTP request fired on a schedule. The schedule.type is one of: "cron" (schedule.expression is a cron string, e.g. "0 9 * * 1,4" for every Monday & Thursday at 09:00 — build/preview expressions at https://runhooks.app/tools/cron-expression-builder; optional IANA schedule.timezone), "interval" (schedule.expression is the number of milliseconds between runs, as a string), or "once" for a single future run (schedule.expression is an ISO-8601 date-time — either an absolute instant like "2026-12-25T14:00:00Z"/with offset, or a naive wall-clock time like "2026-12-25T09:00:00" interpreted in schedule.timezone, defaulting to UTC; the time must be in the future). One-off jobs support the same retries, alerts and logs as recurring jobs. |
| list_jobsC | List your scheduled jobs with optional filters and pagination. |
| get_jobC | Get a single job by its ID. |
| update_jobC | Update an existing job. Only the fields you provide are changed. |
| delete_jobC | Delete a job permanently. |
| pause_jobB | Pause a job — it stops executing until resumed. |
| resume_jobC | Resume a paused job. |
| list_executionsC | List recent executions (run history) for a job. |
| replay_executionB | Re-run a past execution immediately. |
| get_usageA | Show the current plan usage and limits for the account. |
| list_alertsA | List your failure-alert configurations. |
| create_alertB | Create a failure alert. Fires when a job dead-letters. Channel is email, webhook, or slack. |
| get_alertC | Get a single alert configuration by its ID. |
| update_alertB | Update an alert configuration. Only the fields you provide are changed. |
| delete_alertC | Delete an alert configuration. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
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.