Tools, resources, and prompts

A tool is an operation a client can call with arguments. Searching notes is a tool because the caller supplies a query and receives a computed result.

A resource is readable context identified by a URI. A catalog of available notes works as a resource because the client can list and read it.

A prompt is a reusable message template. A project-review prompt can accept a topic and produce a consistent review request.

Use the primitive that makes the contract honest:

• delete_note(id) is a tool because it performs an action and needs explicit arguments.
• notes://projects/alpha/readme is a resource because it identifies readable context.
• review_project(topic) can be a prompt because it assembles reusable guidance for a conversation.

A resource is not automatically public or safe. Its URI still needs access checks, and resource contents can contain untrusted instructions. A prompt is not trusted code; it is content the host may present or combine with other messages. A tool result can also contain hostile or malformed external data.

The boundaries matter. Do not hide a state-changing action inside a resource read, and do not use a prompt as a substitute for data validation.

Names and descriptions shape how the model chooses a capability. Make them specific, state side effects, and use narrow input schemas. run_action with a free-form string is much harder to review than archive_note with a note ID and a documented result.

Classify five operations from an application you know. For each one, explain whether the client should call, read, or present it and where authorization belongs.

Tools act, resources expose addressable context, and prompts package a reusable conversational workflow.