MCP server for Dataform CLI workflows (dev-only).
This server has 9 tools with explicit Zod schemas and descriptions. Naming follows verb_noun patterns (dataform_help, dataform_compile, dataform_run), which is good. However, there are significant gaps: (1) Most tool descriptions are CLI-wrapper focused rather than explaining WHEN to use them or their prerequisites; (2) Parameter descriptions exist but are often minimal (10-40 chars) and lack constraints like min/max for numeric fields; (3) Output schemas are not formally documented, responses return 'content' and 'structuredContent' but the structure of structuredContent is not declared in a schema; (4) Error handling is minimal, no guidance on what to do if commands fail, no categorization of retryable vs fatal errors; (5) The server exposes 'projectDir' as implicit configuration rather than accepting it as a user-friendly parameter. These gaps prevent the server from reaching 70+.
CLI-compatible wrapper for `dataform compile --json [project-dir]`, with parsed summary.
Compile Dataform and return SQL/metadata for matching actions (abstraction over compile JSON).
CLI-compatible wrapper for `dataform run --dry-run [project-dir]`.
CLI-compatible wrapper for `dataform format [project-dir]`.
CLI-compatible wrapper for `dataform help [command]`.
CLI-compatible wrapper for `dataform init-creds [project-dir]` (writes .df-credentials.json).
CLI-compatible wrapper for `dataform install [project-dir]`.
Output schema not formally documented. Tools return {content, structuredContent} but the shape of structuredContent is inferred, not explicitly declared. LLMs cannot reliably parse responses.
Minimal parameter descriptions. Parameters like 'timeout' in dataform_test ('Optional compilation timeout, e.g. `30s`, `2m` (`--timeout`).') are 37 chars, below the 72-char baseline. Descriptions lack actionable context for when to use them.
No error handling guidance. When a Dataform command fails (compile errors, permission denied, missing credentials), tools return stderr without explaining to the LLM what to do next. No categorization of retryable vs fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2025-06-18+ | v2 |
| 2026-03-09 | F | 41 | - | v1 |
CLI-compatible wrapper for `dataform run [project-dir]`.
CLI-compatible wrapper for `dataform test [project-dir]`.
projectDir is hardcoded from server config, not a user parameter. This prevents agents from working with multiple Dataform projects. Consider accepting projectDir as an optional parameter to enable multi-project workflows.
Missing parameter constraints. The 'timeout' parameter in dataform_test accepts a string but lacks a pattern (e.g., /^\d+[smh]$/) or validation guidance. The 'actionRetryLimit' in dataform_run specifies min(0) but no max, allowing unbounded retries.
Tool descriptions lack usage context. E.g., dataform_compile_action says it 'abstracts over compile JSON' but does not explain when an LLM would use it vs dataform_compile. Descriptions should answer: WHAT, WHEN, and any PREREQUISITES.