MCP server to get GitHub Actions Versions
Two tools with basic schemas and descriptions, but significant gaps in parameter documentation and output schema clarity. Both tools share the same schema (GetActionReleaseSchema) but have distinct purposes, creating potential confusion. Parameter 'repository' is marked required in descriptions but appears optional in schema (not in 'required' array). Descriptions are adequate (100-150 chars) but lack actionable context for LLM selection. No output schema documented. Error handling is present but generic.
List all the releases, versions of a GitHub Action
Get the latest release, version of a GitHub Action. Use this tool to get the latest version of a GitHub Action, and keep your workflow files up to date. (using tag_name or sha)
Parameter 'repository' is required by both tools (used in parseRepository call) but not declared in 'required' array of GetActionReleaseSchema. Only 'owner' is marked required. This creates ambiguity, LLMs may omit 'repository' and cause runtime errors.
No output schema documented for either tool. Responses are JSON-stringified release objects, but the structure (fields, types, pagination) is not declared. LLMs cannot plan downstream operations or extract specific fields without guessing.
Parameter descriptions are missing. 'owner' and 'repository' have no descriptions explaining what they represent (GitHub username/org vs repo name). LLMs cannot disambiguate or validate input format.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Both tools share identical schema (GetActionReleaseSchema) but serve different purposes (list all vs get latest). This violates single-responsibility principle and forces LLMs to reason about which tool to call based on description alone, not schema.
Tool descriptions lack context for when to use each. 'List all releases' vs 'Get latest release' is clear, but no guidance on use cases, performance implications, or when one is preferred over the other.