What can you do with this server?

The sql-steward server is a governed, read-only SQL gateway for AI agents that compiles queries from a semantic layer — the agent never writes SQL or accesses raw database connections. It enforces PII policies, refuses blocked fields before any query runs, and maintains a tamper-evident audit trail. Discovery & Exploration * list_entities() — List all accessible tables/entities and available metrics (recommended starting point). * describe_entity(entity) — Inspect an entity's fields, data types, and PII tags; blocked fields are flagged. * list_metrics() — View all pre-approved aggregate metrics with their allowed dimensions and filters. Data Retrieval * get_records(entity, fields, filters, order_by, limit) — Read rows from an entity using structured filters (=, !=, <, like, in, is null, etc.). PII-blocked fields and undefined joins are refused at compile time. * get_metric(metric, dimensions, filters, limit) — Compute a pre-approved aggregate metric, optionally grouped by allowed dimensions or filtered. Aggregation logic is fixed by the semantic layer. * semantic_search(entity, query, k, filters) — Perform pgvector-based nearest-neighbour similarity search over an entity's embedding column (PostgreSQL only). Subject to the same PII restrictions as other tools. Data Quality & Auditing * list_checks() — List declared data-quality checks defined in the semantic layer. * run_checks() — Execute all data-quality checks and receive a readiness summary (pass %, overall status: passing/degraded/failing, and a per-check breakdown). * audit_verify() — Verify the tamper-evident, hash-chained audit log to confirm no previously recorded call was altered. Key guarantees: read-only by construction, PII refused before retrieval, and every call/refusal/error is auditable.

Which integrations are available for this server?

Enables semantic search over entity embeddings by generating embeddings locally via Ollama, with full governance (PII refusal, audit) and no external API calls. Provides read-only, governed access to PostgreSQL databases through a semantic layer with PII protection, role-based access control, and audit logging. Provides read-only, governed access to SQLite databases through a semantic layer with PII protection and audit logging, suitable for local or embedded databases.

How do I use sql-steward?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sql-steward get metric mrr_total by plan" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

sql-steward

Q: Which integrations are available for this server?

Enables semantic search over entity embeddings by generating embeddings locally via Ollama, with full governance (PII refusal, audit) and no external API calls. Provides read-only, governed access to PostgreSQL databases through a semantic layer with PII protection, role-based access control, and audit logging. Provides read-only, governed access to SQLite databases through a semantic layer with PII protection and audit logging, suitable for local or embedded databases.

Q: How do I use sql-steward?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@sql-steward get metric mrr_total by plan" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

by govern-agents

Overview Schema Related Servers Score Discussions

Python

Remote

IMPORTANT

This repository has moved into the Governed Agent Stack monorepo.

Active development is now at packages/sql-steward/. This repo is archived and read-only. Its full commit history is preserved here; new work, issues and releases happen in the monorepo.

sql-steward

PyPI Downloads

License Python Discord

Part of the Governed Agent Stack: free, on-prem building blocks for an AI agent you can point at a real database and audit.

A governed SQL gateway for AI agents, exposed over the Model Context Protocol. The agent never gets a connection string and never writes SQL. It calls typed tools; sql-steward compiles every query from a semantic layer you control, refuses blocked PII before the query runs, and returns rows. Same tools across SQL Server, Postgres and SQLite.

Most SQL MCP servers hand the model a run_sql tool and try to catch the bad queries on the way out. sql-steward removes the tool. There is no path from a prompt to raw SQL at your database, because the only thing the agent can do is name an entity or a metric and pick from allow-lists you wrote.

See it defend a database live. The governed vs ungoverned demo runs the same request through a naive run_sql agent, which leaks customer PII and empties a table, and through sql-steward, which refuses it at compile time.

Three guarantees

