A Model Context Protocol server for GitHub Actions integration
Server defines 5 tools with complete input schemas and descriptions. Naming follows verb_noun convention (get_*, trigger_*, enable_*). However, descriptions are generic and lack actionable context for LLM selection. Parameter descriptions are minimal (10-30 chars). Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels (3 WRITE, 2 READ_ONLY). Token parameter exposed in all tools violates secret-injection pattern.
Enable auto-merge for a specific pull request. This will automatically merge the PR when all required checks pass.
Get detailed information about a specific GitHub Action, including inputs and their requirements
Get available GitHub Actions for a repository
Get the latest 2 releases from a GitHub repository
Trigger a GitHub workflow dispatch event with custom inputs
Token parameter exposed in all tool definitions. GitHub tokens are secrets and must never appear as tool parameters, use server-side injection via environment variables (GITHUB_TOKEN, GITHUB_PERSONAL_ACCESS_TOKEN already loaded in config). Remove 'token' from all 5 tool schemas.
No tool annotations despite clear risk levels. trigger_github_action and enable_pull_request_automerge are destructive (WRITE) but lack destructiveHint annotation. get_* tools are read-only but lack readOnlyHint. Annotations guide LLM caution and enable safety policies.
Output schemas not documented. Tool descriptions do not specify what fields are returned or their types. LLMs cannot plan downstream calls or extract required data (e.g., workflow_id from get_github_actions to pass to trigger_github_action).
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 51 | <=2025-11-25 | v2 |
Parameter descriptions are minimal (10-30 chars) and lack actionable context. E.g., 'path' in get_github_action says 'Path to the action.yml or action.yaml file (usually just action.yml)' but does not explain when to use 'action.yml' vs a custom path, or what happens if the file is not found.
No error handling guidance in tool definitions. Descriptions do not explain what errors are possible, when they are retryable, or what the LLM should do next. E.g., trigger_github_action does not mention 'workflow not found' or 'invalid inputs' scenarios.