Which integrations are available for this server?

Provides read-only access to PostgreSQL databases with query sandboxing, sensitive column masking, and rate limiting.

How do I use mcp-enterprise-starter?

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., "@mcp-enterprise-starter What tables are available?" 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.

mcp-enterprise-starter

by InkByteStudio

Overview Schema Related Servers Score Discussions

TypeScript

Remote

mcp-enterprise-starter

A production-grade MCP (Model Context Protocol) server that gives AI agents safe, authenticated access to a PostgreSQL database. Built as a reference implementation for teams building custom MCP servers for enterprise workflows.

Architecture

┌─────────────────┐     ┌──────────────────────────────────┐     ┌────────────┐
│  Claude Desktop  │     │       MCP Enterprise Server       │     │            │
│  VS Code         │────▶│                                  │────▶│ PostgreSQL │
│  Any MCP Client  │     │  Auth → Validation → Tool Logic  │     │            │
└─────────────────┘     └──────────────────────────────────┘     └────────────┘

Security layers:

API key authentication on every request
SQL query sandboxing (SELECT only, keyword blocklist)
Parameterized queries (no SQL injection)
Sensitive column masking (email, SSN)
Row limit enforcement
Per-key rate limiting
Structured JSON audit logging

Related MCP server: postgres-mcp-query-tool

Quick Start

Option 1: Docker Compose (recommended)

git clone https://github.com/agrgroup/mcp-enterprise-starter.git
cd mcp-enterprise-starter
cp .env.example .env
docker compose up --build

PostgreSQL starts with seeded sample data. The MCP server connects automatically.

Option 2: Local Development

git clone https://github.com/agrgroup/mcp-enterprise-starter.git
cd mcp-enterprise-starter
npm install
cp .env.example .env

# Start PostgreSQL separately, then seed it:
psql $DATABASE_URL < seed.sql

# Run the server
npm run dev

Connect Claude Desktop

Copy the Claude Desktop config from mcp-config.json into your Claude Desktop configuration file:

macOS: ~/Library/Application Support/Claude/claude_desktop_config.json Linux: ~/.config/Claude/claude_desktop_config.json

{
  "mcpServers": {
    "enterprise-db": {
      "command": "node",
      "args": ["dist/server.js"],
      "cwd": "/path/to/mcp-enterprise-starter",
      "env": {
        "DATABASE_URL": "postgres://mcp_user:mcp_password@localhost:5432/mcp_enterprise",
        "API_KEYS": "your-api-key",
        "ALLOWED_TABLES": "departments,users,projects",
        "SENSITIVE_COLUMNS": "email,ssn"
      }
    }
  }
}

Restart Claude Desktop. Ask: "What tables are available?" to verify the connection.

Connect VS Code

Add to your .vscode/settings.json or user settings:

{
  "mcp": {
    "servers": {
      "enterprise-db": {
        "command": "node",
        "args": ["dist/server.js"],
        "cwd": "${workspaceFolder}/../mcp-enterprise-starter",
        "env": {
          "DATABASE_URL": "postgres://mcp_user:mcp_password@localhost:5432/mcp_enterprise",
          "API_KEYS": "your-api-key",
          "ALLOWED_TABLES": "departments,users,projects",
          "SENSITIVE_COLUMNS": "email,ssn"
        }
      }
    }
  }
}

Tools

Tool	Description
`query_database`	Execute read-only SQL queries with automatic row limiting and sensitive column masking
`list_tables`	List all tables available for querying (from the configured allowlist)
`get_schema`	Get column definitions, types, and constraints for a specific table

Resources

URI Pattern	Description
`db://schema/{table_name}`	Table schema as structured JSON

Configuration

Variable	Default	Description
`DATABASE_URL`	—	PostgreSQL connection string
`API_KEYS`	—	Comma-separated list of valid API keys
`ALLOWED_TABLES`	`departments,users,projects`	Tables the agent can access
`SENSITIVE_COLUMNS`	`email,ssn`	Columns to mask in query results
`ROW_LIMIT`	`100`	Default row limit for queries
`MAX_ROW_LIMIT`	`1000`	Maximum row limit (even if query specifies higher)
`RATE_LIMIT_RPM`	`60`	Requests per minute per API key
`MCP_TRANSPORT`	`stdio`	Transport mode: `stdio` or `sse`
`LOG_LEVEL`	`info`	Logging level

Testing

npm test          # Run all tests
npm run test:watch  # Watch mode

Tests mock the PostgreSQL connection so no database is needed.

Adapt for Your Own Database

Update ALLOWED_TABLES in .env to expose your tables
Update SENSITIVE_COLUMNS to mask your sensitive fields
Update seed.sql with your schema (or remove it and use an existing database)
Add new tools in src/tools/ following the pattern in query-database.ts
Update src/server.ts to register your new tools
Add write operations cautiously — start read-only, add writes with explicit confirmation patterns

Security Notes

API keys are checked on every tool call. No key = no access.
Only SELECT queries are allowed. DROP, DELETE, INSERT, UPDATE, and other write operations are blocked at the query level.
Sensitive columns are masked before results reach the agent. The agent never sees raw PII.
Row limits prevent accidental full-table scans on large tables.
All requests are logged as structured JSON to stderr for audit trails.
The production Docker image runs as a non-root user.

License

MIT

Available Tools

3 tools

get_schemaA

Get the column schema for a specific database table, including column names, data types, nullability, and constraints.

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	Name of the table to inspect

TDQS

A3.9/5.0

Behavior3/5

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

