Database MCP Tool Rules

Safe Starting Point

Expose one or two bounded read tools first. Add result limits and require exact IDs where the tool schema supports them.

Good first reads:

• read one customer summary by customer_id
• list open cases for one customer
• list recent orders for one customer
• read metadata that does not expose large freeform text

Keep raw SQL, delete, bulk update, schema mutation, export, and admin tools hidden or blocked.

Tool Surface Overview

Prefer bounded business tools:

• get_customer_summary
• list_open_support_cases
• list_recent_orders
• create_internal_ticket
• update_customer_status

Avoid exposing raw database tools:

• raw SQL
• arbitrary query execution
• schema mutation
• bulk update
• delete
• export
• admin tools

If the server exposes both bounded business tools and raw SQL, hide or block the raw tools.

Write-Like Tools

Medium-risk writes can be useful when they are tightly scoped:

• create one internal ticket for the reviewed customer
• update one status field on the reviewed customer
• add one note to the reviewed case

These should bind to the exact record ID. If the write depends on previously read state, also require a version, timestamp, or hash match.

High-Risk Actions

Block or hide:

• delete customer
• delete order
• bulk update
• raw SQL
• schema migration
• export all rows
• cross-customer write
• admin permission change

Do not rely on an agent prompt to prevent these actions. Keep them outside the normal tool surface.

Good Bindings

Strong database bindings:

• customer_id
• record_id
• case_id
• tenant or account id
• version
• updated_at
• etag
• state_hash

For stale-state binding, the read result should expose a field that can prove the record has not changed since the read. A version or state_hash is usually stronger than display text.

Weak Bindings To Avoid

Avoid relying only on:

• customer name
• email address if not unique
• table row position
• "the selected customer"
• search result order
• freeform SQL text
• a natural-language summary

These can collide, drift, or be misunderstood.

Example Rule Configs

Read And Record Bounded State

Use this when a later write should refer back to the exact customer state the agent just read.

The agent can see and call get_customer_summary. MCP Boundary allows the read, limits the result, and records selected facts for a short time. This does not make every later write safe; it only creates a bounded observation.

Require The Later Write To Reference The Observed Record

Use this when a status update should not be normal automatic work unless it matches the observed customer resource and state.

The agent can see the update tool, but the call is review_required. The state_binding fields require the later write to reference the observed customer and state hash. This does not provide a dashboard approval queue in the current release.

Keep Raw SQL Blocked

Use this for raw query tools or command-like database tools.

The agent cannot see execute_sql as a normal tool, and MCP Boundary blocks it before downstream execution through this path. This does not make arbitrary SQL safe; it keeps raw SQL outside the normal agent surface.

If you later change a state-bound write from review_required to allow, test both paths:

• matching state hash allows exactly the intended record update
• mismatched state hash does not dispatch the update

Demo Walkthrough

Good database walkthrough:

• Read customer C-1002.
• Show the recorded observation with status/version facts.
• Attempt an update with the correct customer and matching state.
• Attempt a cross-customer update and show it blocked or rejected.
• Change the underlying record, then retry the stale update.
• Show the stale-state mismatch.
• Try guessed raw SQL tool names and show they do not dispatch.

This demonstrates exact target binding, compare-before-write, and state drift handling without needing a real production database.