3.1 Prompts, Tools, and MCP
Key Takeaways
- Strong prompts state goal, context, constraints, and success criteria.
- Structured output needs schemas and validation, not only polite instructions.
- Tools should be named clearly, scoped narrowly, and protected by authorization.
- MCP standardizes how models connect to external tools, resources, and prompts.
Prompt Structure
A production prompt should define the role, task, input context, constraints, output shape, and success criteria. Examples help the model understand format and edge cases, but examples do not replace validation.
Tool Design Checklist
| Design item | Why it matters |
|---|---|
| Clear name | Helps tool selection |
| Required fields | Prevents missing inputs |
| Type constraints | Reduces invalid calls |
| Narrow scope | Limits damage |
| Auth checks | Protects data access |
| Structured errors | Enables recovery |
MCP Basics
The Model Context Protocol (MCP) provides a standard way for applications to expose tools, resources, and prompts to models. Tools perform actions. Resources provide readable context. Prompts provide reusable templates. Choose local or remote transports based on where the integration runs and what trust boundary it crosses.
Schema Habit
If downstream code must parse the answer, design the schema first. Define required fields, enum values, nested objects, and validation behavior. Then write the prompt around that contract. This prevents a common failure where prose looks good to a human but breaks production parsing.
Exam Habit
When a scenario adds a tool, ask what inputs, outputs, permissions, and failure recovery are required.
In MCP terminology, which primitive represents readable context such as files, schemas, or records?