No annotations are provided, so the description bears full burden. It correctly describes a read operation returning schema info, but does not disclose additional behavior such as authentication requirements, read-only nature (though implied), or potential errors for missing tables. The description is adequate for a simple schema query 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?

The description is a single, clear, front-loaded sentence that efficiently communicates the tool's purpose without extraneous words. Every part contributes to understanding.

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 (1 parameter, no output schema, no annotations), the description is complete. It tells the agent exactly what the tool does and what information it returns, which is sufficient for correct invocation.

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 description adds minor value beyond the input schema by mentioning 'specific database table' and listing returned attributes (column names, data types, nullability, constraints). However, with 100% schema description coverage, the baseline is 3, and the description does not add new parameter-level semantics beyond what the schema already provides.

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 'Get the column schema for a specific database table' with specific verb and resource, and lists the returned attributes (column names, data types, nullability, constraints). It distinguishes from siblings (list_tables and query_database) implicitly by focusing on schema rather than table listing or query execution.

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

Usage Guidelines3/5

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

The description implies usage when schema details for a specific table are needed, but it does not explicitly state when to use this tool versus alternatives (e.g., list_tables for table enumeration, query_database for data retrieval). No exclusions or conditions are mentioned.

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

list_tablesA

List all database tables that are available for querying. Returns table names from the configured allowlist.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A4.3/5.0

Behavior3/5

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

No annotations provided; description mentions allowlist restriction but does not disclose potential side effects, authentication needs, or rate limits.

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

Conciseness5/5

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

Two concise sentences front-loading action and result; no wasted words.

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?

Simple tool with no params or output schema; description fully covers purpose and result.

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

Parameters4/5

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

No parameters; schema coverage 100% so description adds no param info, which 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?

Description clearly states verb 'List', resource 'database tables', and scope 'available for querying', distinguishing it from siblings get_schema and query_database.

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?

Implies use for discovering queryable tables via 'configured allowlist', but lacks explicit when-not or alternative comparisons.

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

query_databaseA

Execute a read-only SQL query against the database. Only SELECT statements are allowed. Results from sensitive columns (email, SSN) are automatically masked. Queries are limited to a maximum number of rows.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	SQL SELECT query to execute
`params`	No	Parameterized query values

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations, description carries full burden; it discloses read-only nature, sensitive column masking, and row limits. Additional details like max row count or error behavior would improve, but current level is adequate.

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?

Description is front-loaded with main action and composed of short, information-dense sentences, each adding essential context.

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?

Coverage of constraints is good, but lack of output schema and unspecified max row count leaves minor gaps. Still sufficient for typical 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?

Schema coverage is 100% so baseline is 3. Description adds value beyond schema by specifying query constraints (SELECT only, masking, row limit) that affect parameter usage.

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 executes read-only SQL queries, restricts to SELECT statements, and mentions masking and row limits. It distinguishes from siblings (get_schema, list_tables) which focus on schema discovery.

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 explicitly limits usage to SELECT queries, but does not provide alternative tools for schema exploration or when not to use. However, siblings imply when to use those.

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.0Jul 12, 2026
- First observedget_schema
- First observedlist_tables
- First observedquery_database

Install Server

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

TDQS

A4.2/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: listing tables, getting schema for a specific table, and executing queries. No overlap or ambiguity.

Naming Consistency5/5

All tools follow a consistent verb_noun snake_case pattern (get_schema, list_tables, query_database), making naming predictable.

Tool Count4/5

3 tools is on the lower end but appropriate for a focused database starter. It covers essential operations without being too sparse.

Completeness3/5

Core operations (list tables, get schema, query) are present, but missing advanced features like explain plans or index info. Adequate for a starter.

Maintenance

ActivityInactive

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

Xata
io.github.xataio
Xata MCP server lets AI agents interact with your Xata projects, and Postgres database branches.
Databases Vector Databases RAG Systems
1
nlqdb — analytical memory for AI agents AOAuth
com.nlqdb
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
Databases Knowledge & Memory Search
631
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
Motecloud MemoryOAuth
io.github.motecloud
Cloud-hosted MCP server for durable AI memory
Knowledge & Memory Cloud Platforms
2

Related MCP Servers

postgresql-mcp
Databases Cloud Platforms Developer Tools
vnikhilbuddhavarapu
A
license
Not graded
quality
D
maintenance
A production-ready MCP server that connects AI assistants to any PostgreSQL database with 25 tools and role-based access control.
Updated 3 months ago (2026-06-02 04:43 UTC)
27
MIT
postgres-mcp-query-tool
Databases Developer Tools
nskha101
F
license
Not graded
quality
D
maintenance
An MCP server that gives an AI agent scoped, safe access to your Postgres databases with per-connection access control, row caps, timeouts, and defense-in-depth read-only enforcement.
Updated 3 months ago (2026-06-08 18:18 UTC)
-
AgenticMCP
Databases Developer Tools
mattma87
A
license
Not graded
quality
D
maintenance
A Model Context Protocol (MCP) server that provides secure, role-based access to PostgreSQL databases for AI agents.
Updated 6 months ago (2026-02-26 00:23 UTC)
MIT
mcp-enterprise-agent
Databases File Systems
arnavhazra
F
license
Not graded
quality
C
maintenance
An enterprise-grade MCP server that enables LLM agents to securely interact with PostgreSQL databases and the local file system under absolute sandbox boundaries.
Updated 2 months ago (2026-07-04 11:22 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/InkByteStudio/mcp-enterprise-starter'

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