schema-guard-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
} |
| prompts | {
"listChanged": false
} |
| resources | {
"subscribe": false,
"listChanged": false
} |
| experimental | {} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_tablesC | Tables in the warehouse snapshot. filter: part of a table or schema name. |
| describe_tableB | Columns and types of one table. table: name, schema.name or catalog.schema.name. |
| search_columnsB | Columns whose name (or table name) contains term, e.g. "revenue", "email", "created". |
| check_sqlA | Tables and columns in sql that don't exist in the snapshot, with close matches. Does not run the query. dialect: bigquery, snowflake, databricks, postgres, duckdb ... (default: the snapshot's). |
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
list_tables and search_columns can both surface table-name matches, creating slight overlap, but describe_table and check_sql are clearly distinct. Descriptions help clarify intent, so misselection is unlikely.
All four tools follow a consistent snake_case verb_noun pattern: list_tables, describe_table, search_columns, and check_sql. There are no mixed conventions or vague verb styles.
Four tools is well-scoped for a schema exploration and SQL validation server. Each tool has a clear role, and the set avoids both bloat and thinness.
The set covers the core schema-guard workflow: discovering tables, inspecting columns, searching columns, and validating SQL against the snapshot. No obvious lifecycle gaps exist for the stated purpose.