Skip to main content
Glama
Siddharth-coder13

Secure Schema MCP

by Siddharth-coder13
OverviewSchemaRelated ServersScoreDiscussions
Python
Local

Server Quality Checklist

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

  • Latest release: v1.0.1

  • Disambiguation3/5

    list_tables and schema_overview both list tables/views, creating overlap. inspect_table is distinct but also covers PK/FK info that schema_overview summarizes. Descriptions help distinguish, but ambiguity remains.

    Naming Consistency3/5

    Two tools use verb_noun pattern (inspect_table, list_tables), while schema_overview uses noun_noun. The inconsistency is minor but noticeable.

    Tool Count4/5

    Three tools is appropriate for a focused schema exploration server. The count covers essential operations without being excessive.

    Completeness4/5

    Covers listing tables, detailed table inspection, and schema summary. Minor gaps like lack of view-specific inspection or filtering, but overall the surface is sufficient for the domain.

  • Average 4.1/5 across 3 of 3 tools scored.

    See the Tool Scores section below for per-tool breakdowns.

    • No community issues in the last 6 months
    • 2 commits in the last 12 weeks
    • No stable releases found
    • No critical vulnerability alerts
    • No high-severity vulnerability alerts
    • No code scanning findings
    • CI status not available

  • This repository is licensed under Apache 2.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

  • Behavior4/5

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

    With no annotations, the description handles disclosure by stating it only returns structural metadata and no data rows. It could mention it is read-only or has no side effects, but the current text is still adequately transparent.

    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 sentences, no fluff. The first sentence captures the essential purpose, and the second clarifies constraints. Very efficient.

    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 an output schema exists (not shown), the description does not need to detail return values. It covers the tool's scope adequately, though it could benefit from mentioning permissions or performance.

    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?

    Schema coverage is 100%, and the description adds no extra parameter info beyond what the input schema already provides. Baseline score of 3 is appropriate.

    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 exposes column names, types, nullability, primary keys, and foreign key relationships. It is distinct from sibling tools like list_tables and schema_overview by specifying 'structural layouts' and explicitly noting it does not reveal data rows.

    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 use for structural inspection only via 'Does not reveal data rows,' but lacks explicit when-to-use or when-not-to-use guidance, nor does it reference sibling tools for data queries.

    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 carries the full burden. It discloses that it lists 'all' tables and views, which implies a read operation. However, it does not state that it is non-destructive, read-only, or if there are any performance implications. For a simple listing tool, this is acceptable but could be more explicit.

    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: the first defines the action, the second provides usage guidance. It is concise, front-loaded, and every word earns its place. No redundancy or unnecessary 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?

    For a tool with 2 simple parameters, no required fields, and an output schema, the description is adequately complete. It covers what the tool does and when to use it. It does not mention edge cases like system tables or performance, but given the low complexity, it is sufficient.

    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?

    Schema coverage is 100% with detailed descriptions for both parameters. The tool description does not add additional meaning beyond what is already in the schema. Therefore, the baseline score of 3 is appropriate.

    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 it 'Lists all user tables and views available in the current database.' This is a specific verb and resource, and it distinguishes from siblings like 'inspect_table' (which inspects a single table) and 'schema_overview' (which likely gives a broader schema summary). The purpose is explicit.

    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 includes 'Use this to understand what architectural entities exist,' which provides clear context for when to use the tool. However, it does not explicitly state when not to use it or compare it to alternatives (siblings), so it slightly lacks in exclusion guidance.

    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?

    No annotations provided, so description carries full burden. It discloses that only structural metadata is returned, no data rows, and mentions output format options. This adequately sets expectations for a read-only, non-destructive tool.

    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 sentences, no redundant text. The purpose and key constraints are front-loaded. Every word earns its place.

    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 the tool's simplicity, presence of an output schema, and high schema description coverage, the description is complete. It explains scope, constraints, and parameter nuances sufficiently.

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

    Parameters5/5

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

    Schema coverage is 100%. The description adds value beyond the schema: for 'format' it explains token usage vs human readability, and for 'schema' it clarifies it only overrides outside production. This helps the agent decide parameter values.

    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 summarizes structural metadata including tables, views, primary keys, and foreign keys. It explicitly distinguishes from sibling tools by noting it does not reveal data rows, indicating a broader scope than inspect_table or list_tables.

    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 structural overview but does not explicitly compare to sibling tools or state when to use which. The constraint 'Strictly constrained to structural metadata' gives context but lacks explicit guidance on alternatives.

    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

secure_schema_mcp MCP server

Copy to your README.md:

Score Badge

secure_schema_mcp MCP server

Copy to your README.md:

Latest Blog Posts

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/Siddharth-coder13/secure_schema_mcp'

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