Which integrations are available for this server?

Allows exploring and querying PostgreSQL databases, including table structure inspection, statistical profiling, entity-relationship diagrams, and safe query execution. Allows exploring and querying SQLite databases, including table structure inspection, statistical profiling, entity-relationship diagrams, and safe query execution.

How do I use mcp-db-explorer?

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-db-explorer List all tables in the database" 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-db-explorer

by arman1o1

Overview Schema Related Servers Score Discussions

Python

Local

Model Context Protocol Database Explorer

A Model Context Protocol (MCP) server that exposes tools for exploring and querying SQLite and PostgreSQL databases. It allows Large Language Models (LLMs) to inspect table structures, perform statistical profiling, generate entity-relationship diagrams, and execute queries safely.

Overview

The Database Explorer MCP Server provides a bridge between LLMs and SQL databases. It features read-only constraints by default, AST-based query safety verification, automatic schema visualization, and execution plan inspection tools.

Related MCP server: PostgreSQL Advanced MCP Server

Architecture

The diagram below outlines the flow of a client request to the database via the MCP server:

graph TD
    Client[MCP Client] -->|JSON-RPC| Server[MCP Database Explorer Server]
    Server -->|Parse & Safety Check| Safety[Safety Validator]
    Safety -->|AST Verification| Allowed{Safe?}
    Allowed -->|Yes| Database[(Database: SQLite / PostgreSQL)]
    Allowed -->|No| Block[Block Query & Return Error]
    Database -->|Query Results| Server
    Server -->|Response| Client

Project Structure

mcp-db-explorer/
├── .github/
│   └── workflows/
│       └── ci.yml             # GitHub Actions CI workflow
├── mcp_db_explorer/
│   ├── __init__.py
│   ├── database.py            # Database connection and querying logic
│   ├── prompts.py             # Prompt templates (e.g. NL-to-SQL)
│   ├── safety.py              # AST-based SQL safety validation
│   └── server.py              # MCP Server definition and CLI entrypoint
├── tests/
│   ├── test_database.py       # Tests for database connections and queries
│   ├── test_safety.py         # Tests for AST query validation
│   └── test_server.py         # Tests for MCP server tool schemas
├── pyproject.toml             # Project dependency configuration
└── README.md                  # Project documentation

Setup and Installation

Prerequisites

Ensure you have Python 3.10 or later installed on your system.

1. Clone the Repository

git clone https://github.com/arman1o1/mcp-db-explorer
cd mcp-db-explorer

2. Setup and Install Dependencies

Option A: Using uv (Recommended)

This project is configured with uv. To install dependencies and set up the virtual environment, run:

uv sync

Option B: Using pip and venv

You can set up a virtual environment and install dependencies manually:

python -m venv .venv
source .venv/bin/activate  # On Windows: .venv\Scripts\activate
pip install -e .

Running the Application

Running with uv

To run the MCP server, use the uv run command:

uv run mcp-db-explorer --db-type sqlite --connection-string my_database.db

Configuration Options

The server accepts several options via command-line arguments or environment variables:

Argument	Environment Variable	Description
`--db-type`	`DB_TYPE` or `MCP_DB_TYPE`	Default database engine type (`sqlite`, `postgres`, `postgresql`)
`--connection-string`	`DATABASE_URL` or `MCP_DB_CONNECTION_STRING`	Database connection string (path for SQLite, URI for PostgreSQL)
`--allow-writes`	`ALLOW_WRITES`	Enable write operations (DML/DDL queries). Disabled by default.
`--allowed-dir`	`ALLOWED_DATABASE_DIR`	Restricts SQLite database paths to be inside this directory.

Client Integration

To use this server with an MCP client (such as Claude Desktop), add the server configuration to your client configuration file.

Claude Desktop Configuration

Open your claude_desktop_config.json:

Windows: %APPDATA%\Claude\claude_desktop_config.json
macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

