Added _meta field to prompts, resources and paginated results

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557

[pbezglasny]

Motivation and Context

MCP specifies _meta field for requested entities. Currently _meta field implemeted for tool, but missing for others.

This PR:

• adds _meta field for Prompt, Resource
• adds _meta field for PaginatedResult: ListToolsResult, ListPromptsResult, ListResourceTemplatesResult, ListPromptsResult.
• adds the meta attribute to tool_handler and prompt_handler macros
• updates Counter example to include example of usage new attributes(there is an issues with RustRover to parse attributes, but examples are working)

Format of meta attribute is the same as existed for tool.

rust-sdk/crates/rmcp-macros/src/tool.rs

Lines 127 to 131 in 2b60f8a

	let meta = ifletSome(meta) = meta {
	quote!{Some(#meta)}
	}else{
	quote!{None}
	};

In this case you need to provide Meta object, but we can update to something like

let meta = ifletSome(meta) = meta {quote!{ rmcp::model::Meta(rmcp::object!(#meta))}}else{quote!{None}};

and use with item definition only with json, for instance

#[prompt( name = "example_prompt", meta = {"meta_key":"meta_value"})]asyncfn example_prompt(

How Has This Been Tested?

• Code was tested via modelcontextprotocol/inspector.

Breaking Changes

No

Closes#557

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

Additional context

[pbezglasny]

Changed type to String, because in standard arguments are strings https://modelcontextprotocol.io/specification/2025-06-18/schema#prompts/get

[jokemanfire]

It means the args support prompt must be string? I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

[pbezglasny]

It means the args support prompt must be string?

I suppose, now there is error if using mcpinspector when calling counter_analysis tool, e.g. using examples/counter_streamhttp server. Screenshot attached

I think there must be some problem, or we should convert very type to String in prompt macro, but not enforcing the args's type should be String?

Using macro would be good solution, at least for primitive types, now it's possible to use any type with jsonschema.
Frankly speeking, I changed type to string because I was testing with inspector, but now I thinks it would be better to revert change type and changes in different PR.

[pbezglasny]

I reverted field type change. In other sdks(typescript, python) is allowed to define not string arguments of prompt the same way as rust sdk, despite string type requirements. There was issue in inspector modelcontextprotocol/inspector#869 that stands that client should send string arguments

[Copilot]

Pull request overview

This PR adds _meta field support to Prompts, Resources, and paginated list results to align with the MCP specification. The changes enable servers to attach arbitrary metadata to these entities, which was previously only available for Tools.

Key changes:

• Added meta: Option<Meta> field to Prompt, Resource, and all paginated result types (ListPromptsResult, ListResourcesResult, ListResourceTemplatesResult, ListToolsResult)
• Extended #[prompt], #[tool_handler], and #[prompt_handler] macros to accept meta parameter
• Updated the Counter example to demonstrate meta usage in prompts and handlers

Reviewed changes

Copilot reviewed 13 out of 13 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
crates/rmcp/src/model/resource.rs	Added meta field to RawResource struct with proper serde annotations
crates/rmcp/src/model/prompt.rs	Added meta field to Prompt struct and imported Meta type
crates/rmcp/src/model/content.rs	Updated test to initialize meta: None for resource content
crates/rmcp/src/model.rs	Updated paginated_result! macro to include meta field in generated structs
crates/rmcp/src/handler/server/router.rs	Replaced explicit struct initialization with ..Default::default() for cleaner code
crates/rmcp-macros/src/tool_handler.rs	Added meta parameter support to #[tool_handler] macro
crates/rmcp-macros/src/prompt_handler.rs	Added meta parameter support to #[prompt_handler] macro
crates/rmcp-macros/src/prompt.rs	Added meta parameter support to #[prompt] macro
examples/servers/src/common/counter.rs	Demonstrated meta usage in prompts and handlers; changed goal type from i32 to String with validation
crates/rmcp/tests/test_message_schema/*.json	Updated JSON schemas to reflect new _meta fields in all affected types

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

[nitpick] Field ordering inconsistency: The meta field is placed first in paginated result structs, but in entity structs like Tool, Resource, and Prompt, the meta field is placed last (after icons). For consistency, consider placing meta last in this macro as well, after next_cursor and the items field. This would match the convention used in other structs throughout the codebase.

[athola]

LGTM. if there is a requirement to update associated tests or documentation I would encourage doing so but this appears to address my ticket here: #557