Enables database interaction via natural language within GitHub Copilot Agent mode.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@mcp-db-universal What are the top 5 best-selling products?"
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.
A database-agnostic MCP (Model Context Protocol) server that lets you chat with your database through Claude or GitHub Copilot. Ask questions in plain English and the AI will write and execute the SQL for you.
Database | Driver | Install |
PostgreSQL |
|
|
MySQL |
|
|
SQL Server |
|
|
SQLite |
|
|
Oracle |
|
|
Related MCP server: nl2sql-mcp
This tool runs on Node.js. If you don't have it installed, do that first:
Go to nodejs.org and download the LTS version (recommended for most users)
Run the installer and follow the prompts
Once installed, open a terminal (Command Prompt / PowerShell on Windows, Terminal on macOS/Linux) and verify it worked:
node --version # should print something like v20.x.x
npm --version # should print something like 10.x.xIf both commands return version numbers, you're good to go
npm install -g fm-db-mcp-universal
# Then install your DB driver:
npm install -g pg # PostgreSQL
npm install -g mysql2 # MySQL
npm install -g mssql tedious # SQL Server
npm install -g better-sqlite3 # SQLite
npm install -g oracledb # OracleEdit ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) or C:\Users\<username>\AppData\Roaming\Claude\claude_desktop_config.json (Windows):
{
"mcpServers": {
"my-db": {
"command": "npx",
"args": ["fm-db-mcp-universal"],
"env": {
"DB_CLIENT": "oracle",
"DB_HOST": "localhost",
"DB_PORT": "1521",
"DB_NAME": "orcl",
"DB_USER": "xxx",
"DB_PASSWORD": "xxx"
}
}
}
}Create .vscode/mcp.json in your workspace:
{
"servers": {
"oracle-db": {
"command": "npx",
"args": [
"fm-db-mcp-universal"
],
"env": {
"DB_CLIENT": "oracle",
"DB_HOST": "localhost",
"DB_PORT": "1521",
"DB_NAME": "orcl",
"DB_USER": "FMCPROD1",
"DB_PASSWORD": "FMCPROD1"
}
},
"postgres-db": {
"command": "npx",
"args": [
"fm-db-mcp-universal"
],
"env": {
"DB_CLIENT": "postgres",
"DB_HOST": "localhost",
"DB_PORT": "5432",
"DB_USER": "postgres",
"DB_PASSWORD": "password",
"DB_NAME": "postgres"
}
},
"mssql-db": {
"command": "npx",
"args": [
"fm-db-mcp-universal"
],
"env": {
"DB_CLIENT": "mssql",
"DB_HOST": "localhost",
"DB_PORT": "1433",
"DB_USER": "sa",
"DB_PASSWORD": "sadmin",
"DB_NAME": "ALLMERGE"
}
},
}
}All configuration is via environment variables:
Variable | Description | Default |
| Database type: |
|
| Database host |
|
| Database port (auto-detected if not set) | per DB |
| Username | — |
| Password | — |
| Database name | — |
| File path (SQLite only) | — |
| Full connection string (overrides above) | — |
| Set |
|
| Connection pool minimum |
|
| Connection pool maximum |
|
{
"env": {
"DB_CLIENT": "postgres",
"DB_CONNECTION_STRING": "postgresql://user:pass@localhost:5432/mydb"
}
}{
"DB_CLIENT": "postgres",
"DB_HOST": "localhost",
"DB_USER": "postgres",
"DB_PASSWORD": "secret",
"DB_NAME": "myapp"
}{
"DB_CLIENT": "mysql",
"DB_HOST": "localhost",
"DB_USER": "root",
"DB_PASSWORD": "secret",
"DB_NAME": "myapp"
}{
"DB_CLIENT": "mssql",
"DB_HOST": "localhost",
"DB_PORT": "1433",
"DB_USER": "sa",
"DB_PASSWORD": "YourPassword123!",
"DB_NAME": "Northwind"
}{
"DB_CLIENT": "sqlite",
"DB_FILENAME": "/path/to/database.db"
}{
"DB_CLIENT": "oracle",
"DB_HOST": "localhost",
"DB_PORT": "1521",
"DB_USER": "myuser",
"DB_PASSWORD": "mypassword",
"DB_NAME": "ORCL"
}Tool | Description |
| Test connection and confirm it's working |
| Run a SELECT query (read-only, auto-limited to 100 rows) |
| Run INSERT/UPDATE/DELETE/DDL (disabled in read-only mode) |
| List all tables and views |
| Get columns, types, nullability for a table |
| Get index information for a table |
| Get foreign key relationships for a table |
| Full schema dump of all tables at once |
Once connected, just talk naturally:
"What tables do I have?" → Calls
db_list_tables
"Show me all users who signed up in the last 30 days" → Writes and executes a SELECT with date filter
"How many orders are in 'pending' status?" → COUNT query
"What's the schema of the orders table?" → Calls
db_describe_table
"Add an index on users.email" → Calls
db_executewith CREATE INDEX statement
"Give me a summary of sales by region this year" → GROUP BY query with aggregation
To protect production databases, enable read-only mode:
{
"env": {
"DB_READONLY": "true",
...
}
}In read-only mode, db_execute is disabled — only SELECT queries are allowed.
git clone https://github.com/yourname/mcp-db-universal
cd mcp-db-universal
npm install
npm install better-sqlite3 # or your DB driver
npm run buildThen configure Claude/Copilot to use:
{
"command": "node",
"args": ["/path/to/mcp-db-universal/dist/index.js"],
"env": { ... }
}Or run directly in dev mode:
DB_CLIENT=sqlite DB_FILENAME=./test.db npm run devnpm run build
npm publishUsers can then use npx:
{
"command": "npx",
"args": ["mcp-db-universal"],
"env": { ... }
}MIT
Get the schema of a table: columns, types, nullability, defaults
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full burden of behavioral disclosure. 'Get' strongly implies a non-mutating read, and listing the returned schema elements adds useful context. Still, it does not explicitly state that no data is modified, what happens for missing tables, or whether authorization is needed beyond the given table name.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One concise sentence that front-loads the operation and immediately lists the key output components. Every word earns its place with no filler or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple single-parameter introspection tool, the description provides enough to call it correctly and understand the expected result. It lacks explicit edge-case behavior, such as errors for nonexistent tables, but the low complexity and complete parameter documentation keep this from being a significant gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, with the only parameter described as 'Table name', so the baseline is 3. The description adds minimal semantic value by clarifying that the table's schema is being retrieved, but it does not specify details like schema qualification, quoting, or case sensitivity.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description uses a specific verb ('Get') and resource ('schema of a table') and enumerates the exact content (columns, types, nullability, defaults). This distinguishes it from siblings like db_list_tables, db_table_indexes, and db_foreign_keys, which target different aspects or scopes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies this is the tool to use when you need the column-level schema of a single table, rather than listing tables, querying data, or inspecting indexes. However, it does not explicitly state when to prefer it over db_schema_snapshot or the more specialized schema tools, nor does it mention exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a write SQL statement: INSERT, UPDATE, DELETE, CREATE, ALTER, DROP. Disabled in read-only mode.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | SQL statement to execute |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the behavioral disclosure burden. It does disclose that the tool performs writes and is disabled in read-only mode, and it lists potentially destructive statements like DROP. However, it does not warn about irreversibility, side effects, or what happens on execution.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
One compact sentence conveys the tool's purpose, the allowed statement types, and an important runtime constraint. No filler or redundant phrasing.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple one-parameter tool with no output schema, the description is largely complete: it tells the agent what kind of SQL is allowed and when the tool is unavailable. It could mention return behavior (e.g., affected rows or errors), but the core invocation context is fully covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so the schema already documents the 'sql' parameter. The description adds useful context by limiting execution to write statements, but it does not provide parameter-specific details beyond what the schema conveys.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb ('Execute') and a clear resource ('a write SQL statement'), enumerating exact statement types (INSERT, UPDATE, DELETE, CREATE, ALTER, DROP). This clearly differentiates it from sibling tools like db_query, which handles reads.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description makes clear this tool is for write statements only, which implies it should not be used for SELECT queries (where db_query would be appropriate). It also notes it is disabled in read-only mode, giving useful context, but it does not explicitly name the alternative read tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get foreign key relationships for a table
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name |
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 only restates the operation implied by the name and gives no detail on read-only guarantees, error behavior, or what happens for nonexistent tables. 'Get' weakly suggests read-only, but nothing beyond that.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler or redundancy. It states the resource and the table target directly, which is appropriate for a one-parameter metadata tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and the parameter is fully covered by the schema, but there is no output schema or annotations to fill in missing context. The description does not indicate return shape, whether the table name must be schema-qualified, or what occurs when no foreign keys exist. It is minimally viable but not fully complete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%: the only parameter, 'table', is described as 'Table name'. The description adds no extra meaning about naming conventions, qualification, or accepted formats, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a well-scoped resource ('foreign key relationships for a table'). It is clearly distinct from siblings like db_table_indexes and db_describe_table, so an agent can tell what this tool targets without opening the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when foreign key relationships are needed, but it gives no explicit guidance about when to prefer this tool over alternatives such as db_describe_table or db_table_indexes. No exclusions or routing conditions are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables and views in the database
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the disclosure burden. It clarifies that both tables and views are included and implies a read-only listing, but it does not describe output shape, ordering, schema qualification, or whether system objects are returned.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, focused sentence with no wasted words. It front-loads the core operation and scope effectively.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple zero-parameter listing tool, the description is nearly complete and callable. The only notable gaps are lack of contrast with db_schema_snapshot and no statement of the return format, both relatively minor for this use case.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so there is no parameter meaning for the description to clarify. The baseline of 4 for a zero-parameter tool applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and a clear resource ('all tables and views in the database'), making the tool's scope unambiguous. It is easy to distinguish from siblings like db_query, db_execute, db_table_indexes, and db_foreign_keys, which target different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No explicit when-to-use or alternative routing is provided, but the purpose is self-evident: an agent can infer this tool is for enumerating tables and views. It does not distinguish itself from db_schema_snapshot, leaving some ambiguity about which listing tool to choose.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Test the database connection and return connection info
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. It indicates the tool is non-mutating and returns connection info, which is helpful, but it does not describe the exact shape or contents of the returned info.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. The core action and return value are front-loaded, making it immediately scannable.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter tool, the description is largely complete: it names the action and the expected output. The main gap is the lack of detail about what 'connection info' includes, but this is a minor omission given the tool's simplicity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 document. Description adds no parameter details, which is appropriate given the empty input schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action 'test the database connection' and what it returns ('connection info'), with a specific verb and resource. It is easily distinguished from sibling tools like db_query or db_execute, which perform different operations.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'test the database connection' provides clear context for when to use this tool: as a connectivity/health check. It does not explicitly exclude alternatives, but the zero-parameter interface and unique purpose make the usage context evident.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a SELECT SQL query and return results. Use this for all read operations.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | A SELECT SQL query. Must be a read-only statement. | |
| limit | No | Max rows to return (default 100, max 1000) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description itself signals safe read-only behavior by restricting to SELECT and read operations. However, it adds little beyond that—no mention of side-effect absence, limit enforcement, timeout, or error behavior—so the burden is only partially met.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two concise sentences front-load the action and scope. No filler, though the space could have been used to mention the write alternative.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Adequate for a simple SELECT tool, but leaves selection nuance to inference: it does not explicitly distinguish db_query from db_execute or specialized read-only metadata tools. The return value is only described generically as 'results.'
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so both parameters are already documented. The description adds no parameter-level detail beyond what the schema provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: 'Execute a SELECT SQL query and return results.' It also explicitly classifies the tool as the read-operation entry point, which distinguishes it from write and utility siblings.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives clear invocation context: 'Use this for all read operations.' It does not explicitly name db_execute as the write counterpart or specialized metadata tools as alternatives, so it stops short of full exclusion guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get a full schema snapshot of all tables and their columns. Useful for understanding the entire DB structure at once.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description itself signals a read-only operation via 'Get' and 'snapshot', which is reasonable behavioral context. It does not mention potential performance cost, output size, or whether the snapshot includes indexes/views/foreign keys, so some burden remains unmet.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two short sentences with no filler. The core action and scope are front-loaded, and the use-case sentence earns its place by guiding selection.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter introspection tool, the description is largely complete: it states what is returned and when it is useful. It could be slightly richer by clarifying what is not included (e.g., indexes, foreign keys), but the sibling tool names help fill that gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero properties, so there are no parameters to document. The baseline for a zero-parameter tool is 4, and the description does not need to compensate for any missing parameter details.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and a clear resource ('full schema snapshot of all tables and their columns'). It clearly distinguishes itself from siblings like db_describe_table, which would describe a single table, and db_list_tables, which would only list table names.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'Useful for understanding the entire DB structure at once' provides a clear context for when to use this tool versus more targeted schema tools. However, it does not explicitly mention alternatives or exclusion criteria, which leaves some inference to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get indexes for a table
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full behavioral burden. The verb 'Get' implies a read-only lookup, which is useful, but the description does not disclose error behavior, whether primary keys are included, or how the index data is structured. Basic transparency exists, but it is minimal.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler, redundant phrasing, or unnecessary detail. It is front-loaded and immediately communicates the tool's function.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one required parameter, but there is no output schema and no mention of what the returned index information includes. An agent can invoke it correctly, but the ambiguity around the return value format keeps this at a minimum-viable level.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents the only parameter 'table' as 'Table name', with 100% schema description coverage. The description adds no extra parameter detail beyond contextually implying that the table is the target of the index lookup, so 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.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Get') and resource ('indexes for a table'), which clearly distinguishes it from siblings like db_list_tables, db_describe_table, and db_foreign_keys. Even without naming alternatives, the purpose is unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no guidance about when to use this tool versus the available siblings. It does not mention that db_describe_table covers table structure, db_foreign_keys covers relations, or any condition that would make db_table_indexes the preferred choice.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v1.0.0db_describe_tabledb_executedb_foreign_keysdb_list_tablesdb_pingdb_querydb_schema_snapshotdb_table_indexesScored across 8 tools
Most tools are clearly distinct: ping, query, execute, and metadata operations each have a clear purpose. There is minor overlap between list_tables and schema_snapshot, but the descriptions clarify that one returns only table names while the other returns full column-level detail.
All tools share the db_ prefix and use snake_case, which is good, but the pattern is mixed: some are verb_noun (list_tables, describe_table), some are verb-only (ping, query, execute), and some are noun-only (table_indexes, foreign_keys, schema_snapshot). This is readable but not a consistent verb_noun convention.
Eight tools is a well-scoped size for a universal database server. Each tool covers a distinct need: connection testing, read/write SQL execution, and schema/table metadata exploration.
The tool set covers the full database lifecycle: connect, inspect available tables, view schema details, query data, and execute writes and DDL. The generic db_query and db_execute tools avoid dead ends for read and write operations.
GibsonAI MCP server: manage your databases with natural language
Query your warehouse or a CSV with Claude/ChatGPT over MCP, governed by table-level ACL + audit.
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
Analytical memory for AI agents: a real Postgres queried in plain English over MCP. One command.
