This server provides read-only tools to analyze a Postgres database and its paired git repository, offering schema insights, migration risk detection, and health reporting.
Schema Overview: Retrieve tables, columns, primary keys, and foreign keys.
Missing Indexes: Identify FK columns lacking covering indexes.
Circular Foreign Keys: Detect FK cycles across tables, with one example cycle per group.
Table Complexity: See column counts, FK fan-in/fan-out, and cycle involvement per table.
ERD Generation: Produce a Mermaid erDiagram representation of the schema.
Migration Risk Check: Statically parse a SQL migration file for dangerous patterns (e.g., DROP COLUMN, ALTER COLUMN TYPE, RENAME COLUMN/TABLE, ADD COLUMN NOT NULL without DEFAULT, CREATE INDEX without CONCURRENTLY) without executing it.
Schema Churn: Analyze git history to see how often and how recently each table's migrations changed, optionally filtered by a time window.
Combined Report: Generate a full schema health report from all the above insights, optionally filtered by time window.
Analyzes the paired Git repository to track schema churn and migration history, identifying how often and how recently each table's migrations have changed.
Provides read-only tools for inspecting a PostgreSQL schema, including tables, columns, primary and foreign keys, missing indexes, circular foreign keys, table complexity, and ERD generation. Also parses migration files to flag risky database operations without executing them.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Schema Sentinel Generate a schema health report for the last 30 days"
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.
Read-only MCP server that lets an AI agent look at a Postgres db + its paired git repo and just... know what's going on. Schema, ERD, missing indexes, circular FKs, migration risk, git-churn hotspots, all the stuff you'd normally dig up by hand with psql and git log.
Works against any Postgres + repo pair via .env config (connection string + repo path). Not hardcoded to one project.
Two reasons: it's a portfolio piece, and it was my hands-on way of actually learning MCP, schema introspection, static SQL parsing, git analysis, and wiring all of it up as agent-callable tools.
Related MCP server: MCP Server for Database
Tool | Args | What it does |
| — | Tables, columns, PKs, FKs for the connected db |
| — | Flags FK columns with no covering index |
| — | Catches FK cycles across tables, and shows one concrete cycle per group |
| — | Per table: column count, FK fan-in/fan-out, whether it's tangled in a cycle |
| — | Spits out a Mermaid |
|
| Statically parses one migration file and flags risky stuff. Never runs it |
|
| How often, and how recently, each table's migrations changed |
|
| Rolls all of the above into one health report |
check_migration_risk parses the file and flags six patterns:
Pattern | Severity | Why |
| high | irreversible data loss |
| high | rewrites the table, holds a long lock, can silently truncate |
| high | breaks in-flight app code still using the old name mid-deploy |
| high | same, but takes out every FK pointing at the table too |
| medium | fails outright once the table has rows |
| medium | blocks writes for however long the build takes |
pip install -e . (or pip install -e ".[dev]" to also get pytest).
Copy .env.example to .env and fill in SCHEMA_SENTINEL_DB_URL, SCHEMA_SENTINEL_REPO_PATH, SCHEMA_SENTINEL_MIGRATIONS_PATH. The db role has to be read-only, run scripts/setup_readonly_role.sql against your database first if you don't already have one.
Run it: schema-sentinel (installed as a console script), or python -m schema_sentinel.server. Either way it speaks MCP over stdio.
To wire it into an MCP client, point the client at the console script and hand it the three env vars:
{
"mcpServers": {
"schema-sentinel": {
"command": "schema-sentinel",
"env": {
"SCHEMA_SENTINEL_DB_URL": "postgresql://schema_sentinel_ro@localhost:5432/your_database",
"SCHEMA_SENTINEL_REPO_PATH": "/path/to/your/repo",
"SCHEMA_SENTINEL_MIGRATIONS_PATH": "/path/to/your/repo/migrations"
}
}
}
}Python + psycopg v3 (psycopg[binary]) for Postgres.
The mcp SDK's bundled FastMCP (mcp.server.fastmcp) for the server, not the standalone fastmcp package. Pinned to mcp<2 deliberately, see the rough edges below.
Mermaid erDiagram text for the ERD, no Graphviz, no rendering lib. GitHub and Notion already render Mermaid natively, so why bother.
pglast (wraps libpg_query, Postgres's own C parser) to statically parse migrations. check_migration_risk only ever parses, never runs, a migration. Non-negotiable.
Worth saying why it's pglast and not a generic multi-dialect parser: I started on one and found it silently gave up on multi-item DDL. ALTER TABLE x DROP COLUMN a, ALTER COLUMN b TYPE int came back as an unparsed blob, which meant a genuinely dangerous migration would sail through reporting zero risks, and DROP TABLE a, b; raised outright. Both are ordinary SQL. pglast doesn't approximate the grammar, it is the grammar, so neither is a problem.
GitPython for the churn/file-history stuff.
Introspection goes through pg_catalog, not information_schema. Not a style preference: information_schema.table_constraints and friends gate visibility behind write-ish privileges, so a strictly read-only role sees zero rows there. Which is exactly the role this thing is designed to run as.
psycopg3 param binding: list filters use = ANY(%s), not IN %s. psycopg3 doesn't auto-expand a Python list into a SQL IN (...) the way psycopg2 did. Bit me once, not doing it again.
Churn and complexity stay separate. Churn is a pure git signal, complexity is a pure schema signal, neither reaches into the other's half. generate_report hands you both.
Enforced in src/schema_sentinel/db/connection.py:
Session-level lock, SET SESSION CHARACTERISTICS AS TRANSACTION READ ONLY right after connecting, before anything else runs.
Startup privilege check, checks pg_roles for rolsuper / rolcreatedb / rolcreaterole, and information_schema.role_table_grants for any non-SELECT grant on the connecting role. Either one fails, the connection gets closed and it raises WritableConnectionError, no usable connection handed back, period.
scripts/setup_readonly_role.sql sets up a correctly-scoped read-only role in one step, instead of doing it by hand.
The migration checker never touches the database at all, it only reads files off disk.
src/schema_sentinel/
├── config.py env config -> Settings
├── schema.py get_schema_overview, find_missing_indexes,
│ find_circular_foreign_keys, find_table_complexity
├── erd.py generate_erd
├── migrations.py check_migration_risk
├── report.py generate_report
├── server.py MCP entrypoint, registers all 8 tools
├── db/connection.py the read-only gatekeeper
└── git_ops/churn.py find_schema_churn
tests/ mirrors src/, plus tests/test_db/ and tests/test_git_ops/
scripts/ setup_readonly_role.sql, setup_test_db.sqlMost of the suite is DB-free, but the schema/connection/report tests run against a real local Postgres, since the whole point of the connection tests is proving actual grant enforcement and you can't meaningfully mock that.
createdb schema_sentinel_test
psql -d schema_sentinel_test -f scripts/setup_test_db.sql
pytestsetup_test_db.sql builds the fixture tables (simple and composite PKs, simple and composite FKs, one FK deliberately left unindexed) plus the three roles the connection tests need. Point the SCHEMA_SENTINEL_TEST_* URLs in .env at them. CI does exactly this against a throwaway Postgres container on every push.
Schema-qualified names get flattened. Churn keys everything by bare table name, so public.orders and analytics.orders would land in the same bucket. Fine for the single-schema case, wrong for anything fancier.
The risk checker knows six patterns. Plenty of other things worth flagging aren't in there yet: ADD CONSTRAINT without NOT VALID, SET NOT NULL on an existing column, volatile DEFAULTs, VACUUM FULL, CLUSTER.
generate_report re-queries more than it needs to. Several tools call get_schema_overview or the constraint fetch independently, so a full report hits pg_constraint a handful of times over. Each tool being self-contained was the deliberate tradeoff, but on a big schema it's wasteful.
Pinned to mcp 1.x. 2.0 removed mcp.server.fastmcp, which is what server.py is written against, so upgrading means porting the tool registration to whatever replaced it. Pinned rather than rushed.
Complexity is a raw count, not a score. Fan-in, fan-out and column count get sorted, not weighted, and nothing multiplies churn against complexity to give you a single "hotspot" number. You get both halves and draw your own conclusions.
AGPL-3.0-or-later, full text in LICENSE.
Short version: read it, run it, fork it, learn from it, all fine. But if you distribute a modified version, or run one as a service other people can reach, you have to publish your source too.
Copyright (C) 2026 Ramón Iglesias
This program is free software: you can redistribute it and/or modify
it under the terms of the GNU Affero General Public License as published
by the Free Software Foundation, either version 3 of the License, or
(at your option) any later version.
This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
GNU Affero General Public License for more details.
You should have received a copy of the GNU Affero General Public License
along with this program. If not, see <https://www.gnu.org/licenses/>.
Statically parses a single migration .sql file and flags risky patterns. Never executes it.
| Name | Required | Description | Default |
|---|---|---|---|
| sql_path | Yes |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of safety disclosure. It clearly states "Never executes it," indicating the tool is non-destructive, and "Statically parses" further implies no mutation. However, it does not elaborate on what specific risky patterns are flagged or whether any external state is read beyond the file.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with two clauses, front-loading the main verb and resource. Every word contributes value, and there is no redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a simple tool with one parameter and an output schema present, so the description doesn't need to detail return values. It covers the core purpose, scope, and safety behavior. However, it does not explicitly mention what constitutes a risky pattern, which could be considered a minor completeness gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 0% description coverage for sql_path, and the description does not explicitly define this parameter. However, the phrase "single migration .sql file" implicitly communicates that the path should point to such a file, providing some contextual compensation for the missing schema description.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb "parses" and clearly identifies the resource (a single migration .sql file) and outcome (flags risky patterns). It also distinguishes itself from sibling tools like find_missing_indexes or generate_erd, which analyze the schema rather than migration files.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for checking a migration file before execution via "Never executes it" and "single migration .sql file," but it does not explicitly state when to use this tool vs. alternatives, nor does it mention exclusions or prerequisites.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Catches FK cycles across tables.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, and the description does not disclose behavioral details beyond the metaphorical 'catches.' It does not state whether the tool returns a list, whether it is purely read-only, or what side effects (if any) occur. This lack of transparency leaves the agent uncertain about the tool's actual behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single five-word sentence, front-loaded and free of extraneous content. It earns high marks for efficiency.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's simplicity (zero parameters) and the presence of an output schema, the description is mostly sufficient. However, it could benefit from noting any operational context, such as whether it scans the entire schema and what the output represents, though the output schema likely covers that.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema defines zero parameters, so there is nothing to document. The description adds no parameter information, but none is needed. The baseline score of 4 applies for zero-parameter tools.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'catches' and identifies the resource 'FK cycles across tables.' It clearly distinguishes this tool from siblings like find_missing_indexes and generate_erd, which address different schema aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives, nor does it mention any exclusions. The intended usage is only implied by the tool's name and description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Flags FK columns with no covering index.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears the full behavioral disclosure burden. "Flags" implies a read-only analysis operation and is not misleading, but the description does not disclose scope, return format, or whether the analysis covers the entire schema.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence: "Flags FK columns with no covering index." It contains no extraneous words and every word contributes to the meaning.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool with an output schema, the description is largely complete: it conveys the core purpose clearly. It lacks explicit scope or usage context, but the simplicity of the tool makes this a minor gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the description needs no parameter semantics. The empty schema fully covers the parameter set, and the zero-parameter baseline of 4 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description begins with the action verb "Flags" and identifies the specific resource: "FK columns with no covering index." This clearly differentiates the tool from siblings like find_circular_foreign_keys or generate_erd.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description states only what the tool does and provides no guidance on when to use it versus alternatives. It does not mention scenarios where siblings such as check_migration_risk or get_schema_overview might be more appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Git-history churn per table: how often (and how recently) each table's migrations changed.
| Name | Required | Description | Default |
|---|---|---|---|
| since_days | No |
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It reveals that the tool reads Git history and computes churn frequency and recency, which is useful. However, it does not mention whether the operation is read-only, what the output looks like beyond the schema, or how the optional since_days parameter affects behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, tightly packed sentence that conveys the core purpose without unnecessary words. It is front-loaded with the key concept ('Git-history churn per table') and immediately expands on what that means.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has one optional parameter and an output schema, but the description fails to explain the parameter's meaning or provide any usage context. Since the schema coverage is 0% and there are no annotations, the description is the only source of semantic context, and it is incomplete for a tool with even a single parameter.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The sole parameter, since_days, is completely unexplained. The schema provides no description (coverage 0%), and the tool description does not mention it. The description's reference to 'how recently' hints at a time window, but does not clarify that since_days controls it. This is a significant gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool does: it computes Git-history churn per table, measuring how often and how recently migrations changed. This is specific and distinguishes it from sibling tools, which focus on indexes, foreign keys, complexity, ERD generation, migration risk, and overviews.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given on when to use this tool versus alternatives. The description does not mention any context, prerequisites, or exclusions. While the purpose implies use for schema evolution analysis, explicit usage guidance is absent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Structural complexity per table: column count, FK fan-in/out, circular-FK involvement.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are present, so the description must carry the behavioral transparency burden. It discloses the computed metrics and the per-table scope, but it does not mention whether the operation is read-only, potential performance implications, or how circular-FK involvement is determined. The information provided is moderately transparent but lacks depth.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core concept and enumerates the key metrics. There is no filler or redundant information.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With zero parameters and an existing output schema, the description sufficiently covers the tool's scope for an agent to select and invoke it. Minor gaps remain around interpreting 'circular-FK involvement' and how this output differs from sibling tools, but these are not critical for basic usage.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters, so the baseline for parameter semantics is 4. The description adds clarity by explaining what the tool evaluates rather than focusing on inputs, which is appropriate for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states what the tool computes: structural complexity per table with specific metrics (column count, FK fan-in/out, circular-FK involvement). It lacks an explicit action verb like 'calculate' or 'analyze', but the noun phrase is unambiguous and the tool name reinforces the purpose. It distinguishes itself from sibling find_circular_foreign_keys by being broader in scope, though not explicitly.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives such as find_missing_indexes, find_circular_foreign_keys, or generate_erd. The description only states what the tool does, not when it should be selected or what prerequisites or contexts it is best suited for.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Mermaid erDiagram text for the connected schema.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
| Name | Required | Description |
|---|---|---|
| result | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of behavioral disclosure. It only states the output is text for the connected schema, implying a read operation, but does not disclose whether it reads the live schema, whether it requires a connection or permissions, or if there are any performance implications. No caveats or side effects are mentioned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused phrase that immediately communicates the output type (Mermaid erDiagram text) and the target (connected schema). It is appropriately concise for a zero-parameter tool, though it could be slightly more informative without becoming verbose.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the presence of an output schema and zero parameters, the description covers the essential function. However, it lacks contextual completeness by not explaining what 'connected schema' means, how it differs from get_schema_overview, or any prerequisites. The tool appears simple, but a usage hint would significantly improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, and the schema coverage is trivially 100%. The description adds no parameter-specific details, but none are needed; the baseline for zero-parameter tools is 4, and this satisfies that.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description identifies the resource ('connected schema') and the output format ('Mermaid erDiagram text'), which clearly distinguishes it from sibling tools focused on analysis (e.g., find_missing_indexes) and reporting (generate_report). However, it lacks an explicit verb, relying on the tool name to imply 'generate', which prevents a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like get_schema_overview or generate_report. It does not state that it is for visualizing schema relationships, nor does it mention any exclusions or alternative tools. This is a significant gap for a tool with no parameter guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Rolls every tool above into one combined health report.
| Name | Required | Description | Default |
|---|---|---|---|
| since_days | No |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It discloses that the tool executes all other tools ('rolls every tool above'), but it does not state whether the operation is read-only, whether it has side effects, what the report format looks like, or any performance implications. Given the tool's nature as a composite of many potentially heavy operations, this lack of transparency is problematic.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no redundant words, effectively front-loading the core purpose. It is concise and structured well, but it may be overly terse in that it omits important contextual details. Still, as a concise statement, it is appropriately minimalist for the core message, earning a high score.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool that aggregates multiple sibling tools, the description is incomplete. It fails to explain what the combined report contains, how 'since_days' affects the aggregation, or how this differs from running each tool individually. Given the lack of annotations and output schema, the description should provide more context to compensate, but it does not.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention the 'since_days' parameter at all. The schema only provides type information (integer or null) and a default of null, but no explanation of what the parameter controls. The description fails to compensate for the complete absence of parameter semantics, leaving agents without any guidance on how to use or interpret this parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states that the tool 'rolls every tool above into one combined health report,' which clearly indicates its purpose as an aggregator that synthesizes results from the other tools. This distinguishes it from the sibling tools, which are individual analysis utilities. However, the phrase 'tool above' is slightly ambiguous without the context of the sibling list, and 'health report' is not elaborated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus running the individual sibling tools. It is implied that one would use it to get a consolidated view, but there is no stated recommendation, prerequisites, or mention of alternatives. The lack of any usage context makes this a notable gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Tables, columns, PKs, FKs for the connected database.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It does not mention that this is a read-only operation, how large the response might be, or whether any filtering or formatting applies. The description merely lists content items without behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single short sentence that is entirely front-loaded with the key information. It contains no unnecessary words, making it appropriately concise for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
No output schema is present, so the description should explain the return format, but it does not. The fragment 'Tables, columns, PKs, FKs' is ambiguous about whether the output is a list, a nested object, or a formatted report, leaving gaps for an agent.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there are no parameter semantics to clarify. The description's content listing (tables, columns, PKs, FKs) aligns with what an overview would provide, satisfying the baseline for a parameter-less tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides schema metadata including tables, columns, primary keys, and foreign keys for the connected database. It is specific about the content scope, though it lacks an explicit verb; the tool name 'get_schema_overview' supplies that. It doesn't explicitly contrast with sibling tools, but the content is distinct from analytical siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance on when to use this tool versus alternatives like find_missing_indexes or generate_erd. The description only declares what the tool returns, not when it should be invoked or what scenarios it addresses.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0check_migration_riskfind_circular_foreign_keysfind_missing_indexesfind_schema_churnfind_table_complexitygenerate_erdgenerate_reportget_schema_overviewEach tool targets a distinct analytical concern: index coverage, FK cycles, table complexity, ERD generation, migration risk, schema churn, combined reporting, and schema overview. There is no meaningful overlap between tool purposes.
All tool names follow a consistent verb-first snake_case pattern (e.g., find_missing_indexes, generate_erd). The verbs are imperative and the object is clear, making the set predictable.
Eight tools is well-scoped for a schema health analysis server. Each tool earns its place and covers a specific aspect of schema inspection without bloat.
The toolset covers a broad range of schema health checks: current schema, migrations, history, and ERD generation. Minor gaps exist such as index performance analysis or orphaned FK detection, but the core workflows are solid.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/ramoniglesias98/schema-sentinel'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
