#Tools and agents

Without tools, the prompt must describe how to finish the whole job in language. With tools, the model has another path: pick a tool → read the result → think again. The prompt’s job becomes goal, bounds, when to use which tool, and what to do on failure—not faking function-call JSON in prose (that protocol belongs to the API / SDK).

This site hosts the same loop in different containers:

flowchart TD
  P[System contract: goal and policy] --> M[Model]
  S[Tool schemas: name/args/when] --> M
  U[User task] --> M
  M -->|tool call| T[Execute]
  T -->|results as data| M
  M --> R[Final reply to the user]

#What to put in the prompt

Do write:

• Success criteria (“stop when tests pass”)
• Tool policy (“live facts must be fetched, not recalled”; “math goes to the calculator”)
• Forbiddens (“do not commit secrets”; “no DROP TABLE”)
• Failure behavior (“summarize the error and ask a human”; do not fake success)
• Final shape for humans (short diff notes, or a structured summary)

Do not write:

• A hand-copied replica of parameter JSON the vendor already injects
• “Emit a fake XML function call” to bypass the official tool channel
• An entire API manual in the system prompt (use an MCP resource or retrieval; see Structure)

A tool’s description and parameter schema are a second prompt. “What this tool does / does not do” beats restating it in system text. A vague search(query) becomes a hammer for every nail.

# Weak
search: Search.

# Strong
search_docs: Keyword search over Markdown under docs/ in this repo.
Use for “what does the tutorial say” questions. Do not use for the live web or private tickets.
Return at most 5 snippets; if nothing matches, return an empty list—do not invent paths.

A weak description forces a second essay in system about “please use search correctly.” A strong description shows the boundary at tool-choice time. MCP tool descriptions, LangChain docstrings, and Dify tool blurbs all sit in this column.

#A reusable agent policy

You are a coding assistant for this repo. Read relevant files before editing.
- Search when you need facts or the live web; do not invent APIs this library does not have.
- After code changes, run tests that already exist. Fix failures; do not delete tests to go green.
- Secrets, `.env`, production credentials: do not print them or paste them into docs.
- On tool errors: report the command and exit code, propose the smallest next step, wait.
- Finish with a few bullets: what changed and how to verify. Do not dump whole files.

That is the shape of a Cursor rule, a LangChain system_prompt, and a Dify Agent prompt. The user message is this turn’s task (“add a timeout to parse_order”). Do not paste the whole policy every time.

#How this differs from chat prompts

Human approval (edits, email, payments) is a product feature and a prompt constraint: “for high-impact actions, outline first and wait.” Product details live in those courses; this course only requires that the contract says so.

#Next steps

• Evaluation — agents need regression, not one demo
• Practical examples — repo-level instructions
• MCP intro · LangChain tools · Cursor Agent