Attribute Macro resource 

#[resource]

Marks a plain fn returning a Resource as a resource the server lists.

This attribute generates nothing on its own, for the same reason [tool] generates nothing: it expands inside the impl block, where Rust forbids declaring a struct or a function. [server] reads the mark and emits the registration.

The shape

fn name() -> Resource

A plain fn, not an async fn. A resource is registered once, while the server is being built, so there is nothing to await — and an async fn would hand into_server a future where a Resource belongs. The return type is read by its last path segment, so Resource and crate::domain::registry::Resource are equally good.

What the method body is for

The whole Resource, including its uri, description, mime type and size. That is deliberate: the body is ordinary Rust, so anything computable there — a config value, a constant, a match — is available.

What is not checked, and why

Two methods in one #[server] block producing the same uri is not caught at expansion time. The uri lives in the method body, which is arbitrary code, so syn cannot read it — a check that saw the body would have to be a check that ran it. Two claims for one key are therefore decided by the registry at build time, not by the macro. The detection would need the uri as a #[resource(uri = "...")] literal, and that would put the key in two places at once: the attribute and the body, with nothing to say they agree. A duplicate-uri check that covers only the attribute-literal spelling and reads as a general one is worse than none, because it is confidently green over the case it cannot see.

A #[resource] outside a #[server] block is also unchecked, and cannot be: an attribute on a method is expanded without any knowledge of the impl around it, so it has no way to ask whether anything is reading it.

Examples

A worked example lives in crates/protocol-droid/tests/macros.rs, where every macro shape is exercised against the real Resource and Prompt 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.