The "bookworm" server provides access to Rust crate type definitions, documentation and source code.
Bookworm is a Rust-based MCP server for querying Rust crate documentation. All 5 tools have proper verb-prefix naming (search_*, crate_*) and input schemas with types. Descriptions are present but vary in quality. The server demonstrates competent engineering with modular crate architecture, proper use of schemars for schema generation, and thoughtful response size limiting (256 KiB). However, several parameter descriptions are minimal, output schemas are not documented, and error handling lacks recovery guidance. Tool composition is sound, tools are single-responsibility and well-separated. No security issues detected (read-only operations, no secret parameters). STDIO-only transport limits accessibility.
Get the README for a specific crate version.
Get the resource for a crate. The following resource URIs are supported: - `crate://{crate_name}` - list crate versions - `crate://{crate_name}/{crate_version}` - get metadata - `crate://{crate_name}/{crate_version}/readme` - get readme content - `crate://{crate_name}/{crate_version}/items` - list item resources - `crate://{crate_name}/{crate_version}/src` - list source code resources - `crate://{crate_name}/{crate_version}/{path}` - get item/src resource
Search for type definitions and items within a Rust crate.
Get a list of most recent versions of a crate.
Search for Rust crates by name and query.
Output schemas not documented. The tool.rs implementation generates schemas from input structs via schemars, but there is no documentation of what fields are returned, their types, or structure. LLMs cannot plan follow-up calls without knowing the response shape.
Parameter descriptions are minimal (under 20 chars for some). 'The exact name of the crate' and 'Search query' lack actionable detail about format, length, character restrictions, or when to use.
crate_resource tool description is overly technical and focuses on URI syntax rather than WHEN to call it vs. alternative tools. The documentation of supported URIs is implementation detail; the agent needs a high-level explanation of intent. Tool descriptions should be LLM-optimized to guide selection.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | F | 46 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 49 | - | v1 |
No error handling guidance or recovery paths. Code limits responses to 256 KiB and includes a MAX_RESPONSE_SIZE_BYTES constant, but there is no documented tool response explaining truncation or how to paginate. Errors from crates.io or missing crates lack actionable guidance for LLMs.
'kinds' parameter in crate_search_items is typed as array but lacks enum constraints. Description says 'e.g., Struct, Enum, Trait, Function', examples should be replaced with formal enum declarations so LLMs pick valid options rather than hallucinating.