Loading ToolBench
Model Context Protocol server that helps pin GitHub Actions to specific commit hashes and container images to digest hashes
pinner-mcp provides 5 read-only tools for pinning GitHub Actions and container images to immutable references. Tool naming follows verb_noun convention (github_resolve_ref_to_sha, docker_resolve_image_to_digest) and accurately reflects function. All tools have descriptions (avg 130 chars, within 10-1024 baseline). Input parameters are typed and described. However, there are moderate gaps: (1) output schemas are not documented in the source, forcing inference of return structure; (2) parameter descriptions lack formatting constraints (e.g., what constitutes a valid 'ref' string for GitHub?); (3) no error handling documentation, what happens when a digest lookup fails? what should the LLM do?; (4) no pagination support stated for list operations (github_get_versions, docker_get_image_versions likely return multiple items); (5) tool descriptions are task-focused but lack guidance on when to use one tool vs another (e.g., when to call github_get_latest_pinned_version vs github_resolve_ref_to_sha?). Per-tool assessment: all 5 tools score 60-65 individually, averaging to 62 overall.
List the latest versions of a container image for updating base images in Dockerfile
Resolve a container image version to a digest for pinning to immutable images. Use to resolve base images in Dockerfile.
Get the latest pinned version and its tag for a given repository. Used to update pinned GitHub Actions
List the latest versions (releases) for a given repository. Used to check available updates for GitHub Actions
Resolve a Github reference such as a branch or tag to a commit SHA. Returns the ref and SHA for pinning GitHub Actions.
Output schemas are not documented. Source code does not explicitly define or describe the return structure for any tool (e.g., github_resolve_ref_to_sha returns what fields? is 'sha' a string, an object?). LLMs cannot plan downstream calls without knowing what data they'll receive.
Parameter descriptions lack format/constraint details. The 'ref' parameter in github_resolve_ref_to_sha is described as 'The reference to resolve', but does not specify: is it a branch name, tag, or full SHA? What characters are allowed? What is the maximum length? This forces the LLM to guess or try invalid values.
No error handling guidance. Tool descriptions do not explain what happens on failure (e.g., 'ref not found', 'digest lookup timeout', 'rate limit exceeded'). Error responses should guide the LLM toward recovery or alternative actions.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 55 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 42 | - | v1 |
List/pagination support unclear. github_get_versions and docker_get_image_versions likely return multiple items, but neither description mentions pagination, limits, or total counts. How many results are returned? Can results be truncated? This risks context window overflow.
Tool disambiguation absent. No description explains when to call github_get_latest_pinned_version vs github_resolve_ref_to_sha, or how they differ in semantics. LLMs may select the wrong tool or call both unnecessarily.
Parameter descriptions do not include examples or enum constraints. 'version' in docker_resolve_image_to_digest is described as 'The version of the image to resolve', is this a semver (1.0.0), a tag (latest, stable), or a digest? Enums or format hints would prevent hallucination.