The tool loop
Describe, request, execute, return: who does each step.
What you’ll learn
Four ideas, one module.
Tools are ordinary code
Search, code execution, databases and APIs, run by your app.
Permissions by risk
Read, write, irreversible, never exposed: and the control for each.
MCP without the magic
An open protocol for connecting apps to tools and data.
Applied exercise
Design a travel assistant’s tools
Design the tool surface of a travel assistant and decide which capabilities should never be exposed directly.
- Read tools
- Write tools
- Needs human confirmation
- Never exposed to the model
Cheat sheet · for your projects
The model only asks. Your code decides what runs, and with whose rights.
Ask on every project
- What is the worst thing each tool can do if the model calls it wrongly?
- Whose credentials does each tool run with: the user’s, or a service account?
- Which actions can’t be undone, and where does the user confirm them?
- What happens if the same tool call is retried or sent twice?
- Which tool results carry untrusted text, such as web pages, emails or documents?
Rules of thumb
- Give each tool one narrow job; never expose raw SQL, HTTP or shell to the model.
- Enforce limits in code; a rule that lives only in the prompt is not a control.
- Require confirmation in the interface for anything that spends, sends or deletes.
- Run every tool with the signed-in user’s permissions, never an admin account.
Checklist
Tool design review
- One narrow job, with a name and description clear enough for the model to choose it correctly
- Risk level set: read, reversible write, irreversible, or never exposed to the model
- Arguments typed and validated in code: types, enums, ranges, and that IDs belong to the user
- Irreversible or costly actions need user confirmation in the interface, not in chat text
- Runs with the user’s scoped permissions; credentials stay in the app, never in context
- Every call logged with arguments and result; retries carry an idempotency key
Leave at the door
Five myths this module breaks.
| Myth | What’s actually true |
|---|---|
| “The model runs the API call.” | Your application runs it. The model only asks. |
| “With tools, it can reach anything.” | Only the tools you define, within your limits. |
| “A valid call is a correct call.” | Well-formed arguments can still be wrong values. |
| “The prompt says don’t, so it won’t.” | Instructions aren’t permissions. Enforce in code. |
| “MCP makes the model smarter.” | It standardizes connections. The model is unchanged. |
Next · Module 07