Search, read and cite technical books whose code examples run on each edition's pinned versions.
Scored across 6 tools
Most tools target distinct resources/actions: list/search books, contents, section reading, code validation, and edition changes. check_code and get_changes both can report changes since an edition, but check_code is scoped to validating a printed code while get_changes is book-level history; descriptions make the boundary mostly clear.
All six tools use snake_case verb_noun names (check_code, get_changes, get_contents, get_section, list_books, search_books), with no mixed conventions. The pattern is predictable and readable.
Six tools is well-scoped for a book/edition content server; each tool covers a distinct operation (discover, navigate, read, search, validate, inspect changes). No obvious bloat or thinness.
Core lifecycle is covered: list books, get contents, read sections, search passages, check edition codes, and inspect changes. Minor gaps exist—no direct get_book by slug and no list_topics for valid topic IDs—but agents can work around via list_books and documented examples.
Check an edition code, the 8 characters printed on a copy of a Rolling Edition book (such as 483B-Z9SS): "current", "out_of_date" with the current edition and what changed since, or "not_found". A match says which edition the code names; it doesn't prove a copy is authentic.
| Name | Required | Description | Default |
|---|---|---|---|
| code | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so safety is covered. Beyond that, the description discloses the full outcome set (current, out_of_date with the current edition and what changed since, not_found) and adds a meaningful limit: a match identifies the edition a code names but does not prove a copy is authentic. That qualification is real behavioral context an agent would otherwise misread as a verification guarantee.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, no filler. The subject, the input format, and the possible results are front-loaded, and the authenticity caveat is placed last where it reads as a qualification rather than a distraction.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
This is a single-parameter read tool with an output schema, so the description does not need to document return structure. It covers input meaning, result states, and the key interpretive caveat; only the absence of sibling routing guidance leaves a small gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the parameter burden, and it does: the single argument is described as the 8 characters printed on a copy of the book, with a formatted example. It does not mention case sensitivity or how to handle malformed input, which keeps it below a 5.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a specific verb (check) and resource (an edition code) and pins down exactly what an edition code is: the 8 characters printed on a copy of a Rolling Edition book, with a concrete example (483B-Z9SS). It also enumerates the three outcomes, so an agent can tell this apart from get_contents or search_books without consulting the schema.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Implicit usage is clear from the framing: the caller has a physical code in hand and wants to validate it. However, no sibling tool is named and no explicit when-not condition is given, so an agent must infer that this tool is for code lookup while search_books and get_contents cover other discovery paths.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
What changed in a book's editions, newest first: each edition's date, the kinds of change, its summaries, and the sections and examples it changed. Give since_edition for the editions after one you know, such as the edition a reader's copy names.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | ||
| to_edition | No | ||
| since_edition | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, non-destructive, closed-world behavior. The description adds useful behavioral context: results are ordered newest first and enumerate change kinds, summaries, sections, and examples. It does not discuss permissions or limits, but with annotations that is acceptable.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences, front-loaded with the return scope and then the key optional parameter guidance. No redundant restatement of annotations or schema.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Output schema and annotations cover return shape and safety, and the description explains ordering and since_edition. However, to_edition is undocumented and there is no sibling routing, leaving a gap for a 3-parameter tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must carry parameter meaning. It explains since_edition well with an example, but leaves to_edition completely undefined and only implicitly covers book.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific resource and scope: changes in a book's editions, newest first, including dates, change kinds, summaries, sections, and examples. The edition-change focus is clear, though it does not explicitly differentiate itself from siblings like get_contents or get_section.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides concrete guidance for since_edition, including a reader-copy example, which implies using it to track changes after a known edition. It does not say when to choose this over get_contents/get_section or when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
A book's chapters and sections, in reading order, each with the ID that get_section takes. book is the book's slug from list_books, such as "open-table-formats".
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | ||
| edition | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world, non-destructive behavior, so the safety profile is covered. The description adds useful context the annotations cannot: contents are ordered by reading sequence, are hierarchical (chapters and sections), and expose identifiers for downstream calls. It does not mention pagination or behavior for unknown/invalid slugs or a missing edition.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short sentences with zero filler; the return shape and ordering come first, followed by the argument's provenance. Every clause earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists, so return values need not be restated, and the workflow links to list_books and get_section are strong. However, for a tool whose schema has no descriptions, omitting the `edition` parameter entirely leaves a real gap.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description must carry all parameter meaning, and it fully explains `book` as a slug from list_books with a concrete example. The second parameter, `edition`, is never mentioned, leaving half the surface undocumented in both schema and prose.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the resource precisely (a book's chapters and sections, in reading order) and explains the payload carries IDs that get_section consumes, which distinguishes it from get_section itself. It lacks an explicit verb like "list" or "returns", but the intent is unmistakable.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states where the `book` argument comes from (list_books) and what to do with the result (pass IDs to get_section), giving a clear place in the workflow. It offers no explicit exclusions or when-not-to-use guidance versus search_books or get_section.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one section of a book as Markdown, with its subsections, its code examples (each with the versions it was run on and whether it passes) and its citation block. A chapter's ID gives the chapter's opening. A long section comes in pages: pass the next_cursor you were given as cursor for the next one. An earlier ID of a section still works, and the answer says what it's called now.
| Name | Required | Description | Default |
|---|---|---|---|
| book | Yes | ||
| cursor | No | ||
| edition | No | ||
| section_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish readOnly/idempotent/non-destructive, and the description adds substantive behavior on top: response composition (subsections, code blocks with run versions and pass status, citations), pagination mechanics, and ID-redirect behavior where the answer reports the section's current name. It does not state rate limits or size limits, which keeps it below a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Four sentences, each carrying distinct information, with the payload description front-loaded and pagination plus ID behavior following. The opening sentence is dense with parentheticals but nothing is redundant.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema exists so return values need not be detailed, but with four parameters at 0% schema coverage the description should clarify `book` and `edition` (e.g., accepted identifier format, default edition behavior) to be fully sufficient. Pagination and ID-redirect behavior are adequately covered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the burden. It does valuable work on two parameters - `cursor` (use the `next_cursor` from the previous response) and `section_id` (chapter IDs accepted, old IDs tolerated) - but leaves `book` and especially `edition` completely unexplained, so it only partially compensates for the coverage gap.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource ('Read one section of a book as Markdown') and enumerates what the read includes: subsections, code examples with versions and pass status, and the citation block. It does not name a sibling to contrast with, so the agent must infer the boundary with get_contents or search_books, but the scope is otherwise unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives real operational guidance: a chapter ID yields the chapter opening, a long section is paginated via the returned `next_cursor`, and stale IDs still resolve. It never says when to choose this over get_contents or check_code, so the when-to-use versus alternatives is only implied by the description of what is returned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List Rolling Edition's books: each one's slug, title, summary, level, areas and skills, its current edition, the date its examples last passed, how many of its examples pass, and its link. Give topic, an area or skill ID such as "data-engineering" or "large-language-models", to list only the books on it.
| Name | Required | Description | Default |
|---|---|---|---|
| topic | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=false, so the safety profile is fully covered by structured data. The description adds the useful behavioral detail that omitting `topic` returns the full catalogue and that filtering is by area or skill. It says nothing about result ordering, pagination, or result-size limits, which are the remaining behavioral unknowns for a list endpoint.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with the verb and resource, then the field inventory, then the optional filter. The field enumeration is long but each item tells the agent what it can rely on, so it earns its space. Minor cost: the field list duplicates what the output schema likely already declares.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With an output schema present, the description does not need to explain return values, and with rich read-only annotations it does not need to explain safety. Against that lower bar it covers scope, contents, and the single optional filter adequately. The only real gap is absence of any statement about ordering or result limits on a catalogue listing.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description carries the full burden for the single `topic` parameter, and it does so well: it identifies it as an area or skill ID and supplies two concrete example values ("data-engineering", "large-language-models"), plus the effect of supplying it. What is missing is failure behavior for an unrecognized ID.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource ("List Rolling Edition's books") and then enumerates exactly what each entry contains — slug, title, summary, level, areas and skills, edition, last-passed date, pass count, and link. That is far more specific than a generic list tool. It stops short of naming the sibling `search_books` to draw the listing-vs-searching distinction, which keeps it off a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It states the one filtering condition — pass `topic` to restrict to a given area or skill — which implies the default is to return everything. But it never says when to prefer this over `search_books` or `get_section`, and gives no exclusion or precondition guidance. Usage is inferable rather than prescribed.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Find the passages that best match query, by its words, across every book or within one (book, a slug). Each result has its book, edition, section ID and title, a snippet, and the citation block to cite it with. Read a whole result with get_section. limit is 5 unless you ask for up to 10.
| Name | Required | Description | Default |
|---|---|---|---|
| book | No | ||
| limit | No | ||
| query | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare read-only, idempotent, closed-world behavior, so the description is free to add the useful non-annotation details: the shape of each result (book, edition, section ID, title, snippet, citation) and the default/maximum limit. It does not discuss ranking behavior beyond 'best match', which is a small residual gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Three tight sentences: scope and matching first, result contents second, follow-on tool and limit default last. Nothing is repeated from the annotations and no sentence is filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description still sketches the result fields and how to cite them, and covers the default/limit behavior, so an agent has everything needed to call and consume the tool. Nothing material is missing for a three-parameter search.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description has to carry all parameter meaning and largely does: `book` is explained as a slug that scopes the search, and `limit` is documented with a default of 5 and a ceiling of 10, which the schema does not express. `query` is only implicitly described as words to match rather than given format guidance.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource (find passages matching `query` by words) and pins down the scope: every book or restricted to one via `book`. It also names the sibling `get_section` for the follow-on action, so the agent can distinguish search from retrieval without inspecting schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear context of use (find matching passages, then read a whole result with get_section) but does not state when *not* to search, e.g. when to go straight to get_section if the section is already known. Adequate routing guidance with a minor gap.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
check_codeget_changesget_contentsget_sectionlist_bookssearch_booksSearch and read Rust documentation for the standard library and any crate on crates.io
Federated search of books and papers, BibTeX/RIS citations, open-access retrieval and reading.
Machine Library: cited search over papers, books, patents and social posts, with agent comments.
Search public open-source code, documentation, metadata, vulnerabilities, changelogs, and examples.
Add one secure layer between your agents and this server.
