Schema Sentinel

by ramoniglesias98

Overview Schema Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.4/5 across 8 of 8 tools scored. Lowest: 2.6/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 7 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under AGPL 3.0.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![schema-sentinel MCP server](https://glama.ai/mcp/servers/ramoniglesias98/schema-sentinel/badges/card.svg)](https://glama.ai/mcp/servers/ramoniglesias98/schema-sentinel)

Score Badge

Copy to your README.md:

[![schema-sentinel MCP server](https://glama.ai/mcp/servers/ramoniglesias98/schema-sentinel/badges/score.svg)](https://glama.ai/mcp/servers/ramoniglesias98/schema-sentinel)

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/ramoniglesias98/schema-sentinel'

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