release: 1.2.1

[hicksy]

What this changes

Clears the six open Dependabot alerts and the RustSec advisory that has been failing cargo-deny on main since late August, and moves crate publishing to Trusted Publishing.

The six alerts are three advisories counted twice, because Dependabot scans both lockfiles. All three are against rmcp 1.x, and none was reachable from a Dynoxide build: two cover client transports this crate never compiles, and the session-table leak sits behind rmcp's stateful_mode, which the MCP HTTP transport sets to false. 1.8.0 is the end of the 1.x line though, so there is no backport to take. The only code change is model::Content becoming ContentBlock.

rustls 0.23.45 clears RUSTSEC-2026-0285. It reaches the tree through dev-dependencies only and never shipped in a released artefact, but deny.toml holds ignore = [] and cargo-deny does not know the difference, so the check has been red. chacha20 moves off a yanked version while we are here.

Product goes to 1.2.1 and the crate to 2.0.1, both patches under the dependency row in docs/versioning.md. That page gains a short section on why an rmcp major does not take the crate major with it: McpServer implements rmcp's ServerHandler, which a strict reading makes part of the crate's API, and that impl exists for the transport rather than for third parties to host McpServer in their own rmcp server.

The crate now publishes with Trusted Publishing, so no long-lived registry token is stored on the repository. release-preflight gains a check that both publish workflows are registered on crates.io. It does that by asking for a token it is deliberately not entitled to and reading the refusal, which names the filenames that are configured, so the check never mints a token. Worth running before the tag goes up, since the crate is set to require Trusted Publishing and there is no token path to fall back on.

Checklist

• Tests added or updated
• cargo fmt --check and cargo clippy -- -D warnings pass locally
• CHANGELOG.md updated if this is a user-visible change
• Linked issue, discussion, or a short note explaining the motivation
• I agree my contribution is licensed under the project's terms
  (MIT License and Apache License, Version 2.0)

DynamoDB compatibility note

No change to observable behaviour. rmcp 1.8.0 and 2.2.0 declare the same five MCP protocol versions and the same LATEST, so nothing moves on the wire, and the suite passes unchanged at 2141 tests across 66 suites.

[github-actions]

Criterion Benchmark Results

Baseline is the per-benchmark median of the last 5 stored runs, so one unusually fast or slow runner cannot skew the comparison. The range column is the spread across those runs.

Benchmark	Baseline (ns/iter)	Range	Current	Change
batch_execute_statement_25	655,396 (n=1)	655,396 - 655,396	415,166	-36.7%
batch_get_item_100	1,404,603	814,524 - 1,451,464	928,437	-33.9%
batch_write_item_25	957,722	533,898 - 1,182,554	645,931	-32.6%
delete_item	46,152	26,334 - 53,068	32,652	-29.3%
get_item	14,424	8,000 - 15,127	9,523	-34.0%
put_item/put_item/large	269,725	115,520 - 278,302	139,343	-48.3%
put_item/put_item/medium	36,564	19,445 - 46,845	24,819	-32.1%
put_item/put_item/small	20,582	10,759 - 26,885	12,696	-38.3%
query_base_table	1,098,157	666,833 - 1,204,548	805,759	-26.6%
query_gsi	22,277	12,359 - 26,517	14,793	-33.6%
scan_with_filter	8,420,762	5,182,664 - 9,113,670	6,000,463	-28.7%
transact_write_items_4	224,380	112,673 - 267,776	153,940	-31.4%
update_item	166,166	85,461 - 185,342	138,605	-16.6%

All benchmarks within 50% of the 5-run median.

Runs in the baseline

• runs/2026-07-05-7d5fd8a
• runs/2026-07-24-f7e7d96
• runs/2026-07-30-bc2a16c
• runs/2026-07-30T220642Z-be8bfbc
• runs/2026-08-25T200503Z-54a2cb6