fix(macros): accept const paths and concat! in tool/prompt descriptions

[atirna]

Fixes #1175

Motivation and Context

description in #[tool] and #[prompt] only accepted a bare string literal, while neighbouring attributes on the very same items are more permissive: #[doc] on the function accepts include_str! and that value reaches the published description, and #[schemars(extend(...))] on the argument struct accepts const paths.

So the published text could already be sourced from outside the attribute, just not through the field that names it. On a server with many tools, keeping the short broadcast description next to the longer fetchable one is much easier when both can be declared together and the short one referenced from the attribute:

const GET_PROJECT_DESCRIPTION: &str = "...";

#[tool(description = GET_PROJECT_DESCRIPTION)]

How Has This Been Tested?

• before, on current main: a small crate with #[tool(description = SOME_CONST)] fails with error: Unexpected type path, and `#[tool(description = concat!("a", "b"))]` fails with `error: Unexpected type `macro
• after: both compile, and the generated <fn>_tool_attr().description equals the const value / "ab"; a bare string literal, #[doc]-derived and include_str! descriptions keep working; description = 42 is still rejected with a normal type error at the attribute
• added regression tests in test_tool_macros.rs (const path, concat!) and test_prompt_macros.rs (const path); cargo test -p rmcp-macros, the focused integration tests, and the full cargo test -p rmcp --features "client server transport-io which-command" suite pass locally, plus cargo clippy --all-targets --all-features -- -D warnings and cargo +nightly fmt --all -- --check

Implementation notes: the field is parsed through darling's PreservedStrExpr, whose FromMeta keeps a string literal a literal instead of parsing its contents as code, so existing description = "..." usage is unchanged; the generated code stores a &'static str either way, exactly as before.

Breaking Changes

None. Existing string-literal descriptions compile to the same code; only inputs that previously failed to compile are now accepted.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed