#[server]Expand description
Collects every marked method in an impl block into a Server.
Reads three marks: [tool], [resource] and [prompt]. Each is a
different amount of work, and the difference is the reason this macro
exists rather than three separate ones — the registration statements have
to run in one into_server, in source order, against one builder.
The impl is left exactly as written and a second inherent block is added
beside it, carrying one method:
fn into_server(self) -> Result<Server, JsonObjectError>The method consumes self, so the name reads as what it is: the type you
wrote becomes a server. It returns a Result because a tool’s inputSchema
is a serde_json schema and a type with no schema — a map with a non-string
key, say — is a mistake worth naming rather than a panic.
The server’s name is the type’s own, or name = "..." when the name a peer
sees should differ from the Rust type name, which is usually the case.
§What is checked, and what is left to the registry
Signatures. A #[resource] that is async, takes a receiver, or returns
something other than a Resource is a compile error naming the fix, and
the same for #[prompt] and Prompt.
Identities are not. Two #[resource] methods producing the same uri is
decided by the registry when into_server runs, because the uri is built
in a method body and a macro cannot read it without running the body. See
[resource] for why a partial check is worse than none here.
§Examples
A worked example lives in
crates/protocol-droid/tests/macros.rs, where every macro
shape is exercised against real types and the listings are
read back through the dispatcher. A doctest here would be a
strict subset of that coverage and would also require this
crate to depend on protocol-droid for compilation, which
is the cycle the docstring in Cargo.toml says it does not
create.