Role-based MCP database access: one AI tool catalog should not fit every workflow

The universal tool catalog is where governance starts to leak

It is tempting to expose one MCP database server with one tool catalog and let every AI workflow use it. One catalog is easier to set up. It is also easier to misuse.

Finance, customer support, engineering, and operations do not need the same database surface. They may ask questions about the same product, but the allowed data, row scope, columns, freshness requirements, and audit expectations are different.

If every role gets the same tools, the model has to remember the boundary. That is not governance. That is a prompt asking nicely.

Roles should shape tools, not just prompts

Role-based MCP database access means the available tools change based on the workflow and the authenticated user. A support workflow might need account status and recent ticket context. Finance might need invoices and revenue summaries. Engineering might need operational diagnostics. Those should not be the same tool.

The boundary belongs in the access layer:

• Which tools are visible?
• Which views can those tools query?
• Which rows are in scope?
• Which columns are redacted?
• Which queries require approval or should fail closed?

This is the same idea behind least-privilege tool catalogs, but applied at the role and workflow level.

Example: one question, four different boundaries

Take a simple question: “Why did this customer’s usage drop?”

For customer success, the useful answer might include account activity, login trends, onboarding milestones, and open support tickets.

For finance, the same customer might be visible only through subscription status, plan, renewal date, and invoicing state.

For engineering, the relevant data might be failed jobs, latency, integration errors, and deployment windows.

For an executive summary, the answer might need only a high-level risk reason and next action, not raw identifiers or operational logs.

A single broad query tool can technically answer all four. A role-based MCP catalog makes sure each workflow sees only the version it should see.

Approved views are the simplest place to start

You do not need a complicated policy engine on day one. Start by creating approved views for each workflow and exposing MCP tools around those views.

• cs_account_health_summary for customer success.
• finance_revenue_snapshot for finance.
• ops_integration_errors for operations.
• exec_customer_risk_summary for leadership summaries.

Each view can encode joins, redaction, tenant filters, and metric definitions. Then the MCP server exposes tools like get_account_health or get_revenue_snapshot instead of a generic “run SQL” tool.

That gives the model less room to improvise and the team more confidence about what can happen.

Read-only is necessary, not sufficient

Read-only access prevents writes. It does not automatically prevent overbroad reads.

A read-only credential can still expose the wrong tenant, return sensitive columns, scan too many rows, or give a workflow data it has no business seeing. Role-based access narrows that surface before the model receives any result.

For production systems, combine read-only access with:

• Scoped credentials per datasource or workflow.
• Approved views instead of raw tables.
• Column redaction before model context.
• Row-level security where tenant boundaries matter.
• Query budgets and row limits.
• Audit logs per user, role, tool, and result shape.

See read-only ChatGPT to PostgreSQL access for the safer default, and Conexor security for the broader security model.

Audit logs should include the role boundary

When an AI answer affects a customer conversation, a renewal review, or an operational decision, the log should explain more than the query text.

Useful audit records include:

• The authenticated user.
• The active role or workflow.
• The MCP tool name.
• The approved view or datasource used.
• The parameters and row count.
• The policy decision that allowed or denied the request.

That makes it possible to answer a simple governance question later: did this user get this answer through the right boundary?

Where Conexor fits

Conexor is MCP infrastructure for controlled database and API access from AI clients. For role-based database workflows, the important design choice is to keep the tool surface small and intentional.

Instead of asking one universal database tool to serve every team, create a catalog of approved tools that match the way people actually work. Customer success gets account health. Finance gets revenue snapshots. Operations gets integration status. Engineering gets diagnostics.

The AI still feels useful. The access model finally matches the organization.

The practical rule

If two teams would not get the same dashboard, they probably should not get the same MCP database tools.

Start with role-based tool catalogs, approved views, scoped credentials, and audit logs. Then let the model answer questions inside those boundaries instead of trusting it to remember them.

For related implementation patterns, read the MCP database tool allowlist guide and the MCP server setup page.