Skip to main content
Glama
Sign In
db-conn-mcp

db-conn-mcp

by Idle-Sync
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

doctor

Diagnose MCP database setups when connectivity checks miss the cause: scan processes, package updates, config typos, secret permissions, client paths, and per-database access for actionable fixes.

Instructions

Diagnose the whole setup, not just connectivity — use when something is misbehaving and check_database alone doesn't explain why.

Runs every diagnostic: stale running server processes, newer PyPI release, connections.json key typos/types, secrets exposure (permissions, git), MCP client entries pointing at dead paths, and per-database connectivity with a credential-free fallback-port identity probe. Returns findings as {check, status: ok|warn|fail|skipped, detail, suggested_action} where suggested_action is machine-actionable: reconnect_client, upgrade_package, swap_primary_port, fix_permissions, fix_config, repair_client_config, fix_connection, install_doctor_extra, run_setup, report_bug, or none — every finding that states a remedy names one. Fix what you can; report the rest to the user verbatim. Output is sanitized — never contains DSNs, hosts, or credentials. offline=true skips the PyPI lookup.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "doctor"
  }
}

Input Schema

NameRequiredDescriptionDefault
offlineNo

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

No annotations are supplied, so the description carries the full burden and largely meets it: it discloses the full check inventory, the sanitization guarantee ('never contains DSNs, hosts, or credentials'), the offline switch behavior, and a closed enumeration of suggested_action values. The one gap is that it never states whether the tool itself mutates anything or only reports, leaving 'Fix what you can' to be inferred as the agent's job rather than the tool's.

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?

Front-loaded with purpose and trigger, then a compact inventory of checks, then the result contract and remedy vocabulary. Every clause carries decision-relevant information: the check list justifies the cost of the call, and the suggested_action enumeration tells the agent what it can act on automatically.

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?

For a read-only aggregate diagnostic with an output schema already present, the definition supplies everything else an agent needs: when to prefer it over check_database, what it inspects, the finding shape, the sanitization guarantee, and the actionable remedy set. Nothing required to invoke it correctly or interpret its results is missing.

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 0% and the single parameter has no description in the schema, so the description must compensate — and it does, explaining that 'offline=true skips the PyPI lookup', which is the only meaningful semantic of the flag. It omits the default value and any note that offline still runs all other checks, keeping it just short of a full specification.

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?

Opens with a specific verb and scope: 'Diagnose the whole setup, not just connectivity', and explicitly contrasts that scope with check_database. It then enumerates the concrete checks performed (stale processes, PyPI release, connections.json key typos, secrets exposure, MCP client entries, per-database connectivity), so an agent can distinguish it from every sibling in one read.

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

Usage Guidelines5/5

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

States an explicit trigger ('use when something is misbehaving and check_database alone doesn't explain why') and names the alternative that is insufficient, which is exactly the selection rule an agent needs. It also gives post-invocation guidance — 'Fix what you can; report the rest to the user verbatim' — closing the loop on what to do with results.

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

This server cannot be deployed

Other Tools