Open Textbook Finder MCP

Look up an ISBN

lookup_isbn

Read-only

Validate an ISBN's check digit, then fetch Open Library edition details—title, authors, publisher, page count, free-copy status, and related editions newest first.

Instructions

ISBN lookup on Open Library: return the edition details plus the other editions of the same book. Inputs: isbn (10 or 13 digits, hyphens allowed). The check digit is tested first, so a typo is reported before any search. The reply has the title, authors, publisher, publish date, page count and edition name, and says whether a free copy is known. Related editions are listed newest first. Example prompt: "Look up ISBN 978-0-13-468599-1 and tell me what other editions exist."

Input Schema

Name	Required	Description	Default
`isbn`	Yes	The ISBN to look up, 10 or 13 digits, hyphens and spaces allowed.

Output Schema

Name	Required	Description
`url`	Yes	The Open Library page for this edition.
`isbn`	Yes	The ISBN as given, with hyphens and spaces removed.
`pages`	No	Number of pages, when known.
`title`	Yes	Title of the edition.
`isbn13`	Yes	The ISBN 13 form of the ISBN.
`authors`	Yes	Authors, when Open Library lists them.
`free_copy`	Yes	True when a free copy to read online is known.
`publishers`	Yes	Publishers of the edition.
`edition_name`	No	Edition name such as "3rd edition", when known.
`publish_date`	No	Publish date as Open Library gives it.
`free_copy_url`	No	Where to read the free copy, when there is one.
`related_editions`	Yes	Other editions of the same book, newest first.
`openstax_alternative`	No	A free OpenStax textbook on the same topic, when the built in catalog has one that matches the title.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.1.2Nov 2, 2026

addedOutput schema / properties / openstax_alternative

Added value: +{
+  "additionalProperties": false,
+  "description": "A free OpenStax textbook on the same topic, when the built in catalog has one that matches the title.",
+  "properties": {
+    "title": {
+      "description": "Title of the OpenStax textbook.",
+      "type": "string"
+    },
+    "url": {
+      "description": "The OpenStax page for the textbook.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "title",
+    "url"
+  ],
+  "type": "object"
+}

First observedv0.1.0Oct 27, 2026

TDQS

A4.1/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely new behavioral facts: check-digit validation runs before any network search so typos are reported early, related editions come back newest-first, and the response flags whether a free copy is known. These are exactly the kind of operational details annotations cannot convey.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with purpose and then inputs, then behavior, then output — a sensible order. Minor waste comes from restating the ISBN format already in the schema and enumerating return fields that the output schema already defines.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single required parameter with full schema coverage and an output schema, the description covers everything an agent needs: what it returns, validation behavior, ordering of related editions, and a usage example. Nothing essential is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and the schema already documents the ISBN format (10 or 13 digits, hyphens and spaces allowed), which the description largely restates. The one real addition is behavioral rather than semantic: that the check digit is validated first. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

"ISBN lookup on Open Library: return the edition details plus the other editions of the same book" gives a specific verb (lookup), resource (ISBN/edition), and scope (edition + related editions). It is clearly distinguishable in practice from find_older_edition and list_open_textbooks_by_subject, but the description never names those siblings, so the routing is left implicit.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states the concrete use case (look up an ISBN, surface other editions) and grounds it with an example prompt, so the agent can recognize when this tool applies. It stops short of any exclusion such as "use find_older_edition instead when you just want the previous edition" or "use find_free_textbook for free copies," so no explicit when-not guidance exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server