* docs(server): document Err vs Ok(CallToolResult::error) visibility contract
The MCP spec separates two failure modes that surface very differently in
clients:
- Err(ErrorData) is a JSON-RPC protocol error. Most MCP clients render
it opaquely ("Tool result missing due to internal error") - the
caller does not see the message text.
- Ok(CallToolResult::error(content)) is a tool-level error. Clients
render the content; the caller reads the message.
The right shape for "the tool didn't work" is the latter, but Err is
what most handlers reach for because it looks like the natural Rust
return value. This commit adds rustdoc on both ServerHandler::call_tool
and CallToolResult::error pointing handlers at the correct shape, with
a worked example showing protocol errors (-32602 invalid_params) vs
tool errors (empty result, downstream failure).
This is the docs half of the visibility-contract ask. A follow-up may
introduce a typed ToolOutcome sum type to enforce the distinction at
compile time; this PR is the lower-risk version that unblocks the
class immediately.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
* docs: update crates/rmcp/src/handler/server.rs
* docs: update crates/rmcp/src/model.rs
---------
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-authored-by: Dale Seo <5466341+DaleSeo@users.noreply.github.com>
|
||
|---|---|---|
| .. | ||
| src | ||
| tests | ||
| build.rs | ||
| Cargo.toml | ||
| CHANGELOG.md | ||
| README.md | ||
The official Rust SDK for the Model Context Protocol. Build MCP servers that expose tools, resources, and prompts to AI assistants — or build clients that connect to them.
For getting started, usage guides, and full MCP feature documentation (resources, prompts, sampling, roots, logging, completions, subscriptions, etc.), see the main README.
Feature Flags
| Feature | Description | Default |
|---|---|---|
server |
Server functionality and the tool system | ✅ |
client |
Client functionality | |
macros |
#[tool] / #[prompt] macros (re-exports rmcp-macros) |
✅ |
schemars |
JSON Schema generation for tool definitions | |
auth |
OAuth 2.0 authentication support | |
elicitation |
Elicitation support |
Transport features
| Feature | Description |
|---|---|
transport-io |
Server-side stdio transport |
transport-child-process |
Client-side stdio transport (spawns a child process) |
transport-async-rw |
Generic async read/write transport |
transport-streamable-http-client |
Streamable HTTP client (transport-agnostic) |
transport-streamable-http-client-reqwest |
Streamable HTTP client with default reqwest backend |
transport-streamable-http-server |
Streamable HTTP server transport |
TLS backend options (for HTTP transports)
| Feature | Description |
|---|---|
reqwest |
Uses rustls — pure Rust TLS (recommended default) |
reqwest-native-tls |
Uses platform-native TLS (OpenSSL / Secure Transport / SChannel) |
reqwest-tls-no-provider |
Uses rustls without a default crypto provider (bring your own) |
Transports
The transport layer is pluggable. Two built-in pairs cover the most common cases:
| Client | Server | |
|---|---|---|
| stdio | TokioChildProcess |
stdio |
| Streamable HTTP | StreamableHttpClientTransport |
StreamableHttpService |
Any type that implements the Transport trait can be used. The IntoTransport helper trait provides automatic conversions from:
(Sink, Stream)or a combinedSink + Stream(AsyncRead, AsyncWrite)or a combinedAsyncRead + AsyncWrite- A
Workerimplementation - A
Transportimplementation directly
License
This project is licensed under the terms specified in the repository's LICENSE file.