sqlmesh-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| SQLMESH_PROJECT_PATH | Yes | Path to the SQLMesh project directory. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": false
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_modelsA | List every model in the SQLMesh project with its kind, columns, owner, and description. |
| get_modelA | Full detail for one model: rendered query, columns, kind, owner, tags, description. |
| get_model_dependenciesC | Return the direct upstream and downstream model dependencies. |
| fetch_model_dataA | Fetch a bounded, optionally column-filtered preview of model data. |
| server_infoA | Return server, project, safety, and capability metadata. |
| start_planC | Start a plan preview in the background and return a job ID. |
| start_runC | Start a scheduled model run in the background. Requires confirm=true. |
| get_job_statusB | Return the current status and result of an asynchronous plan or run. |
| cancel_jobA | Cancel a queued job. Running SQLMesh operations cannot be interrupted safely. |
| model_impactB | Return all transitive upstream and downstream models affected by a change. |
| environment_healthB | Summarize environment existence, snapshots, and current project drift. |
| audit_historyB | Return recent dataveil audit events without exposing cell values. |
| planA | Preview what a plan against an environment would change. Does not apply anything. Returns a plan_id -- pass it to apply_plan to actually apply this exact plan. |
| apply_planA | Apply a previously-previewed plan. THIS CHANGES REAL DATA in the target warehouse. Requires confirm=true. plan_id must come from a plan() call in this same session -- plans aren't kept across server restarts. |
| lineageB | Column-level lineage: which upstream models/columns does this column depend on. |
| run_auditA | Run audits for a model (or all models if omitted). start/end bound the data checked. |
| run_testA | Run unit tests for a model (or all tests if omitted). |
| diff_environmentA | Diff the current context against a target environment. |
| list_environmentsA | List every environment that exists in this project's state (e.g. prod, dev, ...). |
| table_diffB | Compare two tables or environments and return structured schema/row differences. When comparing environments, pass select_models to choose the models to compare. SQLMesh's console output is suppressed because MCP clients receive the JSON result. |
| formatA | Check or format SQLMesh model and audit files. The default check mode is read-only. Writing formatted files requires confirm=true and is never performed accidentally by an agent. |
| runA | Execute scheduled/due model runs for an environment. THIS CHANGES REAL DATA. Distinct from plan/apply_plan: this runs already-promoted models for their due intervals (what a cron trigger would do), rather than previewing or promoting structural changes. Requires confirm=true. |
| profile_modelA | Aggregate-only profile of a model's columns: null rates, distinct counts, numeric stats, generalized string format signatures (e.g. 'ddd-dd-dddd'). Returns no raw rows or samples; see dataveil's README for its known limits. The model must already be applied (see plan/apply_plan) -- dataveil reads from its current physical snapshot table. |
| propose_cleansing_planA | Everything an agent needs to propose a data-cleansing plan for a model: the aggregate-only profile, a local sensitivity classification per column (PII:EMAIL, PII:SSN, PII:PHONE, ... or "none", each with a match_rate), and the closed operation vocabulary apply_cleansing_plan will accept. This tool does not call an LLM or propose a plan itself -- it's the documented contract an agent (you) reasons over to build one. A plan is a list of {"operation", "column", "params", "rationale"} objects; "operation" must be a key in operation_vocabulary, and only the params listed for it are accepted. Pass the finished plan to apply_cleansing_plan. |
| register_cleansing_planA | Register a cleansing plan for later approval, instead of applying it directly. Only useful when this server requires plan approval (DATAVEIL_REQUIRE_PLAN_APPROVAL=true) -- otherwise apply_cleansing_plan already accepts a plan directly and this tool isn't needed. Validates the plan against the operation vocabulary and the model's schema immediately -- a reviewer should never approve something that would fail at execution time. Read-only: nothing is applied here. Returns a plan_id; pass it to approve_cleansing_plan, then to apply_cleansing_plan. |
| approve_cleansing_planA | Mark a plan registered via register_cleansing_plan as approved. This only records who approved it -- apply_cleansing_plan still requires confirm=true on top of this. Approval and confirm=true are two separate gates, not a substitute for each other. |
| apply_cleansing_planA | Validate and apply a data-cleansing plan. THIS CHANGES REAL DATA in the model's current physical snapshot table. Requires confirm=true. Default mode: pass If this server requires plan approval (DATAVEIL_REQUIRE_PLAN_APPROVAL=
true): pass Note: this writes directly to the model's physical table, outside SQLMesh's own state tracking. A FULL-kind model is fully rematerialized on its next scheduled run/plan apply, which will silently undo the cleansing -- it was never folded into the model's SQL definition. Re-apply after any such rerun if the cleansing still applies. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| explain_model | Explain a model's purpose, inputs, outputs, and lineage. |
| review_plan | Review a SQLMesh plan preview before it is applied. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| models | All SQLMesh model metadata in the configured project. |
TDQS
Scored across 27 tools
Several tools have overlapping intent: plan vs start_plan and run vs start_run are synchronous/async variants of the same operation, while get_model_dependencies, model_impact, and lineage all cover dependency graphs, and plan/diff_environment/table_diff all compare state. The detailed descriptions do explicitly explain the distinctions, so an agent can disambiguate, but the sync/async pairs and parallel comparison tools invite misselection.
All names are snake_case, which is consistent, but verb convention is mixed: verb_noun (get_model, run_audit, apply_plan), reversed noun_verb (table_diff vs diff_environment), and bare nouns (lineage, model_impact, server_info, environment_health) coexist. It remains readable but does not follow a single predictable pattern.
27 tools is above the comfortable range and is inflated by dual synchronous/asynchronous variants (plan/start_plan, run/start_run plus job status/cancel) and conditional tools (register/approve_cleansing_plan only matter when approval is enabled). Still, the SQLMesh domain is genuinely broad (models, plans, runs, jobs, audits, tests, environments, cleansing), so most tools earn their place.
The surface covers the domain thoroughly: model inspection/lineage, plan preview+apply, scheduled runs, job lifecycle, audits/tests, environment diff/health, formatting, and a full cleansing lifecycle. Minor gaps exist (no job listing, no model create/edit since models live as files), but these are workable.