Connecting Claude to MCP does not mean it already understands your project. It must call tools first to obtain context. This article explains six prompting techniques for working efficiently with MCP-enabled Claude: establish context, name tools, narrow scope, chain tool calls, use templates, and describe goals.
After connecting Claude to MCP (Model Context Protocol), it can read project files, search code, and run commands. But many people find that even after setup, Claude still misses the point. The reason is simple: MCP gives Claude capability, not context. Claude must call tools before it can see your project. How you ask directly affects whether it calls the right tools and gives useful answers. This article covers six prompting tips and one core principle.
First: Claude Does Not Automatically Know Your Project
This is the premise of every tip below. Registering MCP successfully does not mean Claude has read your code. At first glance, it sees nothing, just like you would. Only when it calls tools such as list_files, get_module, or search_code does the corresponding content enter its context.
You are essentially talking to a collaborator who can use tools but starts from zero every time it looks at the project. The six tips below are all about helping it obtain the right context quickly and accurately.
Tip 1: Start by Letting It Build Context
In the first turn, do not rush into the requirement. Ask Claude to explore the project and build a global map:
Good openings:
"Use list_files to inspect the project root structure."
"Use get_project_info to understand dependencies and scripts."
"Use get_structure to list all sections and components."Do not assume it already knows the structure. Give it a bird’s-eye view first so later conversations share the same map.
Tip 2: Explicitly Name the Tool
Claude can often infer which tool to call, but naming the tool is more efficient because it avoids exploratory back-and-forth.
Vague:
"Help me see how the upload component is implemented."
Clear:
"Use get_module to read src/components/upload and tell me its props interface."Clear means specifying the tool, the target object, and the output you want.
Tip 3: Narrow the Scope to Avoid Truncation
MCP tool output enters context, and output length is limited. If the scope is too broad, results may be truncated or waste context. Narrow it proactively:
Likely to be truncated:
"Search everywhere for axios usage."
Better:
"Use search_code to search axios inside src/api, with ext limited to ts."
When reading large files:
"Read lines 1-50 of src/app.tsx and inspect the Provider nesting."The three scope dimensions are: directory range, file type / extension, and line range. Smaller scope means more accurate results and less context usage.
Tip 4: Split Complex Work Into a Tool Chain
Do not expect a large task to be solved by one vague instruction. Explicitly break it into a chain of tool calls, and Claude will follow that path:
"I want to add a new section to the project:
1. First use get_structure to inspect the existing sections directory.
2. Then use get_module to read a simple section as reference.
3. Then generate the code for the new section."“Inspect structure -> read reference -> generate output” is a typical chain: build understanding first, then produce changes.
Tip 5: Use Prompt Templates for Common Scenarios
Turn frequent tasks into templates and fill in the blanks:
| Scenario | Prompt |
|---|---|
| Understand how a feature works | Use get_module to read src/sections/xxx and explain the implementation |
| Check how an API is used | Use search_code to search useRouter, with ext limited to tsx |
| Modify config | Use get_config to read vite.config.ts; I want to add a proxy |
| Inspect type definitions | Use read_file to read src/types/user.ts and list all interfaces |
| Analyze build errors | Use run_yarn to run build and analyze the error output |
| Write new code based on an existing component | Use get_module to read src/components/upload as reference and write a similar ImagePicker |
The tool names here are examples from a project-level MCP setup. Replace them with your own MCP tools; the method is the same.
Tip 6: Describe the Goal and Let Claude Decide
The previous tips are about directing Claude to use specific tools. When the task is complex and you are not sure how to break it down, do the opposite: describe the goal and let Claude orchestrate the tools.
Goal-oriented prompt:
"I want to add JWT refresh-token logic to this project.
Find the existing auth implementation, analyze it, and tell me which files need changes."Claude will then compose its own tool chain:
flowchart TD
G["You provide only the goal
Add JWT refresh token"] --> C["Claude orchestrates"]
C --> T1["get_structure
inspect auth directory"]
T1 --> T2["get_module
read auth implementation"]
T2 --> T3["search_code
find token-related code"]
T3 --> R["Analyze → propose changes"]
style C fill:#dbe9ff,stroke:#2563eb,stroke-width:2px
style R fill:#d6f5e3,stroke:#1f9e57
When to Specify Tools vs. When to Give Goals
Tip 2 and Tip 6 may seem contradictory, but they are two ends of a spectrum. Choose based on task certainty:
| Specify the tool | Give the goal | |
|---|---|---|
| Best for | You know which file or tool to use | The task is complex and you are unsure where to start |
| Benefit | Direct hit, fewer turns, fewer tokens | Easier for you; lets the model orchestrate |
| Cost | You need to think it through first | May take extra tool calls |
| In one sentence | Use it for simple, certain tasks | Use it for complex, exploratory tasks |
This does not conflict with narrowing scope. Even in goal-oriented prompts, give scope hints such as “only look under src/auth” to help Claude avoid detours.
This is essentially a ReAct loop: reason -> call tool -> observe -> reason again. Your prompt decides whether you steer every step or let the model drive. For more on this loop, see Getting Started with AI Agent Development.
Core Principle
Condense the six tips into one sentence: you are not asking someone who already understands the project; you are directing a tool-using collaborator who starts from zero each time.
From that come three rules:
- Give context before requirements. Claude must call tools before it can see. Do not make it guess.
- Narrow whenever possible. Directory, file type, and line range make results more accurate and cheaper.
- If the task is certain, name the tool; if the task is vague, state the goal. For simple work, you steer. For complex work, let it orchestrate.
Turn these into habits, and MCP moves from “connected” to actually useful.
