KognitaKognita.
← Back to Overview
Database

Database MCP

Connect one or more databases to your managed Kognita agent so people on your team can ask data questions in plain language, without learning SQL or waiting on an engineer for every lookup.

What this enables

  • Let non-technical users ask operational and product questions against approved database tables
  • Debug production issues with live data context next to the codebase context your agent already has
  • Investigate customer, payment, workflow, or status questions without switching between tools
  • Keep one managed agent connected to both your codebase and the data it needs to verify answers

How it works

You add named database connections. Each one has a connection string containing the host, database name, username, and password, plus guidance that tells the agent what the database is and when to use it. Kognita stores each connection string encrypted and uses it only for the project agent environment tied to your project. Once connected, the managed agent can choose the right database through the MCP configuration and translate plain-language questions into database lookups.

This is especially useful during production debugging. The agent can combine system behavior from the codebase with current database state, so questions like "why did this customer not receive access?" or "which records are stuck in this processing step?" can be answered with evidence instead of guesswork.

Plain-English analytics for approved users

Database MCP is not just for engineers debugging production. It lets approved product, operations, support, finance, and leadership users ask operational analytics questions in natural language while Kognita handles the translation to the right named database connection.

Customer and adoption questions

Ask which customers used a feature, where onboarding is dropping off, or which accounts are stuck in a workflow.

Payment and operational state

Check current status, failed jobs, pending records, or payment-related state without waiting for a custom SQL request.

Leadership reporting

Prepare status, risk, and impact answers from approved data sources without sending every question back through engineering.

Grounded answers with auditability

The managed runtime can combine database evidence with codebase context while preserving query logs and scoped credentials.

Setup guide

1

Create dedicated database users

Create separate database users for Kognita instead of reusing personal or application admin accounts. Give each user access only to the tables or schemas you want the agent to query.

2

Whitelist Kognita egress

Add Kognita's outbound IP to your database firewall, security group, or allowlist before saving the connection in Kognita: 35.254.19.175.

3

Prefer a read-only data source

We recommend connecting a read-only database user to a read replica, analytics database, or other read-only data source. This keeps the agent useful for investigation while reducing the risk of accidental writes or overly broad production access.

4

Prepare each named connection

Give each database a clear name, such as production_read_replica, analytics_warehouse, or billing_db. Then build the connection string. For MySQL, it usually looks like mysql://user:password@db.example.com:3306/database.

Use the dedicated username and password you created for Kognita, not a shared administrator credential.

5

Add it in Kognita

Go to your Kognita dashboard and open the project. Click MCPs, find MCP DB, then click Add database.

Enter the database name, paste the connection string, and add agent guidance. For example:Use this read-only replica for live customer, payment, and production debugging questions.The full connection string is encrypted before saving and is not shown again in the dashboard.

6

Refresh the agent environment

After saving or rotating DB credentials, refresh the project agent runtime from the MCPs panel so the managed agent picks up the latest configuration.

Credential safety

Keep database credentials scoped and rotated. Use a dedicated user, rotate the password regularly, and grant access only to the tables you want Kognita to use. Read-only data sources are strongly recommended for production debugging and plain-language reporting.

Troubleshooting

What should I connect?

Use read replicas, warehouses, or read-only database users whenever possible. Name each connection clearly and explain when the agent should use it.

Can non-technical users query the database?

Yes. The goal of the DB MCP is to let approved users ask plain-language questions while Kognita handles access to the right named database through the managed project agent.

Why not use admin credentials?

Admin credentials usually have broader permissions than the agent needs. A scoped read-only user limits blast radius and makes access easier to audit.