Tool Capability Preflight — Claude Code Guide

Preflight before connecting a tool

Connecting an MCP server does not create a safe workflow by itself. Before starting, understand the problem, permitted operations, result verification, and how the integration can be disabled quickly.

External data such as issues, alerts, documentation, or database rows is context for a hypothesis, not a diagnosis or command to execute.

Preflight question	Record
Need	What recurring problem does the tool solve?
Access	What does the integration read, change, or run?
Context	Which fields, logs, or records are actually needed?
Approval	Which actions need explicit confirmation?
Verification	Which code, test, log, or query confirms the result?
Kill switch	How do you disable, revoke, or return to local scope?

Ten steps before automation

State a concrete need rather than a desire to connect a tool “for later”.
Keep the capability set minimal.
Record forbidden operations separately.
Start read-only.
Protect credentials and choose an intentional scope.
Limit data entering context.
Define approval for risky actions.
Describe result verification before the first run.
Prepare for conflicting or incomplete data.
Confirm a short disable path.

Issue tracker example

Read-only analysis preflight

Need: analyze refund-request sorting
Allowed: read issue, comments, and labels
Forbidden: change status, assignee, labels, or comments
Credentials: read-only token outside repository
Verification: code, targeted test, local reproduction
Fallback: manual issue reading

When sources disagree

An issue provides problem context, an alert provides a runtime symptom, documentation describes expected behavior for a version, code shows implementation, and tests show checked scenarios. No single source is universally sufficient.

Pause editing, separate confirmed and unconfirmed claims, and propose the smallest check: targeted test, local reproduction, or inspection of one file.