Add the following configuration (use absolute paths):

{
  "mcpServers": {
    "mcp-db-explorer": {
      "command": "uv",
      "args": [
        "--directory",
        "C:\\absolute\\path\\to\\mcp-db-explorer",
        "run",
        "mcp-db-explorer",
        "--db-type",
        "sqlite",
        "--connection-string",
        "C:\\absolute\\path\\to\\my_database.db"
      ]
    }
  }
}

Replace the paths with the correct ones for your local setup.

Testing

To run the test suite, run:

uv run pytest

License

This project is licensed under the MIT License - see the LICENSE file for details.

Available Tools

7 tools

connect_databaseA

Connect to a SQLite or PostgreSQL database. For SQLite, connection_string can be a file path (e.g. 'dev.db') or ':memory:'. For Postgres, connection_string must be a valid PostgreSQL connection URI. Resolves relative paths for SQLite databases against the current working directory.

ParametersJSON Schema

Name	Required	Description	Default
`db_type`	Yes	The type of database engine.
`connection_string`	Yes	Connection URI or file path to connect to.

TDQS

A4.2/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It discloses path resolution behavior for SQLite but omits other behaviors such as authentication requirements, error handling, connection lifetime, or side effects (e.g., whether it sets a global state). This leaves moderate gaps for a connection 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 concise (two sentences), front-loaded with the main purpose, and every sentence adds necessary detail without extraneous content.

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 only two parameters and no output schema, the description covers key aspects: supported db types, connection string formats, and path resolution. However, it could be more complete by describing the outcome of a connection (e.g., returns a connection ID or sets a global state) or mentioning that subsequent tools require this connection.

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% but the description adds substantial value: it specifies that connection_string content depends on db_type (file path vs URI) and mentions relative path resolution. It goes beyond the schema's generic descriptions.

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 explicitly states the main action: 'Connect to a SQLite or PostgreSQL database.' The resource (database) and the two supported engines are clearly identified, distinguishing it from sibling tools like list_tables or run_query.

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 provides clear usage context: for SQLite, connection_string can be a file path or ':memory:'; for Postgres, it must be a valid URI. It does not explicitly state when not to use it or mention alternatives, but the sibling tools are oriented toward post-connection operations, implying this is a prerequisite.

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

describe_tableA

Retrieve table columns, data types, primary key status, foreign keys, indexes, and a sample of 5 rows.

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	The name of the table to describe.

TDQS

A3.8/5.0

Behavior3/5

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

With no annotations, the description carries the full burden. It explains the output includes sample rows but does not disclose behavioral traits like read-only nature, potential performance impact on large tables, or error behavior for missing tables.

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, well-structured sentence that conveys all necessary information without redundancy. It is front-loaded with the main action ('Retrieve') and lists all output components.

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 simple input (one required parameter) and no output schema, the description covers the expected output well. However, it omits potential error conditions (e.g., table not found, insufficient permissions) and does not mention the time complexity or limits.

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 description coverage is 100% for the single parameter, so the description adds no additional meaning to 'table_name' beyond the schema. The description's list of retrieved items provides context for the overall tool but not for the parameter.

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 retrieves table metadata including columns, data types, primary keys, foreign keys, indexes, and a sample of 5 rows. It differentiates from siblings like 'list_tables' (which lists table names) and 'get_table_stats' (which provides statistics) by specifying the detailed schema information.

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 the tool is for inspecting table schema but does not explicitly state when to use it versus alternatives. No guidance on when not to use or prerequisites (e.g., table must exist).

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

explain_query_planB

Run EXPLAIN on a SQL query to inspect the database execution path.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL query string to analyze.

TDQS

B3.4/5.0

Behavior3/5

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

No annotations provided, so description must carry the burden. Indicates it's for inspection, implying read-only, but doesn't explicitly state it's non-destructive or require permissions. Also doesn't describe return format.

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?

