🗄️ Database and API MCPs

The PostgreSQL MCP connects the agent to Postgres databases via a connection string. Tools: query (run SQL), list_tables, describe_table. The agent can analyze schemas, generate reports, debug data, and even suggest indexes.

The configuration passes the connection string as an environment variable: POSTGRES_URL=postgresql://user:pass@host:5432/db. Always prefer read-only access for production environments.

"postgres": {
  "command": "npx",
  "args": ["-y", "@modelcontextprotocol/server-postgres"],
  "env": { "POSTGRES_URL": "postgresql://user:pass@localhost:5432/mydb" }
}

The Redis MCP exposes cache and key-value operations: get, set, keys, ttl, del. Useful for debugging cache, checking queues, and monitoring application status in real time.

Connection via REDIS_URL: redis://localhost:6379. The agent can inspect keys, check TTLs, and even clear the cache on demand.

The HTTP MCP is a generic connector for any REST API. You configure the base URL and auth headers, and the agent can make GET, POST, PUT, and DELETE requests to any endpoint. It's the Swiss Army knife of MCPs.

Each operation becomes a tool with parameters for path, query params, headers, and body. Ideal for connecting internal services that don't have a dedicated MCP.

If your API is GraphQL, this MCP lets you run queries and mutations directly. The agent uses introspection to understand the schema and automatically build appropriate queries.

The configuration needs the GraphQL endpoint and optionally auth headers. The agent can explore the schema, list types, and run complex operations with variables.

Connecting MCPs to local services is easy. The challenge is connecting to real-world environments: staging, production. Common patterns: SSH tunnels for remote databases, project-specific env configs (local vs. global settings.json), and connection pools to avoid overload.

Golden rule: never give production write access via MCP without supervision. Use read-only for queries and analysis; use write only in staging or with an approval flow.

MCPs with access to DBs and APIs need credentials: connection strings, tokens, passwords. These credentials are stored in settings.json or environment variables. The risk: if settings.json is committed to git, the credentials leak.

Best practices: (1) use env in settings.json instead of hardcoding in the args, (2) add .claude/settings.json to .gitignore, (3) for teams, use a secret manager and reference shell variables.

# Never commit settings with credentials
.claude/settings.json
.env
.env.local