Prompt examples
MCP prompts should not only tell an agent what to do. They should also tell it what not to touch, what evidence to save, and when to stop for human approval. Use these examples as starting points for Claude Code, Codex, Cursor, and other MCP-enabled agent workflows.
Last reviewed July 10, 2026.
Direct answer
A safe MCP prompt should include the task, allowed tools, permission level, blocked actions, expected evidence, and approval checkpoint. The most useful pattern is: inspect first, summarize findings, propose a plan, and wait before changing files, submitting forms, querying production data, or using credentials.
Use the available repository and MCP tools in read-only mode. Summarize the package structure, risky dependencies, hidden scripts, and files that need human review. Do not edit files, run install commands, or print secrets.Use when: First pass before allowing a coding agent to change a repo.
Guardrail: Blocks writes and secret exposure until the operator approves the next step.
Only inspect files inside the documented project directory. Find outdated setup instructions, propose a patch plan, and list exact files that would change. Wait for approval before editing.Use when: Safe documentation refresh with a filesystem MCP server.
Guardrail: Confines the agent to one folder and separates planning from mutation.
Open the preview URL, check desktop and mobile layout, record title/H1/CTA visibility, check horizontal overflow, and save screenshots. Do not submit forms, purchase, publish, or change account settings.Use when: Preview QA with browser automation or Chrome DevTools MCP.
Guardrail: Allows visual evidence while blocking state-changing browser actions.
Use the read-only database connection. Inspect schema names, row counts, and recent migration evidence. Do not write data, run destructive queries, or export personal data.Use when: Preflight before adding database MCP access to an agent workflow.
Guardrail: Keeps the server useful for diagnosis without granting write authority.
The exact tool names will change between Claude Code, Codex, Cursor, desktop clients, and custom MCP hosts. The durable part is the control pattern. A strong prompt names the allowed action class, asks for evidence, and prevents the assistant from treating successful inspection as permission to mutate the system.
| Pattern | Use it for | Reusable structure |
|---|---|---|
| Inspect, then ask | Code review, migration planning, dependency audits, and docs refreshes. | Inspect the allowed scope, summarize findings, propose exact files, then stop for approval. |
| Read-only proof | Database, browser, filesystem, GitHub, and DevOps integrations before write access. | Run one non-mutating task, save evidence, and report which write action was intentionally blocked. |
| Evidence packet | Preview QA, release gates, compliance checks, and customer-support investigations. | Return route status, screenshots, logs, sample records, and a pass/fail table without changing state. |
| Human checkpoint | Any task that could publish, deploy, email, purchase, delete, merge, or mutate data. | Name the proposed action, explain risk, wait for explicit approval, and keep a rollback note. |
Treat each prompt as a template, not a universal script. Replace the project path, preview URL, database role, browser profile, or repository name with the smallest useful scope. If the prompt will run in a shared environment, include the team rule that matters most: no production writes, no personal account sessions, no hidden credentials, and no public publication without owner approval.
The safest MCP prompts also separate discovery from execution. Discovery prompts ask the agent to inspect, summarize, and propose. Execution prompts are shorter, more specific, and tied to a reviewed plan. This split prevents a helpful assistant from turning a broad research task into an unapproved file edit, database query, browser submission, or deployment.
Do not reuse these prompts blindly for customer data, payment systems, message sending, production databases, or authenticated browser sessions. Those workflows need a narrower policy, a real rollback path, and usually a human confirmation step. A prompt that is safe for a sandbox preview can still be unsafe for a live billing dashboard.
Before a prompt becomes a shared team pattern, review it like a small operational policy. First, identify the system it can influence: local files, browser tabs, GitHub issues, a database, a deployment provider, or a customer-support tool. Second, decide the allowed action class. Some prompts should only inspect. Some can draft a patch. Fewer should be allowed to execute a write after approval. The prompt should say that boundary directly instead of relying on the assistant to infer it from context.
Third, test the prompt against an intentionally risky request. Ask the agent to print a secret, edit a file outside the allowed folder, submit a browser form, or run a destructive command. The correct result is not a clever workaround. The correct result is a refusal, a short explanation, and a safe alternative. That blocked-action test is what turns a prompt from a nice example into a reusable control.
Answer engines are more likely to cite a prompt page when the page contains reusable patterns, not only a wall of sample text. The best citation units are short definitions, checklists, tables, and examples that pair a task with a guardrail. A page about MCP prompts should therefore make the permission model visible: read-only inspection, evidence capture, approval checkpoint, and explicit blocked actions. Those elements help a reader copy the pattern without copying unsafe authority.
A reusable MCP prompt should name the tool boundary, permission level, allowed paths or systems, blocked actions, expected evidence, and approval point before mutation. Vague prompts are risky because MCP servers can touch files, browsers, databases, APIs, and other real systems.
Only include install commands when the package source, maintainer, and client configuration have been verified. For general prompt examples, separate the prompt from the install step so users do not copy a command before reviewing permissions.
The intent can be shared, but the operational wording should match the client and available tools. Keep the invariant parts: read/write boundary, approval checkpoint, evidence to save, and actions the agent must not take.
Prompt examples give answer systems concrete, reusable text with visible guardrails. A page with direct answers, examples, checklists, and FAQ is easier to cite accurately than a generic directory page.