_meta fields, define custom methods whose names start with _, and advertise custom capabilities during initialization.
The _meta field
Object types that define a _meta field can use it to attach custom information
with type { [key: string]: unknown }. This includes many requests, responses,
notifications, and nested types such as content blocks, tool calls, plan
entries, and capability objects. Not every protocol type defines _meta. For
example, the Error object does not.
requestId. The following root-level keys in _meta SHOULD be reserved for W3C trace context to guarantee interop with existing MCP implementations and OpenTelemetry tooling:
traceparenttracestatebaggage
Extension methods
The protocol reserves any method name starting with an underscore (_) for custom extensions, so custom methods can’t conflict with methods added in future protocol versions.
Extension methods follow standard JSON-RPC 2.0 semantics:
- Requests - Include an
idfield and expect a response - Notifications - Omit the
idfield and are one-way
Custom requests
In addition to the requests specified by the protocol, implementations MAY expose and call custom JSON-RPC requests as long as their name starts with an underscore (_).
id:
Custom notifications
Custom notifications are regular JSON-RPC notifications that start with an underscore (_). Like all notifications, they omit the id field:
Advertising custom capabilities
Implementations SHOULD use the_meta field in capability objects to advertise support for extensions and their methods. To avoid collisions with other extensions, follow MCP’s naming convention: prefix extension names with dot-separated labels in reverse-DNS order of a domain you control, followed by /. For example, use com.example/<name> for _meta keys, including capability entries, and _com.example/<name> for custom methods. For example: