ChatGPT Agent Prompt

Give ChatGPT Agent a scoped prompt for using Coding Tools MCP safely and effectively.

ChatGPT Agent Prompt

Use this tutorial when ChatGPT Agent is connected to a Coding Tools MCP server and you want it to behave like a careful local coding agent.

The goal is simple: make the model use the MCP tools for the real workspace, keep edits scoped, verify with the same runtime, and stop instead of silently falling back to an unrelated sandbox when the MCP server is unavailable.

Before you paste the prompt

Start Coding Tools MCP against the repository you want ChatGPT to work on:

coding-tools-mcp --workspace /absolute/path/to/repo --host 127.0.0.1 --port 8000

For a remote ChatGPT connector, expose the server through an HTTPS tunnel and use the safest profile that fits the task. Use read-only for inspection-only sessions and full only when the connected client is trusted to edit and run commands.

If the server root is wrong, restart Coding Tools MCP with the intended --workspace. The runtime is one workspace root per process; there is no separate open_workspace tool.

Copyable prompt

Paste this into the ChatGPT app, agent instructions, or first message for a coding session:

Always use the configured Coding Tools MCP server for local files, commands, project inspection, code edits, and environment checks.

At the start of a new workspace task, call `server_info` first, then `get_default_cwd`. Use the returned workspace root, default cwd, tool profile, auth posture, permission mode, and exposed tool list as the source of truth.

Do not use ChatGPT's `/workspace` sandbox, Python scratch files, uploaded-file workarounds, or guessed local paths for project work unless I explicitly upload files there or ask you to work in that sandbox.

If Coding Tools MCP is unavailable, misconfigured, points at the wrong workspace, or exposes a read-only profile when the task requires edits, stop and report the MCP problem. Do not silently fall back to another filesystem.

For inspection, prefer targeted `list_dir`, `list_files`, `search_text`, and `read_file` calls. Avoid broad recursive scans unless the task needs them.

For source edits, use `apply_patch`. Keep patches scoped to the request and avoid unrelated refactors.

For validation, use `exec_command` for bounded checks such as tests, lint, typecheck, builds, or project-specific verification. Use `write_stdin` only for an active command session and `kill_session` when a session must be stopped.

Use `git_status` and `git_diff` when useful before and after edits. Summarize changed files, verification run, and anything blocked.

Respect Coding Tools MCP permission modes. In `safe` mode, expect network-looking commands, shell expansion, inline scripts, sensitive env, and destructive commands to be blocked. Ask me to restart the server in `trusted` mode only when the project task genuinely needs those gates opened.

Recommended tool loop

1. Orient with server_info and get_default_cwd.
2. Find only the relevant files with search_text, list_files, or list_dir.
3. Read the minimum useful slices with read_file.
4. Edit with apply_patch.
5. Verify with exec_command when the profile and permission mode allow it.
6. Review the result with git_diff and git_status.
7. Report files changed, checks run, and blockers.

Adapting Existing Agent Prompts

When you reuse an agent prompt from another local-coding workflow, rewrite it around the tools this server actually exposes:

Prompt intent	Coding Tools MCP equivalent
Inspect server and workspace configuration	server_info
Confirm the current working directory	get_default_cwd
Inspect the file tree without loading everything	targeted list_dir or list_files
Read source files	read_file
Search the codebase	search_text
Edit files	apply_patch
Run verification commands	exec_command
Review changes	git_status and git_diff

Avoid instructions that ask the model to call unavailable workspace-switching, inventory, or handoff tools. To switch repositories, restart Coding Tools MCP with a different --workspace.

Safety checklist

• The workspace in server_info matches the repository you expect.
• The active profile exposes the tools you need. read-only is not enough for source edits.
• Remote sessions use bearer auth or OAuth unless you intentionally started a short-lived read-only test tunnel.
• exec_command output is treated as data; the model should still inspect failures and not assume a command succeeded.
• The final answer includes changed files, verification, and blocked items.