Provides tools for querying, inspecting, and managing local PostgreSQL databases, including read-only SELECT queries, listing schemas and tables, describing table columns and constraints, and optionally executing write or DDL statements when enabled.
Bridge your AI assistant to local PostgreSQL databases — query, inspect, and manage data without cloud dependencies.
uvx airgap-db-bridgeRelated MCP server: mcpgov
pip install airgap-db-bridgeairgap-db-bridgeWindows (requires full path to executable):
{
"mcpServers": {
"database": {
"command": "C:\Users\<user>\AppData\Local\hermes\hermes-agent\venv\Scripts\airgap-db-bridge.exe",
"env": {
"POSTGRES_DSN": "postgresql://user:pass@localhost:5432/db"
}
}
}
}macOS/Linux (if on PATH):
{
"mcpServers": {
"database": {
"command": "airgap-db-bridge",
"env": {
"POSTGRES_DSN": "postgresql://user:pass@localhost:5432/db"
}
}
}
}Download airgap-db-bridge-1.0.0.dxt from Releases → drag into Claude Desktop.
Environment Variable | Default | Description |
| Required | PostgreSQL connection string (e.g., |
| 1000 | Max rows returned per query |
| 30000 | Query timeout in ms |
| false | Allow CREATE/ALTER/DROP statements |
| false | Allow INSERT/UPDATE/DELETE |
Tool | Description |
| Execute a read-only SELECT query |
| Execute a write query (requires |
| List all tables in the database |
| Show columns, types, constraints for a table |
| List all schemas in the database |
stdio (default) — For local MCP clients (Claude Desktop, etc.)
sse — Server-Sent Events for HTTP clients
http — Streamable HTTP for modern clients
Set via DB_BRIDGE_TRANSPORT environment variable.
The executable is installed to C:\Users\<user>\AppData\Local\hermes\hermes-agent\venv\Scripts\airgap-db-bridge.exe when using Hermes
Always use the full .exe path in MCP client configs on Windows — bare commands like airgap-db-bridge will fail with ENOENT because the venv Scripts folder is not on system PATH
Use standard PostgreSQL DSN format in environment variables
Escape backslashes in JSON command paths (C:\Users\...)
Local-first — Your data never leaves your machine
Air-gapped ready — No cloud dependencies, works offline
Security hardened — Read-only by default, optional write/DDL gates, row limits, statement timeouts
Multiple transports — stdio, SSE, Streamable HTTP
PostgreSQL native — Full protocol support, prepared statements, connection pooling
uvx compatible — Zero-install usage like the competition
# Install with dev dependencies
pip install -e ".[dev]"
# Run tests
uv run pytest -v
# Check code quality
uv run ruff check .
uv run mypy .MIT
Describe a table's structure including columns, indexes, and constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| table | Yes | Table name to describe | |
| schema | No | Schema name containing the table (default: "public") | public |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. 'Describe' implies a read-only operation and the output content is usefully specified, but the description does not address error behavior, permission requirements, or limits such as whether views are included. It adds some transparency but leaves behavioral gaps.
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?
A single, front-loaded sentence with no filler. Every phrase earns its place by specifying the operation and its core output elements.
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 two-parameter tool with an output schema, the description adequately covers purpose and gives a concise preview of returned information. It lacks explicit sibling differentiation and read-only confirmation, but nothing critical is missing for correct invocation.
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 the input schema already documents both parameters (table and schema). The description adds no parameter-specific meaning beyond what the schema provides, 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 'Describe' with a clear resource ('a table's structure') and lists concrete components (columns, indexes, constraints). This makes it immediately distinguishable from siblings like query, list_tables, and explain_analyze.
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?
Usage is implied by the description—use it when you need structural metadata about a table—but there is no explicit guidance on when to prefer it over alternatives or when not to use it. The sibling names provide context, but the description itself offers no routing hints.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a parameterized INSERT, UPDATE, or DELETE statement.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Parameterized DML SQL statement (use $1, $2, etc. for parameters) | |
| params | No | Optional list of statement parameters |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
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 states that the tool executes DML statements, which implies a write/update behavior, but does not disclose side effects such as whether changes are committed automatically, whether transactions are supported, or what happens on failure. It also does not clarify if SELECT is prohibited, which is a notable behavioral gap.
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 that efficiently conveys the core purpose. It avoids unnecessary jargon and front-loads the verb. It is not overly verbose, but it lacks additional context that could be valuable.
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?
With no annotations and an output schema present but not described, the description leaves important gaps: it does not explain the return value, error behavior, or transaction semantics. For a DML execution tool, these are critical for safe invocation. The description is minimal and does not fully cover what an agent needs to know.
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 the parameters 'sql' and 'params' are fully documented in the schema. The description adds minimal semantic value beyond naming the statement types, but it does reinforce the parameterized nature. The baseline of 3 is appropriate since the schema carries the 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 'Execute a parameterized INSERT, UPDATE, or DELETE statement' clearly identifies the operation type (DML execution) and the resource (SQL statements). It is specific about the allowed statement types, which helps distinguish it from generic 'execute' tools. However, it does not explicitly contrast with sibling tools or mention any read-only query capability, leaving slight ambiguity in broader contexts.
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 usage for DML operations but does not explicitly state when to use this tool versus alternatives (e.g., a dedicated query tool for SELECT). It lists the supported statement types, which gives some context, but lacks explicit exclusions or alternative tool references. The agent must infer that SELECT statements are not intended here.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get query execution plan with costs using EXPLAIN ANALYZE.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Parameterized SQL query to analyze (use $1, $2, etc. for parameters) | |
| params | No | Optional list of query parameters |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
There are no annotations, so the description carries the full behavioral burden. It does disclose that the tool uses EXPLAIN ANALYZE and reports costs, which is meaningful. However, it does not warn that EXPLAIN ANALYZE actually executes the query, which could be important for safety and side effects.
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 front-loaded sentence with no redundancy or filler. It states the purpose and mechanism in the fewest words needed.
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 output schema and parameter schema cover return values and arguments, which reduces the burden on the description. Still, the description lacks explicit when-to-use guidance and any caveat about EXPLAIN ANALYZE executing the query, so it is not fully complete for safe and correct invocation.
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 sql and params are already well documented in the input schema. The description adds no extra parameter-level meaning beyond restating that the query will be analyzed, 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 states a specific verb ('Get'), a concrete resource ('query execution plan with costs'), and the mechanism ('EXPLAIN ANALYZE'). This clearly distinguishes it from sibling tools like query and execute, which return results rather than plans.
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 tool is for performance analysis and execution plans, not for retrieving query results. However, it never explicitly says when to choose this over query or execute, and it gives no exclusions or alternative guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all tables in a schema.
| Name | Required | Description | Default |
|---|---|---|---|
| schema | No | Schema name to list tables from (default: "public") | public |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. 'List all tables' transparently implies a read-only enumeration with no destructive side effects, but it does not disclose whether system tables are included, how a missing schema is handled, or whether special permissions are required.
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, front-loaded sentence with no filler. Every word contributes to the action ('List') and the scope ('all tables in a schema').
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 one-parameter, read-only listing tool with an output schema, the description is nearly complete: it names the object and scope, and the schema documents the parameter default. The main gaps are explicit sibling routing and edge-case behavior, which are minor for this simple operation.
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 100% description coverage for the single parameter, including the default value for schema. The description adds no parameter-level detail, but none is needed because the schema already supplies the semantics.
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 and resource: 'List all tables in a schema.' It clearly communicates the tool's function and scope, though it does not explicitly distinguish it from sibling tools such as describe_table or query.
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 explicit guidance on when to use this tool instead of query, execute, or describe_table, and no exclusions or prerequisites are mentioned. The intended usage is only implied by the word 'List,' with no routing context for alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Execute a parameterized SELECT query and return rows.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Parameterized SELECT SQL query (use $1, $2, etc. for parameters) | |
| params | No | Optional list of query parameters |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral disclosure burden. It clearly states that the tool executes a SELECT query and returns rows, which communicates the core read-only behavior. It does not mention limits or edge cases, but the SELECT restriction makes the primary safety profile clear.
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 every word contributing meaning. It is front-loaded with the action and resource, and the return behavior is stated clearly without redundancy.
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 SELECT query tool, the description is nearly complete. The schema covers parameters fully and an output schema exists to describe return values. The only meaningful gap is the lack of guidance about when to prefer 'query' over sibling tools, but the SELECT qualifier mitigates this.
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 baseline is 3. The description adds only the word 'parameterized', which is already captured in the schema's sql parameter description. It does not provide additional semantic value beyond what the schema already documents.
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 specific verb-resource pairing: 'Execute a parameterized SELECT query and return rows.' The SELECT qualifier distinguishes it from general execution tools like 'execute', though it does not explicitly name sibling tools.
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 guidance is given about when to use this tool versus alternatives like 'execute' or 'explain_analyze'. The only implicit signal is that SELECT queries belong here, but there is no explicit when-to-use or when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Run a database migration (DDL statements) in a transaction.
| Name | Required | Description | Default |
|---|---|---|---|
| sql | Yes | Migration SQL containing one or more DDL statements separated by semicolons |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses that the operation runs DDL inside a transaction, which is meaningful behavioral context. It does not mention what happens on failure, whether partial changes can be rolled back, or that DDL is inherently schema-modifying, so some burden falls on the agent despite the transaction note.
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 wasted words. It front-loads the action and object, then adds the key transaction qualifier.
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 an output schema, the description is close to adequate. The main gaps are the lack of explicit guidance versus execute and the absence of failure/rollback semantics, which matter for a DDL mutation tool.
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 schema covers the single parameter fully with a clear description, and the tool description adds little beyond the existing schema text. The phrase 'in a transaction' adds execution context, but it does not meaningfully expand the parameter's meaning.
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 a specific verb ('Run') and a specific resource ('a database migration'), and clarifies these are DDL statements. It distinguishes the tool from read-oriented siblings like query, list_tables, and describe_table, though it does not explicitly contrast it with execute.
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 the tool is for DDL migrations and mentions transactional execution, which gives useful context. However, it never explicitly says when to prefer this over execute or when not to use it, leaving the routing decision to inference.
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. Dates show when Glama detected each change.
v1.0.3describe_tableexecuteexplain_analyzelist_tablesqueryrun_migrationEach tool has a clearly distinct role: query for SELECT, execute for DML, run_migration for DDL, explain_analyze for query plans, and list_tables/describe_table for schema inspection. There is no meaningful overlap that would confuse an agent selecting among them.
Most tools follow a clear verb_noun pattern, such as list_tables, describe_table, and run_migration. The bare verb tools query and execute break the pattern slightly, but they are standard database terms and remain predictable in context.
The 6-tool surface is well-scoped for a database bridge: it covers queries, changes, schema introspection, migration, and performance analysis without unnecessary duplication. Each tool serves a meaningful purpose.
The set covers the core lifecycle of database interaction: read, write, schema inspection, DDL changes, and query analysis. Minor gaps exist, such as no explicit transaction control for arbitrary DML batches or no tool for managing connections, but these are reasonable workarounds.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Safe, read-only Postgres and MySQL access for AI agents. Audit log + column-level controls.
Read-only PostgreSQL, MySQL, SQL Server access via MCP — 24 dialect-aware hosted tools.
Hosted MCP server for PostgreSQL diagnostics: slow queries, missing indexes, connection pressure.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Airgap-fleet/db-bridge'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
