A useful rule answers four questions:
Can the agent see this tool? Can the agent request it? What arguments or result size are acceptable? Does a write need to match something that was just read?
For the full website guide, use:
Server-specific playbooks:
The full Markdown manuals also ship inside the downloaded ZIP/tarball under docs/mcpboundary/publish/tool_rules/.
Dashboard Builder Workflow
For normal editing, do not start by pasting full Policy JSON.
Use the tool-first path:
select a tool -> change its access or input rules -> optionally show the server-validated Policy JSON -> save policy with the dashboard edit token -> restart/reload if the page says changes apply after restart/reconnect
The full Policy JSON editor remains available under Builder: Full Policy JSON for complete developer Policy files. Builder changes are local until saved.
Policies use the downstream server's native tool name. The client-safe name the agent sees may replace dots with underscores, but it must not be copied into downstream_tool_name unless it is also the native name.
Without loaded tool metadata, Builder can create an explicit manual Policy when you know the native tool and field names. Those names are unverified and match only when they are exact. Unsupported or complex shapes remain preserve-only and require Full Policy JSON for direct editing.
The Basic Controls
Visibility controls whether the agent sees a tool:
visible the agent can see the tool dashboard_only the dashboard can show it, but the agent should not request it hidden do not expose it to the agent
Call handling controls what happens when the agent asks for a tool:
allow continue through the checked path block stop before downstream execution review_required do not treat as normal allowed work
review_required stops the first call before execution and creates a pending local approval. With the local operator token, the dashboard can approve or reject that exact item. Approval does not execute the tool; the agent must make a later call with top-level approval_retry metadata and the original arguments. See the concrete retry shape in the FAQ.
Read Vs Write
Start with reads, but do not assume every read is harmless.
Good first choices:
- search/list/read tools with result limits
- metadata reads
- one exact record, issue, message, or thread
Harden or block:
- send
- publish
- merge
- push
- delete
- trash
- raw SQL
- batch mutation
- broad admin tools
Classify a tool by its strongest possible effect, not by a friendly name.
Scope Binding
Scope binding means a write targets exactly the resource that was read or confirmed.
Examples:
only this email thread only this message only this GitHub issue only this customer record only this repo/path/ref
Good bindings use stable IDs such as thread_id, message_id, customer_id, issue_number, pull_number, repo, path, or head_sha.
Weak bindings use text such as subject line, display name, search query, "latest item", or "the one we just discussed."
Stale-State Binding
Stale-state binding means a write should not run if the relevant state changed after the read.
Good stale-state fields include:
version updated_at etag state_hash head_sha last message id message count
Database tools are the clearest stale-state examples. Email tools can often bind to a thread or message, but they may not expose a hard version/hash. GitHub write rules often need repo, path, ref, and sha binding.
In Builder, the guided state-binding recipe is under Advanced controls on the write tool. It creates the read tool's observation rule and the write tool's state binding without executing either tool. MCP Boundary does not infer the read result schema, so confirm that the configured result fields really exist.
For email, treat thread_id and message_id as scope binding unless the MCP Server also returns a stable state fact such as a provider history id, last message id, message count, or thread state hash. The public email examples keep send/delete paths blocked or reviewed instead of claiming a hard Gmail state_binding rule.
Example Starting Patterns
For email:
search/read visible + allow + result limit create draft visible + allow or review_required send hidden or visible + block trash/delete hidden + block
For database tools:
read record visible + allow + observation rule update record review_required or allow only with state binding raw SQL hidden + block delete hidden + block
For GitHub:
list/read issue visible + allow + repo binding comment issue review_required unless tightly scoped file write hidden or review_required with repo/path/ref/sha binding merge/push dashboard_only or hidden, not first-run allow
What MCP Tool Rules Do Not Claim
MCP Boundary checks MCP calls that pass through it.
It does not automatically see:
- a direct agent connection to the original MCP server
- downstream internal effects hidden behind one outer tool
- provider-side automations after the MCP server runs
- retries that may duplicate an uncertain side effect
Do not turn a rule example into a broad support claim. Use Tested Servers And Limits for what has actually been tested.