precis-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
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
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| validate_dataA | Validate Precis project data against all constraint rules (10 types: NotNull, Unique, AllowedValues, Range, ForeignKey, Conditional, Scripted, Charset, DateLogic, Composite). Use it to check data quality or to re-validate data after editing constraint configuration; read-only, it modifies no files. Returns the contract JSON: is_valid (overall pass/fail), errors (one entry per violation, with table name, column name, row number, error_code and details), summary (violation counts); full field definitions in docs/contracts/validate-json-v1.md. Preconditions: manifest points to an existing project.precis.yaml inside the server working directory; a path outside the working directory or a missing file returns an isError result. |
| check_configA | Load and inspect a Precis project configuration file without validating data. Use it when validate_data fails, or to diagnose configuration problems first (unsupported version, missing files, dangling references); read-only. Returns: manifest_path, version_ok (whether the manifest version is supported), schemas_loaded/constraints_loaded (counts of schema/constraint files loaded successfully), loading_errors (one entry per load error), warnings. The manifest must be inside the server working directory and must exist, otherwise the call fails. |
| describe_constraintsA | List all 10 constraint types supported by Precis (NotNull/Unique/AllowedValues/Range/ForeignKey/Conditional/Scripted/Charset/DateLogic/Composite) with their refs/params documentation. Use it when writing or editing *.constraint.yaml files, or when unsure which parameters a constraint type accepts; takes no arguments, read-only. Returns a types array whose entries contain: type (constraint type name), refs (documentation of the referenced schema table/column IDs), params (parameter keys, allowed values, defaults). The content is derived from the actions registry as the single source of truth, so it matches the validation engine behavior. |
| infer_schemaA | Infer column types by sampling the head of a data file (CSV/Excel/JSON/JSONL) and generate a draft V2 schema structure. Use it when creating a schema for a new data source or rebuilding an existing schema; read-only, nothing is written to disk - the caller decides whether to save the returned draft. Returns a schema dictionary with V2 fields such as id, name and columns (each column carries its inferred type: string/integer/float/decimal/boolean/date). Note: type inference is based on a sample (1000 rows by default), so extreme values outside the sample may change the actual type; review the draft by hand before verifying it with validate_data. The file path must be inside the server working directory, otherwise the call fails. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
Scored across 4 tools
Each tool has a largely distinct purpose: validate_data checks data, check_config inspects a project's config files, describe_constraints serves as generic reference documentation, and infer_schema produces draft schemas. The main overlap is between validate_data and check_config, since both are used for diagnosing failures, but the descriptions explicitly frame check_config as the follow-up to a validate_data failure, which mitigates most confusion.
All four tools follow a clean verb_noun snake_case convention: validate_data, check_config, describe_constraints, infer_schema. There are no deviations or mixed conventions.
Four tools is a good fit for a focused validation/diagnostics server; each tool serves a clear purpose (validate, diagnose config, reference docs, infer schema). It is on the lighter side, so slightly under-scoped but not thin enough to be a problem.
The read-only validation lifecycle is well covered: validate, diagnose, reference constraint types, and draft schemas. Minor gaps exist, such as no tool to inspect an existing saved schema or enumerate a project's declared constraints, but these are workarounds rather than blockers.