ActionD
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| ACTIOND_MCP_ALLOW_LIFECYCLE | No | Set to '1' to allow the AI to start/stop/restart ActionD over MCP |
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
} |
| resources | {
"subscribe": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| actiond_action_getA | Fetch full detail for one CI/CD job by its ID. Returns id, repo, plugin_name, status, live progress line, created/started/ended timestamps, duration_ms, and the commit map (hash, message, author) that triggered the job. Works for running jobs (poll to watch progress) and for terminal jobs (done/failed/cancelled), whose records are kept for post-mortem review — pair with actiond_log to replay the job's log lines or actiond_diagnose for interpreted failure causes. Errors when the ID does not exist. |
| actiond_actions_listA | List the most recent CI/CD jobs executed by ActionD. Each row carries id, repo, plugin_name, status (done/failed/running/pending/cancelled), created_at, and duration_ms, so failures can be spotted at a glance and filtered client-side by status. Optional limit caps the number of rows (default 20). Use this for an overview; use actiond_action_get for one job's full detail, actiond_job_wait to block on a specific job, and actiond_diagnose for root-cause analysis of failures. |
| actiond_cleanupA | Reclaim disk space by deleting terminal CI/CD jobs (done/failed/cancelled) and their artifact directories. Pending and running jobs are never deleted. Default retention is 7 days; pass days=0 or all=true to delete every terminal job. Destructive and irreversible: deleted job records and artifacts cannot be recovered, so confirm intent — especially with all=true — before calling. Returns a summary with deleted_jobs, deleted_dirs, and the retention window applied. |
| actiond_diagnoseA | Diagnose failed CI/CD jobs and turn their logs into actionable fix suggestions. Pass job_id to analyze one job, or omit it to analyze the most recent failures (optional limit caps how many are analyzed, default 5). For each job it extracts the root-cause category (build/test/lint/dependency/permission/timeout/...), error code, severity, confidence, evidence lines, and the files most likely needing changes; the aggregate summary highlights the most common category with concrete next steps. Jobs without error output are reported explicitly as no_error_output instead of being silently dropped. Reach for this first whenever a job fails; use actiond_log for raw logs and actiond_action_get for job metadata. |
| actiond_handoff_packA | Generate a handoff package that lets another agent (or human) resume this work with full context, aggregating git log, ActionD CI/CD verdicts, and — when task_id is given — the task report from the connected task management system. Returns structured JSON plus a ready-to-use Markdown document covering: goal, current state (with evidence level), completed work (recent commits), pending work, known failures, decisions, verification state, and a suggested next action. The markdown field alone is designed to give the receiving agent everything it needs without reading the original session; missing information is marked unknown rather than guessed. Optional path (defaults to the current directory), task_id, project_id, from_agent/to_agent, goal, suggested_next_action, pending_work (comma-separated), and ttl_hours for the validity window (default 24). |
| actiond_job_cancelA | Cancel a pending or running CI/CD job. Validates the job's state first and refuses terminal jobs (done/failed) with an explanatory error, so an accidental double-cancel is safe. On success the job transitions to cancelled and its record is kept for later review via actiond_action_get. Use actiond_job_retry to re-queue a cancelled or failed job. |
| actiond_job_retryA | Re-queue a failed or cancelled CI/CD job for execution. The job runs again as a fresh execution — every retry takes full time and may fail again, so repeated calls create repeated runs (this is not idempotent). Returns the job ID and plugin name; follow up with actiond_job_wait to block until the retry finishes, or actiond_diagnose if it fails the same way. |
| actiond_job_waitA | Block until the given CI/CD job reaches a terminal status (done/failed/error/cancelled), then return the full job detail. Call it right after a push surfaces job IDs — for example, immediately after "lgh up" reports triggered_job_ids. The optional timeout in seconds (default 300) aborts the wait with an error if the job is still unfinished; it never cancels the job itself. Prefer this over polling actiond_action_get; use actiond_job_cancel to abort a stuck job instead. |
| actiond_logA | Read recent ActionD server runtime log entries. Each entry carries timestamp, level (info/warn/error/plugin), and message; plugin execution results and system events appear here. Optional limit caps the number of entries returned (default 20). Read-only; use it to inspect raw output after actiond_actions_list or actiond_action_get surfaces a failure, and prefer actiond_diagnose when you want errors interpreted into root cause and fix steps. |
| actiond_plugin_disableA | Disable a CI/CD plugin for the current project. Once disabled, the plugin no longer triggers even when its event conditions are met — useful for skipping unnecessary checks or shortening CI. The plugin stays registered and can be re-enabled at any time with actiond_plugin_enable; discover exact names with actiond_plugins_list. For broad, preset scope changes prefer actiond_profile_set (fast/full/release). |
| actiond_plugin_enableA | Enable a CI/CD plugin for the current project. Once enabled, the plugin fires on its configured trigger events (git.push/git.tag) on every subsequent push. The plugin must already be registered — discover exact names with actiond_plugins_list, or use actiond_plugins_recommend when you want guidance on what suits the project. To change the whole CI scope at once, switch the execution profile with actiond_profile_set instead of toggling many plugins individually. |
| actiond_plugins_listA | List every CI/CD plugin registered in ActionD, both enabled and disabled. Each entry includes name, trigger events (git.push/git.tag), supported languages, optional repo filter, type (built-in/custom exec), and current enabled state. Read-only; use it to discover valid plugin names before calling actiond_plugin_enable/actiond_plugin_disable, and actiond_plugins_recommend when you want suggestions instead of a raw inventory. |
| actiond_plugins_recommendA | Analyze a project directory and recommend which CI/CD plugins to enable or disable. Detects languages (Go, Python, Java, TypeScript, ...), frameworks (React, Next.js, Spring, ...), project type (frontend/backend/fullstack/monorepo), and features (tests, Docker, existing CI) by scanning config files, then returns per-plugin recommendations with category, reasoning, priority, and confidence, plus aggregate enable/disable suggestions and a workflow proposal. Read-only; apply the suggestions with actiond_plugin_enable / actiond_plugin_disable. Optional path defaults to the current directory. |
| actiond_plugins_reloadA | Hot-reload the ActionD plugin registry without restarting the server. Scans the plugin directories for new or changed manifest.json files and updates the registry in place, so newly added plugins become available immediately. Use it after adding, editing, or removing a plugin manifest, then verify the result with actiond_plugins_list. Returns status, the number of loaded plugins, and the plugin list. |
| actiond_profile_getA | Get the execution profile that controls which CI/CD plugins run on each push. Returns the active profile name plus a description of what it triggers: "fast" runs minimal CI (core lint and test only, 2-3 jobs per push) for quick feedback during development; "full" adds security scan, coverage, and formatting checks (6-10 jobs) for pre-merge verification; "release" adds build, deploy, and release notes (10-15 jobs) for shipping. Read-only; switch profiles with actiond_profile_set and inspect the concrete plugin inventory with actiond_plugins_list. |
| actiond_profile_setA | Switch the execution profile that controls which CI/CD plugins run on each push. Accepts exactly one of: "fast" (minimal CI — core lint and test only, recommended during active development for quick feedback), "full" (complete CI — adds security scan, coverage, and formatting; switch before merging), or "release" (full CI/CD — adds build, deploy, and release notes). The change applies globally and takes effect on the next triggered event. Returns the new profile; verify the current one any time with actiond_profile_get. |
| actiond_run_reportA | Generate a goal run report for a repository: one structured JSON that reconstructs what a run changed and how well it was verified, without writing any new state. Aggregates git log, ActionD CI/CD job verdicts, and — when a task management system report is available — the task's handoff status into sections that answer: what changed (commits), why (declared task intent), did it work (per-job verdicts pass/fail/unknown), how trustworthy the results are (verification depth and verifier provenance), can someone else continue the work, and can it be rolled back (recovery points with evidence levels). Anything not knowable is reported as an explicit "unknown" — never silently converted to pass/fail — and a Limitations list states what the report cannot yet guarantee. Optional path (defaults to the current directory), commit (focus the report on one commit), task_id/project_id (look up the task report), and limit (commits to include, default 10). |
| actiond_server_restartA | Restart the ActionD server daemon (stop, then start again). Requires ACTIOND_MCP_ALLOW_LIFECYCLE=1 in the MCP server environment; the call is refused with a clear error otherwise. By default it protects in-flight work: it refuses and lists the pending/running jobs unless force=true is passed, which restarts even while jobs are executing (those jobs are interrupted). Use it to pick up server-level changes — plugin manifest changes only need actiond_plugins_reload. Returns an action/changed/running/message envelope with combined stop/start output. |
| actiond_server_startA | Start the ActionD server in daemon mode. Refuses with a clear error unless ACTIOND_MCP_ALLOW_LIFECYCLE=1 is set in the MCP server environment (lifecycle control is disabled by default as a safety gate). Starting an already-running server is a no-op that reports the current state. Returns an action/changed/running/message envelope plus daemon output; verify health afterwards with actiond_status. |
| actiond_server_stopA | Stop the ActionD server daemon. Requires ACTIOND_MCP_ALLOW_LIFECYCLE=1 in the MCP server environment; the call is refused with a clear error otherwise. By default it protects in-flight work: it refuses and lists the pending/running jobs unless force=true is passed, which stops the server even while jobs are executing (those jobs are interrupted). Stopping an already-stopped server is a no-op. Returns an action/changed/running/message envelope with the daemon output. |
| actiond_statusA | Check whether the ActionD CI/CD server is reachable and capture its vitals in one call. Returns JSON with running state, version, uptime, registered plugin count, and recent action count. Safe to call at any time with no side effects; use it first when diagnosing connectivity, and prefer actiond_log for execution errors or actiond_actions_list for job history. |
| dev_cycle_runA | Run the end-to-end development loop — commit, trigger CI, wait for results, return a summary — in a single aggregated call. Internally it: (1) commits and pushes the working tree via "lgh up" (requires the LGH daemon running), (2) waits for the ActionD CI/CD jobs triggered by that push, and (3) collects every job result into one structured output. Requires a message (the commit text); optional path (repo directory, defaults to the MCP client's working directory), timeout in seconds (default 300), profile (fast/full/release — switched temporarily for this run and restored afterwards; omit to keep the current profile), and auto_rollback (default false; on failure, resets the repo to the pre-push commit). Use it after editing code to commit, test, and verify in one step; the result reports success, the commit sha, per-job statuses with durations, artifacts, rollback info when applicable, and a human-readable summary. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| ActionD Plugins | List of all CI/CD plugins available in ActionD |
| ActionD Status | Current ActionD server status and statistics |
| Recent Actions | Recent CI/CD actions executed by ActionD |
Latest Blog Posts
- Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)By Om-Shree-0709 on .mcpAgent IdentityOAuth 2.1
- Your AI Chatbot Just Exposed Your CEO's Salary to an InternBy Om-Shree-0709 on .Agent IdentityMCP SecurityOAuth Delegation
- Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)By Om-Shree-0709 on .Agentic AiPrompt InjectionWebAssembly
MCP directory API
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/JoeGlenn1213/ActionD'
If you have feedback or need assistance with the MCP directory API, please join our Discord server