Production-ready MCP (Model Context Protocol) server for Justfile integration
The just-mcp server defines 4 tools with complete input schemas and basic descriptions. All tools have proper naming with action verbs (list_, run_, get_, validate_). Descriptions are present but generic, most fall below the 194-char production baseline. Parameter schemas are well-typed (string, boolean) with descriptions, but lack detail about ranges, formats, and valid values. Output schemas are not documented in the visible code. Error handling is present (errorReporting=true) but recovery guidance is not visible. The tool set is logically composed with minimal overlap. Naming is clear: list_recipes, run_recipe, get_recipe_info, validate_justfile, each is unambiguous and verb-led.
Get detailed information about a specific recipe
List all available recipes in the justfile
Execute a specific recipe with optional arguments
Validate the justfile for syntax and semantic errors
Descriptions are generic and below production baseline (194 chars avg). 'List all available recipes in the justfile' (43 chars) lacks WHEN to use, what structure is returned, and whether pagination is supported.
Output schemas are not documented. No visible return type specifications for any tool. LLMs cannot plan downstream calls or extract needed fields without knowing what list_recipes returns (array? paginated? pagination cursor?).
Parameter descriptions lack actionable constraints. 'Optional JSON string of arguments as array' (run_recipe.args) is ambiguous, what format? Array of what? How are they passed to the recipe? LLMs cannot reliably construct valid args without explicit format guidance.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 63 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 44 | 2024-11-05+ | v1 |
list_recipes lacks pagination support (no limit, offset, or page_size params) and no documented result cap. Large justfiles with hundreds of recipes would dump all into context, diluting signal per mxe:enforce-result-limits baseline.
run_recipe is a destructive/write operation (noted as WRITE risk) but description does not warn 'This modifies state' per pattern:command-tool. LLMs need explicit signal that this is irreversible.
No confirmation or dry-run pattern documented. run_recipe accepts no --dry-run flag or confirm step. Agents can execute destructive recipes without safeguards per pattern:confirmation-request.