MCP Local Tool Access Rules

Purpose

Use these rules when an AI client connects to an MCP server that can expose local tools, resources, prompts, roots, credentials, or networked services.

This is a runtime access policy. It is not only about whether a server is safe to install. It is about whether the server should remain enabled for the current task, with the current roots, transport, credentials, and approval rules.

Access Inventory

Before enabling an MCP server, record what the client can see and what the server can do.

1. Tools. List every model-callable action, its parameters, side effects, timeout behavior, and whether it can read, write, delete, execute, or call external services.
2. Resources. List resource URI patterns, templates, cached data, dynamic data sources, and whether resource contents can include secrets or private records.
3. Prompts. Review prompt templates for hidden instructions, stale project policy, sensitive examples, or actions that encourage unsafe tool calls.
4. Roots. Name the filesystem or workspace roots the client exposes and why each root is needed for the task.
5. Transport. Record whether the server uses stdio, local HTTP, streamable HTTP, SSE, or a remote endpoint, and who can reach that channel.
6. Credentials. List environment variables, tokens, config files, cookies, browser profiles, SSH keys, cloud credentials, and service accounts the server can access.
7. Logs and artifacts. Identify where tool calls, prompts, outputs, traces, and errors are stored.

If any item is unknown, keep the server disabled or run it in a disposable test workspace until the owner can explain the access boundary.

Local Access Rules

• Enable one MCP server for one clear job; avoid broad "utility" servers that expose unrelated tools.
• Default tools to read-only where possible.
• Require explicit approval before writes, deletes, command execution, browser automation, payments, emails, calendar changes, cloud mutations, database changes, or production network calls.
• Limit roots to the smallest directories needed for the task.
• Do not expose home directories, credential folders, cloud config, browser profiles, mail stores, password-manager exports, or production data by default.
• Separate development, staging, and production credentials; never pass broad personal tokens when a scoped test token will work.
• Treat public HTTP listeners, remote transports, and shared workstations as higher risk than local stdio servers.
• Review prompts and resources with the same care as tools because they can inject instructions or reveal private context.
• Disable the server when the task ends, when the package updates, or when the server's exposed tool list changes.

Approval Gates

Require a human approval gate before allowing MCP tool calls that can:

• modify files outside the current worktree;
• run shell commands, scripts, package managers, or interpreters;
• connect to production systems or private customer data;
• use browser, email, calendar, messaging, clipboard, screen, or accessibility automation;
• write to databases, queues, cloud storage, SaaS APIs, or billing systems;
• change repository settings, secrets, CI, deployments, DNS, or release automation;
• export large tool outputs, logs, traces, or resource snapshots into the model context.

Approval should name the tool, target, expected side effect, rollback plan, and maximum scope. Do not approve a vague request such as "let the MCP server fix it" when the actual tool call can mutate local or remote state.

Merge Or Config Blockers

Block enabling or merging MCP configuration until resolved when:

• the exposed tools, resources, prompts, roots, or transport are not inventoried;
• a server can write, delete, execute commands, or mutate external services without an approval gate;
• roots include sensitive directories that are not needed for the task;
• credentials are broad, personal, unscoped, production-facing, or hard-coded;
• a local HTTP server is reachable from untrusted networks;
• logs or traces store raw secrets, customer records, prompts, or tool outputs;
• package updates changed tool behavior but the server was not reviewed again;
• the server owner cannot explain how to disable, revoke, or rotate access.

Review Checklist

• {"task": "Tools inventoried", "description": "Every exposed MCP tool has a known purpose, parameter shape, side effect, and approval requirement"}
• {"task": "Resources reviewed", "description": "Resource templates and returned data are checked for secrets, private records, and unnecessary breadth"}
• {"task": "Prompts safe", "description": "Prompt templates do not smuggle unsafe instructions, stale policy, or sensitive examples"}
• {"task": "Roots minimal", "description": "Filesystem roots are limited to the task workspace and exclude sensitive directories"}
• {"task": "Transport bounded", "description": "stdio, local HTTP, remote HTTP, or SSE access is matched to the trust boundary and network exposure"}
• {"task": "Credentials scoped", "description": "Tokens and environment variables are least-privilege, revocable, and separate from production credentials"}
• {"task": "Logs redacted", "description": "Tool outputs, traces, errors, and prompt artifacts avoid raw secrets and private user data"}

Troubleshooting

• The tool list is too broad: disable the server and re-enable only the specific server or profile needed for the current task.
• The client needs a whole repository root: exclude credential folders, generated secrets, private data dumps, and unrelated sibling projects before exposing the root.
• A server update changed behavior: treat it as a new access review; compare the tool list, prompts, resources, transport, and credential requirements.
• A tool call needs production access: use a break-glass approval path, time-bound credentials, dry-run output, and rollback notes.
• Logs contain private data: stop sharing the log, rotate exposed secrets if needed, and configure redaction before reconnecting the server.

Duplicate And History Check

Checked existing rules, guides, hooks, skills, MCP entries, open PRs, and closed PR history for MCP safety, local tool access, server threat modeling, MCP roots, tools, resources, prompts, transports, authorization, and least privilege.

Adjacent content includes the pre-installation MCP threat-modeling guide, the MCP server auth and least-privilege build guide, MCP server hardening skills, FastMCP review skills, and local-first AI dev stack guidance. This entry is distinct because it is a portable rules policy for active local MCP tool access: what to inventory, what to approve, how to bound roots and transports, when to disable access, and how to keep tool outputs and logs privacy-safe during an AI-client session.

Spec Responsibility Split

The tools/call specification assigns distinct security duties to each side of an MCP connection. Use this split to assign review ownership when bounding local tool access.

The spec defines two error mechanisms: a protocol error is a standard JSON-RPC error, while a tool execution error is returned inside a normal result with isError: true (its content still reaches the model context):

{
  "jsonrpc": "2.0",
  "id": 4,
  "result": {
    "content": [
      { "type": "text", "text": "Failed to fetch weather data: API rate limit exceeded" }
    ],
    "isError": true
  }
}

Sources

• Model Context Protocol specification - https://modelcontextprotocol.io/specification/2025-06-18
• MCP tools specification - https://modelcontextprotocol.io/specification/2025-06-18/server/tools
• MCP resources specification - https://modelcontextprotocol.io/specification/2025-06-18/server/resources
• MCP prompts specification - https://modelcontextprotocol.io/specification/2025-06-18/server/prompts
• MCP roots specification - https://modelcontextprotocol.io/specification/2025-06-18/client/roots
• MCP transports specification - https://modelcontextprotocol.io/specification/2025-06-18/basic/transports
• MCP security best practices - https://modelcontextprotocol.io/docs/tutorials/security/security_best_practices

• Source repositorygithub.com 2026-07-19T11:20:19-07:00
• Documentationmodelcontextprotocol.io
• Submitted by MkDev112026-06-04