Tool Design
This is a member-only chapter. Log in with your Signal Over Noise membership email to continue.
Log in to readModule 4 · Section 5 of 9
Tool Design
The hello example is trivial. Real tools need more thought.
Name clearly. Tool names are how Claude decides what to use. get_calendar_events is better than fetch or calendar. Be specific enough that Claude can distinguish between your tools without guessing.
Write useful descriptions. Claude reads these descriptions when deciding whether to call a tool. “Returns a greeting” is fine for a demo. For real tools, write what the tool does, when to use it, and what it returns. The description is your tool’s interface contract with Claude.
Keep input schemas tight. Define exactly what each parameter is and whether it’s required. Don’t make everything optional when some parameters are genuinely required. Don’t mark things as required when Claude should be able to call the tool without them.
Return structured text. The content array can contain text, images, or other types. For most purposes, return clear text that Claude can reason about. If you’re returning data, format it in a way that’s easy to parse — JSON, markdown tables, or plain prose depending on what Claude will do with it.