Local CI/CD engine for AI agents with MCP integration. Listens to Git events and automatically triggers plugin actions like linting, testing, building, and AI-powered documentation generation.
ActionD presents 19 well-named tools with comprehensive descriptions (avg ~250 chars, well above baseline 194). All tool names follow verb_noun pattern (actiond_status, actiond_plugins_list, etc.). Descriptions are LLM-optimized with WHAT/WHEN/HOW guidance. However, critical gaps exist: input schemas are visible but lack explicit type definitions and constraints in the source code, JSON Schema structure is inferred from the provided schema objects but not explicitly validated in the actual codebase. Parameter descriptions are present but often generic (e.g., 'Plugin name to enable' for actiond_plugin_enable lacks enum values or format constraints). Output schemas are not documented in code, tool descriptions mention return structure but no formal schema is visible. Error handling is mentioned in descriptions ('Errors when the ID does not exist') but no recovery guidance is provided. Security: no mention of secret injection, permission gates, or audit logging in visible source. Composition is strong, tools are single-purpose and chainable (e.g., actiond_plugins_list → actiond_plugin_enable). Most tools include helpful cross-references in descriptions (e.g., 'Pair with actiond_plugins_list to discover valid names'). This is a solid B- server: good naming and descriptions, but lacks schema rigor, formal output documentation, and error recovery patterns.
Cancel a running CI/CD job by its ID. Only works for jobs with status 'running' or 'pending'; terminal jobs (done/failed/cancelled) cannot be cancelled. The job's log and artifacts are retained for post-mortem review.
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.
Retry a failed or cancelled CI/CD job. Creates a new job with the same repo, plugin, and commit; the new job ID is returned in the response. Only failed and cancelled jobs can be retried; other statuses are rejected.
Block until a specific CI/CD job reaches a terminal status (done/failed/cancelled) or the timeout expires. Polling job detail via actiond_action_get on your own is allowed but not recommended; actiond_job_wait is more efficient and returns as soon as the job completes.
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.
Input schemas lack explicit type and constraint declarations in code. While schema objects are provided (e.g., {'type': 'integer', 'description': '...'} for limit params), there are no enum values, min/max bounds, or pattern restrictions visible. E.g., 'limit' param in actiond_actions_list and actiond_log has no minimum (should be ≥1) or maximum to prevent abuse.
Output schemas are not formally documented in code. Tool descriptions mention return structure (e.g., 'Returns JSON with running state, version, uptime...' in actiond_status), but no explicit JSON Schema is visible for what clients should expect. LLMs cannot plan downstream calls without knowing output field names and types.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 69 | 2026-07-28+ | v2 |
Reclaim disk space by deleting terminal CI/CD jobs (done/failed/cancelled) and their artifact directories. Pending and running jobs are protected.
Interpret a failed CI/CD job using a natural-language AI model. Analyzes the job's log output to identify root causes (e.g., missing dependencies, syntax errors, lint violations). Returns a structured diagnosis with severity, category, and suggested remediation.
Prepare a CI/CD job for human review or external escalation. Generates a summary document with job metadata, logs, and artifacts ready for handoff to another system (e.g., Slack, email, ticketing system).
Fetch recent log lines from the ActionD server. Each entry carries a timestamp, log level (info/warn/error), and message. Optional limit caps the number of lines (default 50). Use this to diagnose server issues, plugin errors, or failed CI/CD jobs.
Disable a specific plugin by name, so it will NOT trigger on matching Git events (but remains registered). Idempotent: disabling an already-disabled plugin is a no-op. Pair with actiond_plugins_list to discover valid names.
Enable a specific plugin by name, so it will trigger on matching Git events. Idempotent: enabling an already-enabled plugin is a no-op. Pair with actiond_plugins_list to discover valid names, and actiond_plugins_recommend for suggestions.
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.
Get AI-powered plugin recommendations based on a given repo name and optional filter. Returns a sorted list of plugins with match scores so you can choose which ones to enable.
Fetch the current execution profile (e.g., 'quick'/'thorough'/'custom') for CI/CD job verdict assignment. The profile name is used by plugins to control output filtering and interpretation.
Change the execution profile (e.g., 'quick'/'thorough'/'custom') for CI/CD job verdict assignment. The profile persists across server restarts and is used by plugins to control output filtering and interpretation.
Generate a structured report of recent CI/CD job runs. Summarizes pass/fail rates, average duration, plugin performance, and error frequencies over a given time window. Useful for workflow tuning and debugging bottlenecks.
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 job 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.
Trigger a multi-step CI/CD workflow on a given repository. Workflows are sequences of plugins that run in order, passing outputs from one stage to the next. Returns the workflow execution ID for status polling.
List all known CI/CD workflows registered in ActionD. Each entry includes name, description, plugin sequence, and trigger events.
Error handling lacks recovery guidance. Descriptions state when errors occur (e.g., 'Errors when the ID does not exist' in actiond_action_get) but do not guide the LLM what to do next (e.g., 'Try actiond_actions_list to find valid job IDs'). This violates the recovery-guide pattern.
Destructive/sensitive tools lack confirmation patterns. actiond_cleanup and actiond_action_cancel (reversible but not recommended) have no mention of dry-run, preview, or confirmation steps. actiond_handoff is marked WRITE but has no security context about what 'destination' means or permission requirements.
Parameter 'destination' in actiond_handoff accepts free-form strings ('slack', 'email', 'ticket') with no enum constraint. LLMs will hallucinate invalid values. Should declare: enum ['slack', 'email', 'ticket', 'console'].
No security annotations visible. No mention of permission gates, scope declarations, audit logging, or secret injection patterns. Agents calling actiond_cleanup or actiond_handoff have no visibility into what permissions are required or what data is being logged.
Pagination not explicitly documented for list tools. actiond_actions_list, actiond_plugins_list, actiond_workflow_list accept 'limit' but no 'offset', 'page', or 'next_cursor'. Descriptions do not state total count or whether results are truncated.
Parameter 'profile' in actiond_profile_set is free-form string with no enum. Description mentions 'e.g., quick/thorough/custom' but does not declare valid values. LLMs will guess invalid profiles.
Parameter 'filter' in actiond_plugins_recommend lacks format specification. Description says 'e.g., go-*, *-test' suggesting glob pattern, but does not state regex/glob syntax or validation rules.