Review Rust crate versions and dependencies with MCP

Run the workflow

1. 1. Find the crate and confirm its name

   Use rust_search_crates with a specific name or topic. Search is paginated and covers at most the first 1,000 relevance results. Inspect the crate source link before choosing a package with a similar name.

2. 2. Inspect an exact version

   Call rust_crate_details with name and version from your planned change or lockfile. Keep declared license, Rust-version requirement, feature metadata, yanked status and prerelease status visible. Omitting version requests the registry’s highest non-yanked stable version, which may differ from the most recently published version.

3. 3. Review declared dependencies

   Call rust_crate_dependencies with that same exact version. Optional, development, build and target-specific requirements are included when declared. Retain truncation flags. These requirements are not a resolved dependency tree; Cargo.lock and your target/features determine the versions your project uses.

4. 4. Check advisories and test the actual change

   Query osv_query_package with ecosystem crates.io and the identical package name/version. Inspect returned advisories and their original source links. No match is not a safety guarantee. Use project builds, tests and appropriate lockfile tooling to assess the actual dependency change.

What a useful result looks like

A review entry should retain the exact crate/version, crates.io source link, declared release fields and dependency requirements. Attach OSV source records separately. Document which checks still require your project configuration, lockfile or independent license review.

Know the limits

Registry metadata is publisher-supplied. No package files, README, source or installation is fetched or executed. Dependency requirements are not transitive resolution. Downloads are counts, not a quality score. Source metadata, availability and advisory coverage can change. Shared ToolCargo quotas and aggregate provider spacing apply.