Which integrations are available for this server?

Provides read-only schema inspection for MySQL databases, exposing table and view names, columns, types, keys, and relationships without exposing row data. Provides read-only schema inspection for PostgreSQL databases, exposing table and view names, columns, types, keys, and relationships without exposing row data. Provides read-only schema inspection for SQLite databases, exposing table and view names, columns, types, keys, and relationships without exposing row data.

How do I use Secure Schema MCP?

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., "@Secure Schema MCP show me the schema of the orders table" 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.

Secure Schema MCP

by Siddharth-coder13

Overview Schema Related Servers Score Discussions

Python

Local

Secure Schema MCP

A read-only MCP server that gives AI coding tools database structure without exposing row data. It returns table and view names, columns, types, keys, and relationships in a compact format designed to reduce LLM token usage.

What it exposes

Exposed	Not exposed
Table and view names	Row values or query results
Column names and SQL types	Row counts or samples
Primary and unique keys	Database credentials
Foreign-key relationships	Write or query tools

Schema metadata can still be sensitive. A column name such as ssn reveals information even without values, so production deployments should always use the table allowlist and a dedicated database account.

Related MCP server: DBMCP

Requirements

An MCP-compatible client such as Cursor or Codex
A reachable SQLite, PostgreSQL, or MySQL database
Python 3.12 or newer when installing without uvx

SQLite support uses Python's built-in driver. PostgreSQL and MySQL drivers are included. Other SQLAlchemy dialects are not tested or bundled in v1.

Configure your IDE

The recommended setup uses uvx to download and run the published Python package in an isolated environment. You do not need to clone this repository or start the server separately. Your IDE launches it over stdio when needed.

Cursor

Add this server to your Cursor MCP configuration:

{
  "mcpServers": {
    "secure-schema": {
      "command": "uvx",
      "args": ["mcp-secure-schema"],
      "env": {
        "DATABASE_URL": "postgresql+psycopg2://schema_reader:password@localhost:5432/appdb",
        "DATABASE_SCHEMA": "public",
        "ALLOWED_TABLES": "users,orders,products",
        "SECURE_SCHEMA_ENV": "production",
        "FASTMCP_CHECK_FOR_UPDATES": "off",
        "FASTMCP_SHOW_SERVER_BANNER": "false"
      }
    }
  }
}

Restart or reload Cursor after changing its MCP configuration.

Codex

Add this to ~/.codex/config.toml or a trusted project's .codex/config.toml:

[mcp_servers.secure-schema]
command = "uvx"
args = ["mcp-secure-schema"]
enabled_tools = ["schema_overview", "list_tables", "inspect_table"]
startup_timeout_sec = 30
tool_timeout_sec = 30

[mcp_servers.secure-schema.env]
DATABASE_URL = "postgresql+psycopg2://schema_reader:password@localhost:5432/appdb"
DATABASE_SCHEMA = "public"
ALLOWED_TABLES = "users,orders,products"
SECURE_SCHEMA_ENV = "production"
FASTMCP_CHECK_FOR_UPDATES = "off"
FASTMCP_SHOW_SERVER_BANNER = "false"

Install once instead

If you prefer a persistent installation:

pipx install mcp-secure-schema

Then use "command": "mcp-secure-schema" with an empty args list in the IDE configuration.

Database URLs

Secure Schema MCP accepts SQLAlchemy connection URLs:

# SQLite (absolute path)
sqlite:////Users/me/project/app.db

# PostgreSQL
postgresql+psycopg2://user:password@localhost:5432/appdb

# Remote PostgreSQL with certificate verification
postgresql+psycopg2://user:password@db.example.com:5432/appdb?sslmode=verify-full&sslrootcert=/path/to/ca.pem

# MySQL
mysql+pymysql://user:password@localhost:3306/appdb

Percent-encode special characters in URL usernames and passwords. For example, @ in a password becomes %40.