Single sentence, concise and front-loaded. However, could include more context without being 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?

For a simple tool with one parameter and no output schema, the description is adequate but lacks usage guidelines and behavioral details. Not leveraging sibling tool context.

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 parameter 'sql' described. Description adds no extra meaning beyond schema; both say 'SQL query'. Baseline 3 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 uses specific verb 'Run EXPLAIN' and resource 'SQL query', with clear purpose 'to inspect the database execution path'. It distinguishes from sibling tools like run_query which executes the query.

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 on when to use vs alternatives like run_query. Does not mention prerequisites (e.g., database connection) or limitations (e.g., only works with SELECT queries).

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

generate_erdB

Generate a Mermaid.js Entity Relationship Diagram (ERD) based on tables and foreign keys.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

B3.3/5.0

Behavior2/5

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

No annotations provided; description only states the action but doesn't disclose how tables are selected, output format, or side effects. With no annotations, the description should fill this gap but fails to.

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?

Single sentence, concise and front-loaded with the main purpose. Could be slightly more structured but no unnecessary words.

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, no annotations, and the description lacks details on input context (e.g., which database), output format, or how to interpret the result. Incomplete for a tool that presumably operates on a connected database.

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 in schema, so description adds no param meaning. With zero params, baseline is 4 per guidelines; no deduction needed.

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 it generates a Mermaid.js ERD based on tables and foreign keys, distinguishing it from sibling tools like list_tables or describe_table that don't produce diagrams.

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 on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., need a connected database) or when not to use it.

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

get_table_statsA

Profile a table to compute row count, null rates, cardinality, and numeric ranges (min/max/average).

ParametersJSON Schema

Name	Required	Description	Default
`table_name`	Yes	The name of the table to profile.

TDQS

A3.8/5.0

Behavior3/5

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

The description specifies what is computed but omits behavioral traits such as being read-only, potential performance impact (e.g., table scan), or required permissions. With no annotations provided, the description should disclose these to fill the gap.

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, efficient sentence that conveys the tool's purpose and outputs without any extraneous information. Every word earns its place.

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 a single parameter and no output schema, the description adequately states the outputs. However, it does not mention the return format or prerequisites (e.g., table must exist, a database connection must be active), which would improve completeness.

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 covers 'table_name' with a basic description. The tool description adds context by linking the parameter to the profiling action, but since schema coverage is 100%, baseline is 3. The description adds marginal value beyond the schema.

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 ('Profile') and resource ('a table') and explicitly lists the computed statistics (row count, null rates, cardinality, numeric ranges), making the tool's purpose clear and distinct from siblings like describe_table or run_query.

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?

No explicit guidance on when to use this tool versus alternatives, but the implied context (profiling table statistics) differentiates it from siblings. The description could benefit from stating that it is for summary statistics, not for schema or queries.

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 table names and their descriptions in the connected database.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.7/5.0

Behavior3/5

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

With no annotations, the description carries full burden. It discloses the output (names + descriptions) but does not mention potential performance impact, authentication needs, or whether system tables are included. Adequate but minimal.

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?

One sentence, front-loaded with action and resource. No fluff.

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?

Lacks explicit mention that the database must already be connected (prerequisite). Does not clarify if descriptions can be null or if all tables (including views) are listed. Minimal but functional for a simple list tool without output schema.

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 exist, so baseline is 4. The description implicitly confirms no input is needed.

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 exactly states the action (list) and the subject (table names and descriptions) and specifies the scope (in the connected database). It clearly differentiates from sibling tools like describe_table or get_table_stats.

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 on when to use this tool vs alternatives like describe_table. The description does not mention that this is a preparatory step for exploring the database schema, nor does it indicate when it might be inappropriate (e.g., many tables).

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

run_queryA

Execute a SQL query against the database. Checked for safety. Read-only SELECT by default.

ParametersJSON Schema

Name	Required	Description	Default
`sql`	Yes	The SQL query string to run.