Read-only by construction. There is no run_sql, query, or execute tool. The compiler can only ever build a SELECT, so a write isn't blocked, it's unrepresentable.
PII refused before retrieval. Every field can carry a PII tag. If a request touches a category your policy blocks, sql-steward refuses with a structured reason before any SQL is compiled or run.
Auditable. Every call, refusal and error can be recorded in a tamper-evident, hash-chained log via agent-blackbox, with audit-verify to prove nothing was rewritten.

Related MCP server: sqlserver-semantic-mcp

See it in 10 seconds

pip install sql-steward      # or: pipx install sql-steward
sql-steward demo            # zero config, no API key, no agent, SQLite

1) get_metric('mrr_total', dimensions=['plan'])  -> safe aggregate
   compiled: SELECT subscriptions.plan, SUM(subscriptions.mrr) AS mrr_total
             FROM subscriptions GROUP BY subscriptions.plan LIMIT 1000
   {'plan': 'pro', 'mrr_total': 297.0}
   {'plan': 'team', 'mrr_total': 598.0}

2) get_metric('mrr_total', dimensions=['customers.country'])  -> auto-join
   compiled: ... INNER JOIN customers ON subscriptions.customer_id = customers.id ...

3) get_records('customers', fields=['id','email'])  -> PII refusal
   refused: {"kind": "pii_blocked", "detail": "Field 'customers.email' is tagged
             EMAIL_ADDRESS, which this policy refuses."}

The semantic layer

This YAML is the entire contract between the agent and your database. Review it like code.

dialect: postgres

entities:
  customers:
    table: customers
    fields:
      id: {type: int}
      name: {type: text, pii: PERSON}
      email: {type: text, pii: EMAIL_ADDRESS}
      country: {type: text}
  subscriptions:
    table: subscriptions
    fields:
      customer_id: {type: int}
      plan: {type: text}
      mrr: {type: numeric}

joins:                              # nothing reachable that isn't listed here
  - left: subscriptions
    right: customers
    on: subscriptions.customer_id = customers.id

metrics:
  mrr_total:                        # the aggregation is fixed; the agent only
    entity: subscriptions           # chooses dimensions/filters from the lists
    aggregate: sum
    field: mrr
    dimensions_allowed: [plan, status, customers.country]
    filters_allowed: [status, customers.country]

policy:
  block_pii: [EMAIL_ADDRESS, CREDIT_CARD]
  max_rows: 1000

Ask for a join that isn't defined and you get unreachable_entity, not an invented relationship. Ask to group a metric by a dimension that isn't listed and you get dimension_not_allowed. Misspell a metric or field and the error lists what does exist, with the closest spellings, so an agent corrects itself in one turn instead of making a second discovery call.

Tools exposed to the agent

Tool	Purpose
`list_entities()`	What can be read, plus the available metrics
`describe_entity(entity)`	Fields, types and PII tags (blocked ones flagged)
`list_metrics()`	Metrics and the dimensions/filters each allows
`get_records(entity, fields, filters, order_by, limit)`	Read rows from one entity
`get_metric(metric, dimensions, filters, limit)`	Compute a pre-approved aggregate
`semantic_search(entity, query, k, filters)`	pgvector nearest-neighbour search over an entity's embedding column
`audit_verify()`	Verify the tamper-evident audit chain

Filters are {field, op, value}; operators are =, !=, <, <=, >, >=, like, in, not in, is null, is not null. Values are always bound parameters, never inlined.

Wire it into an MCP client

The semantic layer YAML lives wherever you point SQL_STEWARD_LAYER. Claude Desktop (claude_desktop_config.json):

{
  "mcpServers": {
    "sql-steward": {
      "command": "sql-steward",
      "env": {
        "SQL_STEWARD_LAYER": "/full/path/to/semantic.yaml",
        "SQL_STEWARD_DB_URL": "postgresql+psycopg://readonly@db.internal/warehouse"
      }
    }
  }
}

SQL_STEWARD_DB_URL is a SQLAlchemy URL, so the same server reads SQL Server (mssql+pyodbc://...), Postgres (postgresql+psycopg://...) or SQLite (sqlite:///path.db). Install the matching driver with the extras: pip install "sql-steward[postgres]" or "[mssql]".

Optional: the rest of the stack

The semantic layer is the primary control. These are extra layers, all opt-in, and no-ops if the library isn't installed:

pip install "sql-steward[rbac,mask,audit]"

export SQL_STEWARD_POLICY=/path/to/policy.yaml   # query-warden second-pass role check
export SQL_STEWARD_ROLE=analyst
export SQL_STEWARD_MASK=1                         # pii-veil masks anything left in results
export SQL_STEWARD_AUDIT_DB=logs/steward.db       # agent-blackbox audit chain (on if installed)
export SQL_STEWARD_QUERY_BUDGET=200               # persistent per-role query cap (SQLite-backed)
export SQL_STEWARD_BUDGET_WINDOW=3600             # optional: make the cap a sliding window, in seconds
export SQL_STEWARD_EMBED_URL=http://localhost:11434/api/embeddings  # local embeddings for semantic_search
export SQL_STEWARD_EMBED_MODEL=nomic-embed-text

Semantic search (pgvector)

Give an entity a search block pointing at a pgvector column and the agent gets a semantic_search tool, governed exactly like everything else (PII refused, results masked, calls audited):

entities:
  documents:
    table: documents
    fields:
      id: {type: int}
      title: {type: text}
      embedding: {type: vector}
    search:
      vector_column: embedding
      dim: 768
      returns: [id, title]

The query text is embedded locally (set SQL_STEWARD_EMBED_URL to a local Ollama endpoint, so nothing leaves the building), and matched with pgvector's <=> operator. PostgreSQL only. The embedding column is never returned.

query-warden re-checks the compiled SQL against a role policy.
pii-veil masks any PII that survives into result rows.
agent-blackbox records every call in a hash-chained ledger; sql-steward audit-verify checks it.

Security model

sql-steward governs the path from the model to your database. It assumes the process that calls its tools is trusted. That boundary is the difference between deploying it safely and exposing it, so it is worth stating plainly.

What it enforces, whatever the model asks. Every call runs the same gate: read-only by construction, blocked PII refused before retrieval, an optional role check via query-warden, results masked by pii-veil, and a hash-chained audit of the call. A jailbroken model still cannot write, cannot read a blocked column, and cannot reach an entity the layer does not define. These hold by construction, not by trusting the model to behave.

What it does not do. sql-steward is an enforcement plane, not a front door.

It does not authenticate the caller. SQL_STEWARD_ROLE is configuration, not a verified identity; sql-steward trusts that the role it is handed is the correct one.
It does not resolve per-user permissions. If different users should see different data, the caller maps the user to a role and sets it before invoking. The role check enforces a policy, it does not decide who you are.
It does not secure transport. Run it over stdio to a local host, or place it behind something that terminates TLS.
It does not manage secrets. SQL_STEWARD_DB_URL and the audit key AGENT_BLACKBOX_KEY are read from the environment; supply them from a secret store, not a checked-in file.

What you provide. sql-steward is built to sit behind a trusted caller, whether that is an MCP host on the same machine or a gateway that has already authenticated the user.

Invoke it from a trusted process: a subprocess of an MCP host you control (stdio), or a service behind a gateway that authenticates the request and maps the verified identity to a role before the call.
Give it a least-privilege, read-only database account. Writes are unrepresentable in the compiler, but a read-only grant is defense in depth and the right blast radius if a dependency is ever wrong.
Keep the database and any local embedding endpoint on a private network. Do not expose the server to untrusted callers.
Treat the connection string and the audit key as secrets.

The threat it is built for. The design assumes a capable, possibly compromised model and a trusted operator. It bounds what the agent can do with your database. It does not replace your identity provider and is not meant to face an untrusted network alone. Point it at a real database from behind a host or gateway you trust, and the three guarantees are what the model is left with.

How this is different

A typical SQL MCP validates arbitrary SQL the model wrote (a blocklist: catch what's bad). sql-steward compiles SQL from definitions you wrote (an allow-list: only what's described exists). The read-only and PII guarantees hold by construction rather than by inspection, and the query surface is the same across three engines.

Versus a semantic layer (Cube, dbt Semantic Layer, Cortex Analyst, Genie)

The nearest tools are not other MCP servers, they are semantic layers. Cube and the dbt Semantic Layer already expose compiled, metric-only access, and Snowflake Cortex Analyst and Databricks Genie both answer natural-language questions over a governed model. If you run on their platform, use them. This project exists for the case they do not cover:

On-prem and air-gappable. sql-steward is a pip install that talks to SQL Server, Postgres or SQLite with no account, no warehouse, and no data leaving the building. Cortex Analyst is Snowflake, Genie is Databricks, and Cube's cloud features assume their service. For a factory or a hospital that cannot send data to a vendor, that difference is the whole decision.
PII refused before retrieval, at the same chokepoint. A blocked field is refused at compile time for every caller, so the model cannot read what policy forbids even to reason over. Semantic layers govern which metrics you can query; they are not built to guarantee a tagged column never reaches the model.
One tamper-evident audit for the whole agent, not just SQL. The same gate pattern wraps KQL, document retrieval and agent memory in the composed stack, under one hash-chained ledger. A warehouse semantic layer governs the warehouse; it does not govern the agent's other tools.

Short version: a semantic layer makes queries safe on its platform. sql-steward makes an agent safe on your infrastructure, across every surface it can reach.

That difference does not mean living on an island. The industry is converging on Apache Ossie (the Open Semantic Interchange format, incubating at the ASF, started by the Snowflake, dbt and Salesforce working group) as the neutral way to move semantic models between tools, and sql-steward speaks it:

sql-steward export semantic.yaml --out model.osi.yaml

Entities, joins and metrics map to OSI datasets, relationships and metrics. OSI has no governance vocabulary yet, so the parts that make the layer a contract rather than a catalog, the PII tags, the policy block, metric allow-lists and checks, travel in custom_extensions under vendor_name: SQL_STEWARD; anything that cannot be represented is reported as a note on stderr instead of dropped silently. The output passes Ossie's own validator, so a layer written for sql-steward can be handed to anything that reads the standard.

Scaling to a real schema

The semantic layer is authored by hand on purpose, so it reads and reviews like code. That is the right default for tens of tables and the wrong one for thousands: nobody hand-writes a layer for a 10,000-table ERP, and returning the whole layer in one list_entities call would not fit an agent's context anyway. How that scales:

Bootstrap, then review. sql-steward init --from-db <url> reflects a live schema, maps column types, proposes PII tags from column-name heuristics (biased toward over-tagging, so a leak is a review edit rather than a default), and infers joins from foreign keys. It emits a draft layer that loads and validates as-is, with a header that tells you what to narrow. The point is not to auto-expose everything; it is to remove the blank-page problem so a large schema starts as a reviewable file, not a hand-typed one.
```
sql-steward init --from-db "postgresql+psycopg://readonly@db/warehouse" --out semantic.yaml
# then delete entities you do not need, check the PII tags, add metrics
```
Scope beats size. A governed layer should expose the handful of entities an agent actually needs, not the whole database. A 10,000-table schema still becomes a 20-entity contract; the discipline is deciding what belongs (use --include/--exclude to draft only a slice), which is a feature of the model, not a limit of the tool.
Discovery grows with the layer. list_entities/describe_entity are browsed as the layer grows; search and paging on those responses is the next edge to close before this points at a very large single layer.

Develop

git clone https://github.com/Pawansingh3889/sql-steward
cd sql-steward
pip install -e ".[dev]"
pytest -q

License

MIT

Available Tools

4 tools

audit_verifyA

Verify the tamper-evident audit chain (agent-blackbox), if enabled.

Reports whether any previously recorded call was altered after the fact.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It discloses the tool reports on call alterations and mentions the 'if enabled' condition, but lacks details on prerequisites (e.g., permissions), side effects, or whether it is read-only/destructive. This is adequate but not rich.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the primary purpose, and contains no redundant or unnecessary words. Every sentence adds value.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple tool with no parameters and an output schema present, the description adequately explains the tool's action and result. It mentions the 'if enabled' precondition, which is important context. Could be slightly improved by noting what happens when audit is disabled, but not essential.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The tool has zero parameters and schema coverage is 100% (trivial). The description adds no parameter information because none exist, which is appropriate. Baseline for 0 parameters is 4.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool's purpose: verifying the tamper-evident audit chain and reporting alterations. It uses specific verbs ('verify', 'reports') and identifies the resource ('audit chain'). It is distinct from sibling tools, which involve describing entities, getting metrics, or running checks.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage when audit is enabled but does not explicitly state when to use this tool versus alternatives. No exclusions or comparisons to siblings are provided, leaving the agent to infer context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_metricA

Compute a pre-approved metric, optionally grouped/filtered by allowed dimensions. The aggregation itself is fixed by the semantic layer.

ParametersJSON Schema

Name	Required	Description	Default
`limit`	No
`metric`	Yes
`filters`	No
`dimensions`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations provided, the description carries full responsibility. It mentions 'pre-approved' (suggesting authorization) and 'fixed aggregation' (implying immutability), but does not explicitly state that the operation is read-only, nor does it detail potential side effects or permissions. The behavior is somewhat transparent but not fully.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two concise sentences front-load the core action ('Compute a pre-approved metric') and then add constraints. Every word adds value; no fluff.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool has 4 parameters, no annotations, but an output schema exists, the description is too brief. It lacks details on parameter formats, output expectations, and prerequisites. It does not fully equip an agent to use the tool correctly without additional knowledge.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0% (no parameter descriptions in schema), so the description must compensate. It mentions 'grouped/filtered by allowed dimensions', which loosely maps to dimensions and filters, but does not explain the 'metric' (required), 'limit' (ignored), or specifics of filters format. This is insufficient for a tool with 4 parameters.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'compute' for a metric resource, and specifies optional grouping/filtering. It distinguishes itself from sibling tool 'list_metrics' (which just lists available metrics) by emphasizing computation with a fixed aggregation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when to use the tool (to compute a pre-approved metric) and hints at constraints like 'allowed dimensions', but does not explicitly state when not to use it or provide alternative tool names. The context of sibling tools partially fills this gap.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_checksA

List the declared data-quality checks the layer can run.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A3.6/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided; description implies a read operation but does not disclose side effects, permissions, or any behavioral traits beyond listing.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with verb front-loaded, no wasted words. Very concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple list tool with no parameters and an output schema, the description is adequate. However, could briefly mention relationship to 'run_checks' for completeness.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist; baseline is 4 as per guidelines. Description adds no parameter info but none is needed.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description states verb 'List', resource 'declared data-quality checks', and scope 'the layer can run'. Clearly distinguishes from siblings like 'run_checks'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives such as 'run_checks' or other list tools. Lacks context for decision-making.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

run_checksA

Run the declared data-quality checks and return a readiness summary.

Each check compiles to a read-only violation count; zero violations passes. Returns a readiness score (percent of checks passing), an overall status, and a per-check breakdown. An 'error'-severity failure makes the status 'failing'; a 'warn'-severity failure makes it 'degraded'.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
No output parameters

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The description discloses that each check is read-only ('read-only violation count'), the return structure (readiness score, overall status, per-check breakdown), and the severity mapping for status ('error' -> failing, 'warn' -> degraded). Since there are no annotations, the description fully bears the transparency burden and does so well.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is concise (three sentences) and front-loaded with the main purpose. Every sentence adds value: main action, read-only guarantee, return structure, and status logic. No redundant or vague phrasing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given no parameters and an output schema present, the description thoroughly explains what the tool does and what it returns. It covers the key behavioral aspects (read-only, severity, output format) without relying on the output schema. It is complete for this tool's complexity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has zero parameters, so schema coverage is 100%. Per guidelines, zero parameters merits a baseline of 4. The description does not need to add parameter information, and it doesn't.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states that the tool runs data-quality checks and returns a readiness summary. It specifies the verb 'Run' and the resource 'declared data-quality checks', which distinguishes it from sibling tools like 'list_checks' (which lists checks) and 'audit_verify' (likely a different type of check).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description does not explicitly state when to use this tool versus alternatives. While the purpose is clear, it lacks direct guidance on prerequisites, when to prefer it, or when to avoid it. It is adequate but not proactive in helping the agent choose among siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

5 tool updatesv0.4.0Jul 25, 2026
- Removeddescribe_entity
- Removedget_records
- Removedlist_entities
- Removedlist_metrics
- Removedsemantic_search
9 tool updatesv0.3.3Jul 9, 2026
- First observedaudit_verify
- First observeddescribe_entity
- First observedget_metric
- First observedget_records
- First observedlist_checks
- First observedlist_entities
- First observedlist_metrics
- First observedrun_checks
- First observedsemantic_search

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.9/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: audit trail, entity schema, computed metrics, raw data access, checks metadata, entity listing, metric listing, check execution, and vector search. There is no overlap in functionality.

Naming Consistency4/5

Most tools follow a verb_noun pattern (list_entities, get_records, run_checks, etc.). 'audit_verify' is a compound verb, and 'semantic_search' lacks a verb prefix, but overall the naming is predictable and clear.

Tool Count5/5

With 9 tools, the server covers core data access, metrics, quality checks, audit, and search without being too heavy or sparse. The count is well-scoped for its domain.

Completeness4/5

The tool surface provides a solid read-only interface for querying, metrics, checks, and search. Minor gaps exist (e.g., no individual check detail, no metric detail), but agents can work around these using list tools.

Maintenance

ActivitySlowing

ResponsivenessSyncing

Resources

GitHub Repository

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

QueryBearOAuth
io.github.spencerpauly
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Databases RAG Systems
2
agentlock
io.github.Olum289
Security gateway for AI agents: policy, approval, and audited execution, no secrets shared.
Security Agent Orchestration
2
Veto — SQL Safety & Cost Oracle A
com.vetosql
Deterministic safety, correctness & cost gate that vets Postgres SQL before your AI agent runs it.
Databases Security Autonomous Agents
32
mcpOAuth
ai.matih
The grounded data layer for any LLM: governed SQL, metrics, lineage and catalog over your data.
Data Platforms Databases
2

Related MCP Servers

RunContext
Databases Search Developer Tools
Quiet-Victory-Labs
A
license
Not graded
quality
C
maintenance
Enables AI agents to understand and query your database safely by providing a semantic layer of metadata, with tools to search, explain, validate, and generate safe SQL.
Updated 3 months ago (2026-05-30 23:16 UTC)
2
MIT
sqlserver-semantic-mcp
Databases Developer Tools
LukeStackLab
A
license
Not graded
quality
A
maintenance
Provides a semantic intelligence layer for SQL Server databases, enabling AI agents to understand schema structure, relationships, and safely interact through policy-gated tools.
Updated 12 days ago (2026-08-25 07:12 UTC)
3
MIT
sql-mcp-server
Databases Security
nethinwei
A
license
Not graded
quality
A
maintenance
A governed SQL gateway for untrusted AI agents, providing controlled access to PostgreSQL, MySQL, and OceanBase with RBAC, field ACLs, row policies, and cost controls.
Updated 8 days ago (2026-08-29 03:25 UTC)
MIT
SQLGuard MCP
Databases Security
Advaith789
A
license
Not graded
quality
C
maintenance
Enforces safety and governance for SQL queries executed by AI agents, providing read-only enforcement, cost estimation, and audit trails.
Updated 18 days ago (2026-08-19 00:20 UTC)
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/govern-agents/sql-steward'

If you have feedback or need assistance with the MCP directory API, please join our Discord server