Review MCP and tool permissions before connection

Verifiedon 2026-07-302026.7.1

“Read-only” is a claim to test

A server can describe itself as read-only while still receiving broad network access, reading local files, observing environment variables, or exposing a tool that writes through a secondary API. Permission review therefore starts with capability inventory, not the README’s adjective.

The reviewed OpenClaw MCP guide is the primary receipt for the integration surface. Pair it with OpenClaw’s tool configuration reference, which is the source for configuration keys and tool exposure, and the sandbox versus tool-policy versus elevated execution guidance. These documents describe the platform’s boundaries at revision 2d2ddc43d0dcf71f31283d780f9fe9ff4cc04fe4; they do not approve an arbitrary third-party server.

Think of a connection as a supply-chain decision. You are adding code or a remote process, granting it a transport, mapping its tools into a runtime, and creating a future maintenance burden. The review must be reversible before the first connection is made.

The permission worksheet

Complete one row per capability, not one row per server. A server that offers five tools needs five tool records because the authority and test evidence may differ.

Secrets are data, not configuration trivia. If the candidate needs a token, record its purpose, scope, location, expiry, test-only status, and revocation command or owner. Never paste the value into the worksheet. Redact account names and local paths from screenshots.

Worked example — a task-reading server

A fictional MCP server says it “reads project tasks” but requests unrestricted network, local filesystem, and host command execution. Review the request against the job. Reading a fixed project-task API does not require arbitrary shell commands. It may not require the whole filesystem, and it should name the exact API hosts. A minimum request could be: one immutable server version; outbound access to one test API hostname; no local files; no shell; no browser profile; a read-only token limited to fixture data; a 10-second timeout; and a human owner who can revoke the token.

The rejection should be specific: “The broad request is declined because host command execution and local filesystem access are not necessary for the stated read-only task query. Re-submit with the narrower capability map and a fixture denial test.” This is better than saying “security concerns” because the next reviewer can verify the missing boundary.

artifact: task-reader@1.4.2
transport: local disposable process
network: https://fixture.tasks.invalid/api
filesystem: none
commands: none
browserProfile: none
credentials: fixture token, read-only, expires 2026-08-15
writes: none
owner: extension-review@example.invalid
expiry: 2026-08-29
revoke: delete fixture token; remove server entry; assert next call=denied

Do not install the fictional server just to prove the review. The lesson artifact is a reviewable decision. If you do run a disposable local test, capture only the server name, allowlist, policy result, and non-secret run ID.

Hands-on lab — red-team the request

Write a candidate request for a “project task reader” that is intentionally overbroad. Then produce the minimum viable request and a test matrix. Your matrix must include: allowed fixture read, filesystem denial, network denial for a second host, command denial, credential scope check, and expiry or revoke verification. The expected output is a signed or timestamped worksheet in which every requested authority has an owner and a test.

Expected result: the broad design is rejected before connection. The narrow design passes only in a disposable environment, returns structured task data, and produces no writes. Failure cases include a deny test that never exercises the boundary, a token that is valid outside the fixture, a log that prints headers, or a revocation step that removes configuration but leaves the token active. Rollback is “do not connect”; if a connection already exists, disconnect it, remove the server registration, revoke the test credential, delete cached state, and run the denied-call check.

Checkpoint

Which evidence closes a permission review?

A. A popular package name
B. A successful first run
C. A named artifact version, requested authority inventory, containment test, owner, expiry, and revoke action
D. A promise not to use the dangerous functions

Answer: C. Popularity and intent do not establish control. The record must be reproducible when a future reviewer has to disable the integration quickly.

Learner artifact and source receipt

Submit the completed worksheet, the rejection paragraph, the minimum request, and the denial matrix. Include direct links to the pinned MCP source and tool policy source. The source receipt validates the platform concepts and revision; your worksheet must supply the supplier-specific denials, owner, expiry, and removal proof. Re-check the pinned references when the implementation surface changes; they bound platform concepts, while the worksheet remains the evidence for this decision.