Bump the cargo group across 2 directories with 2 updates#143
Open
dependabot[bot] wants to merge 2 commits into
Open
Bump the cargo group across 2 directories with 2 updates#143dependabot[bot] wants to merge 2 commits into
dependabot[bot] wants to merge 2 commits into
Conversation
Bumps the cargo group with 2 updates in the /mcp-client-rust directory: [rmcp](https://github.com/modelcontextprotocol/rust-sdk) and [openssl](https://github.com/rust-openssl/rust-openssl). Bumps the cargo group with 2 updates in the /weather-server-rust directory: [rmcp](https://github.com/modelcontextprotocol/rust-sdk) and [openssl](https://github.com/rust-openssl/rust-openssl). Updates `rmcp` from 0.8.1 to 1.4.0 - [Release notes](https://github.com/modelcontextprotocol/rust-sdk/releases) - [Changelog](https://github.com/modelcontextprotocol/rust-sdk/blob/main/release-plz.toml) - [Commits](modelcontextprotocol/rust-sdk@rmcp-v0.8.1...rmcp-v1.4.0) Updates `openssl` from 0.10.79 to 0.10.80 - [Release notes](https://github.com/rust-openssl/rust-openssl/releases) - [Commits](rust-openssl/rust-openssl@openssl-v0.10.79...openssl-v0.10.80) Updates `rmcp` from 0.3.0 to 1.4.0 - [Release notes](https://github.com/modelcontextprotocol/rust-sdk/releases) - [Changelog](https://github.com/modelcontextprotocol/rust-sdk/blob/main/release-plz.toml) - [Commits](modelcontextprotocol/rust-sdk@rmcp-v0.8.1...rmcp-v1.4.0) Updates `openssl` from 0.10.79 to 0.10.80 - [Release notes](https://github.com/rust-openssl/rust-openssl/releases) - [Commits](rust-openssl/rust-openssl@openssl-v0.10.79...openssl-v0.10.80) --- updated-dependencies: - dependency-name: rmcp dependency-version: 1.4.0 dependency-type: direct:production dependency-group: cargo - dependency-name: openssl dependency-version: 0.10.80 dependency-type: indirect dependency-group: cargo - dependency-name: rmcp dependency-version: 1.4.0 dependency-type: direct:production dependency-group: cargo - dependency-name: openssl dependency-version: 0.10.80 dependency-type: indirect dependency-group: cargo ... Signed-off-by: dependabot[bot] <support@github.com>
dependabot
Bot
added
dependencies
|
cihatsarsilmaz
added a commit
to cihatsarsilmaz/quickstart-resources
that referenced
this pull request
Jun 8, 2026
Rust compiler only supports editions \"2015\" and \"2021\". The invalid \"2024\" edition causes immediate compilation failure with exit code 101. Changes: - mcp-client-rust/Cargo.toml: edition = \"2024\" → \"2021\" - weather-server-rust/Cargo.toml: edition = \"2024\" → \"2021\" This resolves the cargo build failure that cascaded into test failure. Fixes: PR modelcontextprotocol#143 test failure Root cause: Invalid Rust edition specification
|
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
The smoke tests listed tools and stopped there, so they could not catch a
broken structured result. They also ran only 5 of the 10 examples: the Go
and Ruby examples and the Rust client had no coverage at all.
mcp-test-client now calls every tool that declares an outputSchema and
checks the answer against it: the result must carry structuredContent,
and a tool with an array-rooted schema must return a top-level JSON array
while an object-rooted one must return an object. That second check is
the point - a server advertising {"type":"array"} and returning
{"result":[...]} passes a tools/list-only test and fails this one. The
client negotiates with mode "auto" so it exercises servers of either
protocol era.
Tool calls reach the live NWS API, so an unreachable upstream surfaces as
an error result. Those are reported as a skip rather than a failure;
someone else's outage should not fail the build.
mock-mcp-server moves to the low-level Server and advertises two tools,
one array-rooted and one object-rooted, with the schemas written out
literally. The array-rooted one is deliberate: clients that compile every
declared outputSchema at connect - as the Go and Rust clients now do -
fail here if they assume an output schema is always an object.
utils.sh no longer swallows build output. Builds ran with >/dev/null 2>&1
unconditionally, so a compile failure left no binary and the test
reported a downstream spawn ENOENT instead of the actual error - which is
exactly what made modelcontextprotocol#143 hard to diagnose. run_build prints the compiler
output when a build fails, and ensure_built can now build Go too.
check_dependency returns instead of exiting, so a missing toolchain fails
its own test and still lets the suite finish and print its summary.
Binaries are resolved through a helper that accounts for the .exe suffix,
so the suite is runnable on Windows as well as CI.
smoke-test.sh adds weather-server-go, mcp-client-go and mcp-client-rust,
taking coverage to 8 of 10. The Ruby examples stay out: the mcp gem caps
at protocol 2025-11-25 and cannot negotiate 2026-07-28.
CI gains a Go toolchain, without which the new Go tests cannot run, and
moves from Node 18 to Node 20 because the 2.0 MCP SDK packages require
it.
Requires the 2.0 beta SDK packages for the helpers, matching the servers
and clients under test.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. The model identifier moves to claude-sonnet-5, the current Sonnet. All four quickstart clients now name the same model; they had drifted onto three different ones, and the Rust client was on claude-sonnet-4-20250514, which is past end of life and warns on every run. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
The smoke tests connected to each server, listed its tools, and stopped
there, so they could not catch a broken structured result.
mcp-test-client now calls every tool that declares an outputSchema and
checks the answer against it: the result must carry structuredContent,
and a tool with an array-rooted schema must return a top-level JSON array
while an object-rooted one must return an object. That second check is
the point - a server advertising {"type":"array"} and returning
{"result":[...]} passes a tools/list-only test and fails this one. A tool
with no output schema is left alone, so this is not a new requirement on
any example.
The client negotiates with mode "auto": one server/discover probe,
falling back to the 2025-11-25 initialize handshake. That keeps it
working against every example as it stands today while also being able to
test a server that speaks 2026-07-28.
Tool calls reach the live NWS API, so an unreachable upstream surfaces as
an error result. Those are reported as a skip rather than a failure;
someone else's outage should not fail the build.
mock-mcp-server moves to the low-level Server and advertises two tools,
one array-rooted and one object-rooted, with the schemas written out
literally. The array-rooted one is deliberate: a client that compiles
every declared outputSchema when it connects will fail here if it assumes
an output schema is always {"type":"object"}, which is no longer true as
of protocol revision 2026-07-28.
utils.sh no longer swallows build output. Builds ran with >/dev/null 2>&1
unconditionally, so a compile failure left no binary behind and the test
reported a downstream spawn ENOENT instead of the actual error. That is
what makes a broken build hard to diagnose from CI logs alone, and modelcontextprotocol#143
is the current example of it. run_build prints the compiler output when a
build fails.
check_dependency returns instead of exiting, so a missing toolchain fails
its own test and still lets the suite finish and print its summary.
Binaries are resolved through a helper that accounts for the .exe suffix,
so the suite is runnable on Windows as well as in CI.
CI moves from Node 18 to Node 20, which the 2.0 MCP SDK packages require.
The test helpers move to those packages for the same reason; the examples
themselves are untouched by this change.
The Go examples and the Rust client are still uncovered. Each needs a
change inside its own directory first - both clients abort when no .env
file is present, so neither can be driven without credentials - so that
coverage lands alongside those changes rather than here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. The model identifier moves to claude-sonnet-5, the current Sonnet. All four quickstart clients now name the same model; they had drifted onto three different ones, and the Rust client was on claude-sonnet-4-20250514, which is past end of life and warns on every run. The client forwards `content` to the model and uses structured content as data, rather than sending the structured value to the model in place of the text. The two channels have different readers - the SDK documentation is explicit that content is what the model sees and structured content is for the application around it - and forwarding the structured value inverted that, which also meant the human-readable text each server carefully builds was never read by anything. The client now reports the item count from the structured array and forwards the text blocks to the model. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. The model identifier moves to claude-sonnet-5, the current Sonnet. All four quickstart clients now name the same model; they had drifted onto three different ones, and the Rust client was on claude-sonnet-4-20250514, which is past end of life and warns on every run. Each channel goes to its stated reader. `content` is what the model reads, so that is what the client forwards, narrowed to the text blocks. Structured content is for the application around the model - already validated against the declared schema - so the client uses it as data, reporting how many items came back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. The model identifier moves to claude-sonnet-5, the current Sonnet. All four quickstart clients now name the same model; they had drifted onto three different ones, and the Rust client was on claude-sonnet-4-20250514, which is past end of life and warns on every run. Each channel goes to its stated reader. `content` is what the model reads, so that is what the client forwards, narrowed to the text blocks. Structured content is for the application around the model - already validated against the declared schema - so the client uses it as data, reporting how many items came back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools now declare an outputSchema and return structuredContent alongside the human-readable text. get_alerts declares Vec<Alert> as its output schema, so its structured content is a top-level JSON array rather than an array nested in an object. Protocol revision 2026-07-28 is the first to allow this: through 2025-11-25 an outputSchema had to be object-rooted, forcing a wrapper key for what is naturally a list. No alerts is now simply [], not a special case. get_forecast returns an object, for contrast. Failure paths return a tool-level error result rather than a bare text result: a tool that declares an outputSchema MUST return conforming structured content, so a path with no data to return has to fail. The client compiles every declared outputSchema at connect time and validates results against it, per the spec's client-side SHOULD. rmcp does not do this for you; its docs point at the jsonschema crate, which is the one new dependency here. The client also prefers structuredContent when forwarding to the model. The client no longer treats a missing .env as fatal, and checks for ANTHROPIC_API_KEY after connecting rather than before. Connecting and listing tools needs no credentials, so this matches the Python and TypeScript clients, which report the missing key and exit cleanly - the behaviour the smoke tests rely on. This supersedes modelcontextprotocol#143. That PR bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump; the rewrite here was required either way, so the bump is folded in and taken further, to 3.0.0-beta.2 - the first version with the 2026-07-28 model. Two rmcp gaps worth knowing about, both discovered by connecting a TypeScript SDK client to this server: list_tools is hand-written. #[tool_handler] generates one that hardcodes ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549), and a strict client rejects the response outright. The macro skips generation when the impl defines the method. Without this workaround the server is unusable from such a client. get_info does not pin ProtocolVersion::V_2026_07_28. rmcp's server never implements server/discover - the string appears only in its client - so it cannot serve a modern-era opening, and pinning the version only overstates support. Note also that rmcp sends an array-rooted schema as written on every connection; it does not project it down to the object form older revisions require, the way the TypeScript SDK does. Adopting an array root is therefore a breaking change for pre-2026-07-28 clients. The README says so. The model identifier moves to claude-sonnet-5, the current Sonnet. All four quickstart clients now name the same model; they had drifted onto three different ones, and the Rust client was on claude-sonnet-4-20250514, which is past end of life and warns on every run. Each channel goes to its stated reader. `content` is what the model reads, so that is what the client forwards, narrowed to the text blocks. Structured content is for the application around the model - already validated against the declared schema - so the client uses it as data, reporting how many items came back. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
The smoke tests connected to each server, listed its tools, and stopped
there, so they could not catch a broken structured result.
mcp-test-client now calls every tool that declares an outputSchema and
checks the answer against it: the result must carry structuredContent,
and a tool with an array-rooted schema must return a top-level JSON array
while an object-rooted one must return an object. That second check is
the point - a server advertising {"type":"array"} and returning
{"result":[...]} passes a tools/list-only test and fails this one. A tool
with no output schema is left alone, so this is not a new requirement on
any example.
The client negotiates with mode "auto": one server/discover probe,
falling back to the 2025-11-25 initialize handshake. That keeps it
working against every example as it stands today while also being able to
test a server that speaks 2026-07-28.
Tool calls reach the live NWS API, so an unreachable upstream surfaces as
an error result. Those are reported as a skip rather than a failure;
someone else's outage should not fail the build.
mock-mcp-server moves to the low-level Server and advertises two tools,
one array-rooted and one object-rooted, with the schemas written out
literally. The array-rooted one is deliberate: a client that compiles
every declared outputSchema when it connects will fail here if it assumes
an output schema is always {"type":"object"}, which is no longer true as
of protocol revision 2026-07-28.
utils.sh no longer swallows build output. Builds ran with >/dev/null 2>&1
unconditionally, so a compile failure left no binary behind and the test
reported a downstream spawn ENOENT instead of the actual error. That is
what makes a broken build hard to diagnose from CI logs alone, and modelcontextprotocol#143
is the current example of it. run_build prints the compiler output when a
build fails.
check_dependency returns instead of exiting, so a missing toolchain fails
its own test and still lets the suite finish and print its summary.
Binaries are resolved through a helper that accounts for the .exe suffix,
so the suite is runnable on Windows as well as in CI.
CI moves from Node 18 to Node 24. The 2.0 MCP SDK packages require Node 20
or newer, but Node 20 reached end of life in April 2026, so this pins the
Active LTS rather than the floor.
The test helpers move to those packages for the same reason; the examples
themselves are untouched by this change.
The Go examples and the Rust client are still uncovered. Each needs a
change inside its own directory first - both clients abort when no .env
file is present, so neither can be driven without credentials - so that
coverage lands alongside those changes rather than here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
The smoke tests connected to each server, listed its tools, and stopped
there, so they could not catch a broken structured result.
mcp-test-client now calls every tool that declares an outputSchema and
checks the answer against it: the result must carry structuredContent,
and a tool with an array-rooted schema must return a top-level JSON array
while an object-rooted one must return an object. That second check is
the point - a server advertising {"type":"array"} and returning
{"result":[...]} passes a tools/list-only test and fails this one. A tool
with no output schema is left alone, so this is not a new requirement on
any example.
The client negotiates with mode "auto": one server/discover probe,
falling back to the 2025-11-25 initialize handshake. That keeps it
working against every example as it stands today while also being able to
test a server that speaks 2026-07-28.
Tool calls reach the live NWS API, so an unreachable upstream surfaces as
an error result. Those are reported as a skip rather than a failure;
someone else's outage should not fail the build.
mock-mcp-server moves to the low-level Server and advertises two tools,
one array-rooted and one object-rooted, with the schemas written out
literally. The array-rooted one is deliberate: a client that compiles
every declared outputSchema when it connects will fail here if it assumes
an output schema is always {"type":"object"}, which is no longer true as
of protocol revision 2026-07-28.
utils.sh no longer swallows build output. Builds ran with >/dev/null 2>&1
unconditionally, so a compile failure left no binary behind and the test
reported a downstream spawn ENOENT instead of the actual error. That is
what makes a broken build hard to diagnose from CI logs alone, and modelcontextprotocol#143
is the current example of it. run_build prints the compiler output when a
build fails.
check_dependency returns instead of exiting, so a missing toolchain fails
its own test and still lets the suite finish and print its summary.
Binaries are resolved through a helper that accounts for the .exe suffix,
so the suite is runnable on Windows as well as in CI.
The test helpers move to the 2.0 MCP SDK packages, which is where the
2026-07-28 support lives. The examples themselves are untouched.
Those packages require Node 20 or newer, so CI moves off Node 18. It goes to
Node 24, the Active LTS, rather than to the floor: Node 20 reached end of
life in April 2026.
The Go examples and the Rust client are still uncovered. Each needs a
change inside its own directory first - both clients abort when no .env
file is present, so neither can be driven without credentials - so that
coverage lands alongside those changes rather than here.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
The smoke tests connected to each server, listed its tools and stopped there, so they could not catch a broken structured result. mcp-test-client now calls every tool that declares an outputSchema and checks the answer against it: the result must carry structuredContent, and a tool with an array-rooted schema must return a top-level JSON array rather than an object wrapping one. Tools with no output schema are left alone, so this is not a new requirement on any example. The client negotiates with mode "auto", so it exercises servers of either protocol era. Tool calls reach the live NWS API; an error result is reported as a skip rather than a failure. mock-mcp-server moves to the low-level Server and advertises one array-rooted and one object-rooted tool, with the schemas written out literally. A client that compiles every declared outputSchema at connect time fails against the array-rooted one if it assumes output schemas are always objects. utils.sh no longer swallows build output. A failed build left no binary behind and the test reported a downstream spawn ENOENT instead of the compiler error, which is what makes a broken build hard to diagnose from CI logs; modelcontextprotocol#143 is the current example. check_dependency returns instead of exiting, so a missing toolchain fails its own test and the suite still prints its summary. Binaries resolve through a helper that accounts for the .exe suffix. The test helpers move to the 2.0 MCP SDK packages, where the 2026-07-28 support lives; the examples themselves are untouched. Those require Node 20 or newer, so CI moves off Node 18 to Node 24, the Active LTS - Node 20 reached end of life in April 2026. The Go examples and the Rust client stay uncovered here. Both clients abort when no .env file is present, so that coverage lands with those examples. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
olaservo
added a commit
to olaservo/quickstart-resources
that referenced
this pull request
Jul 26, 2026
Both tools declare an output_schema and return structured_content alongside the text. get_alerts declares Vec<Alert>, so it answers with a top-level JSON array rather than an array nested in an object, which protocol revision 2026-07-28 is the first to allow. "No alerts" is simply []. get_forecast returns an object, for contrast. Error paths return a tool-level error: a tool declaring an output_schema MUST return conforming structured content, so a path with no data has to fail. The client compiles every declared outputSchema at connect time and validates results against it. rmcp does not do this; its docs point at the jsonschema crate, which is the one new dependency here. Each channel goes to its stated reader: content is forwarded to the model, structured_content is used as data, reporting how many items came back. A missing .env is no longer fatal, and the API key is checked after connecting rather than before. This supersedes modelcontextprotocol#143, which bumped rmcp 0.3 -> 1.4 and failed CI because the 0.3 #[tool] macro API does not survive the jump. The rewrite was required either way, so the bump is folded in and taken to 3.0.0-beta.2, the first version with the 2026-07-28 model. list_tools is hand-written. #[tool_handler] generates one hardcoding ttl_ms: None, cache_scope: None, but both are required on a paginated result at 2026-07-28 (SEP-2549) and a strict client rejects the response outright. get_info does not pin ProtocolVersion::V_2026_07_28 either: rmcp's server never implements server/discover, so pinning would overstate support. Model identifier moves to claude-sonnet-5, replacing claude-sonnet-4-20250514, which is past end of life. Note that rmcp sends an array-rooted schema as written on every connection rather than projecting it down, so an older client rejects the tool list. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Bumps the cargo group with 2 updates in the /mcp-client-rust directory: rmcp and openssl.
Bumps the cargo group with 2 updates in the /weather-server-rust directory: rmcp and openssl.
Updates
rmcpfrom 0.8.1 to 1.4.0Release notes
Sourced from rmcp's releases.
... (truncated)
Commits
4628720chore: release v1.4.0 (#779)65d2b29fix(server): remove initialized notification gate to support Streamable HTTP ...a7b5700fix: pass GIT_TOKEN to release-plz CLI (#798)8a8c036chore: update Rust toolchain to 1.92 (#797)34d0bc6fix: upgrade rustc in actions (#796)45a4cc5feat: add Default and constructors to ServerSseMessage (#794)5f43283feat: add meta to elicitation results (#792)be321a4feat(macros): auto-generate get_info and default router (#785)5891b45refactor: unify IntoCallToolResult Result impls (#787)d98248aci: add --locked to release-plz install (#786)Updates
opensslfrom 0.10.79 to 0.10.80Release notes
Sourced from openssl's releases.
Commits
35be7aeRelease openssl 0.10.80 and openssl-sys 0.9.116 (#2639)19eceb2Fix output buffer overflow in cipher_update_inplace for AES key-wrap-with-pad...b460eb3Prefer Homebrew openssl@4 and stop looking for openssl@1.1 (#2633)Updates
rmcpfrom 0.3.0 to 1.4.0Release notes
Sourced from rmcp's releases.
... (truncated)
Commits
4628720chore: release v1.4.0 (#779)65d2b29fix(server): remove initialized notification gate to support Streamable HTTP ...a7b5700fix: pass GIT_TOKEN to release-plz CLI (#798)8a8c036chore: update Rust toolchain to 1.92 (#797)34d0bc6fix: upgrade rustc in actions (#796)45a4cc5feat: add Default and constructors to ServerSseMessage (#794)5f43283feat: add meta to elicitation results (#792)be321a4feat(macros): auto-generate get_info and default router (#785)5891b45refactor: unify IntoCallToolResult Result impls (#787)d98248aci: add --locked to release-plz install (#786)Updates
opensslfrom 0.10.79 to 0.10.80Release notes
Sourced from openssl's releases.
Commits
35be7aeRelease openssl 0.10.80 and openssl-sys 0.9.116 (#2639)19eceb2Fix output buffer overflow in cipher_update_inplace for AES key-wrap-with-pad...b460eb3Prefer Homebrew openssl@4 and stop looking for openssl@1.1 (#2633)Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting
@dependabot rebase.Dependabot commands and options
You can trigger Dependabot actions by commenting on this PR:
@dependabot rebasewill rebase this PR@dependabot recreatewill recreate this PR, overwriting any edits that have been made to it@dependabot show <dependency name> ignore conditionswill show all of the ignore conditions of the specified dependency@dependabot ignore <dependency name> major versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's major version (unless you unignore this specific dependency's major version or upgrade to it yourself)@dependabot ignore <dependency name> minor versionwill close this group update PR and stop Dependabot creating any more for the specific dependency's minor version (unless you unignore this specific dependency's minor version or upgrade to it yourself)@dependabot ignore <dependency name>will close this group update PR and stop Dependabot creating any more for the specific dependency (unless you unignore this specific dependency or upgrade to it yourself)@dependabot unignore <dependency name>will remove all of the ignore conditions of the specified dependency@dependabot unignore <dependency name> <ignore condition>will remove the ignore condition of the specified dependency and ignore conditionsYou can disable automated security fix PRs for this repo from the Security Alerts page.