TDQS

A3.6/5.0

Behavior3/5

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

Without annotations, the description provides some behavioral context by stating 'checked for safety' and 'read-only SELECT by default,' but does not disclose what happens with non-SELECT queries or error handling, leaving gaps.

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 concise with two sentences, but the second sentence is very short and could be integrated. No wasted words, but not perfectly structured.

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 no output schema, the description omits return value details. It also lacks execution limits or error behavior. For a simple tool with one parameter, it is moderately complete but leaves questions.

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 single parameter 'sql' has a description in the schema ('The SQL query string to run.') and the tool description adds no extra semantics. Schema coverage is 100%, so baseline 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 executes SQL queries against the database, emphasizes safety checks, and specifies read-only SELECT as default. This distinguishes it from sibling tools like list_tables or describe_table.

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 read-only queries but does not explicitly state when to use alternatives like list_tables or describe_table. No when-not-to-use guidance is provided.

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.

7 tool updatesv0.1.0Jun 18, 2026
- First observedconnect_database
- First observeddescribe_table
- First observedexplain_query_plan
- First observedgenerate_erd
- First observedget_table_stats
- First observedlist_tables
- First observedrun_query

Install Server

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

TDQS

A4/5.0

Disambiguation5/5

Each tool has a clearly distinct purpose: connection, schema description, query planning, ERD generation, statistics, table listing, and query execution. There is no overlap between them.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern in snake_case (e.g., connect_database, list_tables, run_query). No deviations or mixed conventions.

Tool Count5/5

Seven tools is well-scoped for a database explorer. Each tool covers a necessary operation without being too few or too many.

Completeness5/5

The tool set covers the full lifecycle of database exploration: connection, listing tables, describing schemas, profiling stats, generating ERDs, explaining query plans, and executing queries. No obvious gaps.

Maintenance

ActivityStale

ResponsivenessNo issues

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

hithereiamaliff-mcp-nextcloudOAuth
ai.smithery
A comprehensive Model Context Protocol (MCP) server that enables AI assistants to interact with yo…
Cloud Storage File Systems Workplace & Productivity
237
mcpOAuth
io.prisma
MCP server for managing Prisma Postgres.
Databases Developer Tools
247
stagenth · 数据工具箱 A
com.stagenth
Query, join, profile, clean and convert CSV/JSON/Parquet with server-side DuckDB over MCP.
Databases Data Platforms File Systems
62
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

Related MCP Servers

MCP Database Server
Databases Cloud Storage Data Platforms
dwarvesf
-
license
Not graded
quality
Not graded
maintenance
A Model Context Protocol server that provides tools for interacting with databases, including PostgreSQL, DuckDB, and Google Cloud Storage Parquet files.
Updated a year ago (2025-04-25 07:14 UTC)
2
-
PostgreSQL Advanced MCP Server
Databases Developer Tools
syahiidkamil
A
license
Not graded
quality
D
maintenance
An enhanced Model Context Protocol server that enables LLMs to inspect database schemas with rich metadata and execute read-only SQL queries with safety checks.
Updated a year ago (2025-05-09 05:33 UTC)
269
25
MIT
QueryCraftMCP
Databases RAG Systems
ratchanonth60
A
license
Not graded
quality
D
maintenance
A flexible Model Context Protocol server that enables LLMs to interact with database systems, supporting dynamic schema discovery and query execution across PostgreSQL and SQLite backends.
Updated a year ago (2025-05-24 17:17 UTC)
2
MIT
PostgreSQL MCP Server
Databases Developer Tools
guibracco
F
license
Not graded
quality
D
maintenance
An MCP server that enables AI assistants to interact with PostgreSQL databases by executing SQL queries and inspecting database schemas. It provides tools for standardized database exploration and management through the Model Context Protocol.
Updated 7 months ago (2026-02-10 08:28 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/arman1o1/mcp-db-explorer'

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