Tool use and MCP integration

Tools let Claude fetch live data and take actions. You define each tool with a name, a clear description, and an input JSON schema; Claude decides when to call it, you execute it, and you return the result — a loop that repeats until Claude is done. Write descriptions like documentation: the description is the single biggest driver of correct tool use. Independent tools can be called in parallel. MCP (Model Context Protocol) standardises how external systems expose tools, resources, and prompts to Claude, so integrations are reusable across any MCP‑aware client. Always gate destructive or irreversible actions behind human approval or scoped permissions.

An MCP server is a product for models: expose narrowly‑scoped tools (actions), resources (data worth reading into context), and prompts (reusable templates). Keep each tool's scope tight and its description precise; authenticate at the server; treat every input as untrusted. The payoff of doing it once and well: the same server plugs into any MCP‑aware client — Claude Code, desktop, your apps — with no per‑app integration work.

• Tool definition: name + description + input_schema (JSON Schema). Description quality = tool‑use quality.
• The loop: Claude requests a tool → you run it → return tool_result → repeat.
• Parallel tools: independent calls in one turn; sequence only when dependent.
• MCP triad: tools (actions) · resources (data) · prompts (templates), over one standard protocol.
• Reusable: one MCP server works across any MCP client (Claude Code, apps).
• Security: least privilege · scope tools narrowly · human approval for writes/deletes/payments.
• Errors: return clear is_error results so Claude can recover — not raw stack traces.
• Don't over‑tool: expose only what the task needs.

• Say what it does, when to use it — and when NOT to.
• Document every parameter: format, units, allowed values, an example.
• State side effects: read‑only vs destructive; idempotent or not.
• Return concise, structured results — not raw dumps the model must dig through.
• Errors: is_error: true + an actionable message (what failed, what valid input looks like).
• Prefer fewer, sharper tools over many overlapping ones; distinct names, no ambiguity.
• The description is documentation for the model — write it like docs, not a label.

Every tool is defined by “NDS” — Name, Description, Schema. The MCP triad is “TRP” — Tools (do), Resources (read), Prompts (reuse). Destructive action? Gate it — human in the loop.

When a tool fails, “TELL” the model — Tag it (is_error: true), Explain what failed, List what valid input looks like, Let Claude retry. A good error message turns a dead end into a self‑correction.