Local and remote databases use the same MCP configuration. For remote databases, the machine running the IDE must also have working DNS, network access, firewall permission, and valid TLS settings.

Configuration

Variable	Required	Description
`DATABASE_URL`	Yes	SQLAlchemy connection URL. Treated as a secret by the registry manifest.
`DATABASE_SCHEMA`	No	Default schema or catalog namespace. Recommended for PostgreSQL. Locked against tool overrides in production.
`ALLOWED_TABLES`	Production	Comma-separated, case-sensitive table and view allowlist. Production mode refuses to start without it.
`SECURE_SCHEMA_ENV`	No	Set to `production` or `prod` for strict startup validation. Defaults to `development`.
`FASTMCP_CHECK_FOR_UPDATES`	No	Set to `off` for predictable stdio startup.
`FASTMCP_SHOW_SERVER_BANNER`	No	Set to `false` to suppress the startup banner.

Multiple schemas

DATABASE_SCHEMA selects the default namespace. Resolution works as follows:

In production, a configured DATABASE_SCHEMA is a security boundary and tool arguments cannot override it.
Outside production, an explicit tool schema argument overrides DATABASE_SCHEMA.
Without either value, the database driver's default schema is used.

For strict production access to multiple schemas, run one MCP server entry per schema with its own DATABASE_SCHEMA and ALLOWED_TABLES values. The table allowlist contains unqualified names, not schema.table values.

Tools

schema_overview: compact map of permitted tables, views, primary keys, and foreign-key relationships
list_tables: permitted table and view inventory
inspect_table: columns, SQL types, nullability, primary keys, unique constraints, and foreign keys for one entity

Every tool defaults to format="compact" for lower token usage:

tables:orders,users | pk:orders(order_id);users(user_id) | fk:orders.user_id->users.user_id

Pass format="markdown" when a human-readable table is more useful.

Security notes

The server exposes only SQLAlchemy inspection operations; it provides no row-query or write tool.
Missing and disallowed table names return the same message when an allowlist is active, avoiding an existence leak.
Client-facing errors are sanitized. Operational details are written to server stderr.
The IDE launches the MCP process and supplies its environment, so treat the IDE and its configuration as trusted.
Do not commit configurations containing credentials. For stronger isolation, launch through a wrapper that obtains DATABASE_URL from an OS keychain or secret manager.
Use a dedicated least-privilege database account and TLS certificate verification for remote connections.

Example PostgreSQL role:

CREATE ROLE schema_reader LOGIN PASSWORD 'use-a-secret-manager';
GRANT CONNECT ON DATABASE appdb TO schema_reader;
GRANT USAGE ON SCHEMA public TO schema_reader;

Metadata visibility varies by PostgreSQL provider and database policy. Grant only the additional catalog or object privileges required for inspection; avoid granting row SELECT unless your environment requires it.

Troubleshooting

The server exits immediately

Check the IDE's MCP logs. DATABASE_URL is mandatory, and production mode also requires a non-empty ALLOWED_TABLES value.

No tables or views are discovered

Confirm DATABASE_SCHEMA, exact table-name casing, database permissions, and whether the allowlist contains the expected names.

The connection URL fails with a valid password

Percent-encode reserved URL characters or use a secret-injection wrapper. Do not paste real credentials into issues or logs.

uvx is not found

Install uv using its official instructions, or install the package with pipx and use mcp-secure-schema as the command.

Starting the command appears to hang

That is normal for a stdio MCP server. It waits for an MCP client on standard input and is normally started by the IDE.

Development

Clone the repository only when developing or testing the server:

git clone https://github.com/Siddharth-coder13/secure_schema_mcp.git
cd secure_schema_mcp
uv sync --extra dev
uv run python tests/demo_database.py
DATABASE_URL="sqlite:///$PWD/test_schema.db" uv run mcp-secure-schema

Run the test suite:

uv run pytest

Run the opt-in PostgreSQL integration test against a disposable database. The test creates and removes a randomly named schema:

POSTGRES_TEST_DATABASE_URL='postgresql+psycopg2://user@localhost:5432/testdb' \
  uv run pytest tests/test_postgres_smoke.py -v

The tests verify row-data isolation, allowlist behavior, sanitized errors, compact output, relationships, schema selection, and the locked production namespace.

Release checklist

Maintainers should update the matching versions in pyproject.toml and server.json, run the complete SQLite and PostgreSQL suites, build with uv build --no-sources, verify installation from the wheel, publish to PyPI, and only then publish server.json to the MCP Registry.

License

Licensed under the Apache License 2.0. See LICENSE and NOTICE.

Available Tools

3 tools

inspect_tableA

Exposes exact column names, types, nullability, primary keys, and foreign key relationships. Strictly constrained to structural layouts. Does not reveal data rows.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format. Use compact to reduce LLM token usage; markdown for human-readable output.	compact
`schema`	No	Optional schema/catalog namespace. Overrides DATABASE_SCHEMA only outside production.
`table_name`	Yes	The exact case-sensitive name of the table to inspect.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4/5.0

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.

list_tablesA

Lists all user tables and views available in the current database. Use this to understand what architectural entities exist.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format. Use compact to reduce LLM token usage; markdown for human-readable output.	compact
`schema`	No	Optional schema/catalog namespace. Overrides DATABASE_SCHEMA only outside production.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

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 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.

schema_overviewA

Summarizes available tables, views, primary keys, and foreign key relationships. Strictly constrained to structural metadata. Does not reveal data rows.

ParametersJSON Schema

Name	Required	Description	Default
`format`	No	Output format. Use compact to reduce LLM token usage; markdown for human-readable output.	compact
`schema`	No	Optional schema/catalog namespace. Overrides DATABASE_SCHEMA only outside production.

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

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.

Tool Schema Changelog

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

3 tool updatesv1.0.1Jul 4, 2026
- First observedinspect_table
- First observedlist_tables
- First observedschema_overview

Install Server

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

TDQS

A3.9/5.0

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.

Maintenance

ActivityStale

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

ChrysaiOAuth
com.chrysai.www
Hosted MCP server for AI-driven data ops. Create apps, manage schemas, and CRUD structured data.
Data Platforms Developer Tools App Automation
2
CData Connect AIOAuth
com.cdata
Cloud-hosted MCP server for secure AI access to enterprise data sources via CData Connect AI.
Databases RAG Systems Cloud Platforms
2
dataOAuth
co.thinair
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Databases Developer Tools
2
Dataassist-IOOAuth
io.github.DataAssistIO
Query your org's data in natural language — read-only MCP access to SQL, NoSQL, files & warehouses.
Search Databases
2

Related MCP Servers

SQL Server MCP
Databases Developer Tools
az-coder-123
A
license
B
quality
D
maintenance
An MCP server that connects AI assistants to Microsoft SQL Server databases, enabling schema exploration and read-only queries safely.
Updated 5 months ago (2026-03-29 15:10 UTC)
49
37
4
MIT
DBMCP
Databases RAG Systems
jesse-smith
A
license
Not graded
quality
D
maintenance
MCP server providing read-only access to SQL Server databases for AI assistants, enabling schema exploration, query execution, and foreign key inference with token-efficient TOON responses.
Updated 3 months ago (2026-06-15 06:32 UTC)
1
MIT
MCP Server for Database
Databases Developer Tools
thanhphat2609
F
license
Not graded
quality
F
maintenance
A read-only MCP server that enables AI agents to explore database schemas and execute safe queries on PostgreSQL and MySQL.
Updated 5 months ago (2026-03-26 16:19 UTC)
-
Oracle DB MCP
Databases Developer Tools
muazam99
F
license
Not graded
quality
C
maintenance
Read-only MCP server that lets coding AI agents inspect Oracle Database schema through live metadata.
Updated 2 months ago (2026-07-18 06:34 UTC)
-

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

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