Search a catalog of 1.7 million books and find books by mood, vibe, pace or genre. Read-only.
Scored across 6 tools
Each tool has a clearly distinct retrieval strategy: single lookup by id/ISBN (get_book), author lookup (get_author), title/author text search (search_books), tag-based discovery (find_books_by_mood), adjacency (get_similar_books), and popularity (get_trending_books). The descriptions make the required inputs explicit, so an agent can pick correctly without guessing.
All names are snake_case verb_noun forms (get_book, get_author, search_books, get_similar_books, get_trending_books), with only find_books_by_mood using a longer 'find_..._by_...' pattern. The mix of get/search/find verbs is semantically motivated but a minor deviation from a single predictable pattern.
Six tools is well-scoped for a read-only book discovery catalog: one per retrieval modality (lookup, search, tag discovery, similarity, trending, author) with no filler. Each tool earns its place and there is no redundancy.
The discovery surface is solid—single-book and author lookups, text search, tag exploration, similarity, and trending all exist. Minor gaps remain: no pagination beyond 10 results, no series/genre browse endpoint, and no shelf/user-list operations, which agents may need for deeper traversal.
Find books in the ShelfClub catalog by mood, vibe, pace and genre tags. At least one tag is needed. Books that carry every requested tag are listed first, most read first; when there are fewer of those than asked for, books that carry some of the tags follow, and matchAll says how many of the books returned carry every tag. Each book is returned with its own tags. Returns up to 10 books, each with its ShelfClub id, authors, description, reader rating, series and shelfclub.app link. The tags are machine-generated, or voted for by at least three readers of the book.
| Name | Required | Description | Default |
|---|---|---|---|
| pace | No | How quickly the story moves. | |
| limit | No | How many books to return. | |
| moods | No | How the book feels to read. | |
| vibes | No | The kind of reading experience. | |
| genres | No |
| Name | Required | Description |
|---|---|---|
| books | No | |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| hasMore | No | Whether more books carry these tags than were returned. |
| matchAll | No | How many of `books`, counted from the first, carry every tag asked for. The books after them carry some of the tags. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the read-only, idempotent annotations, the description explains ranking behavior: exact tag matches come first, most-read first, with partial matches following. It also discloses the matchAll signal, the cap of up to 10 results, returned book fields, and that tags are machine-generated or reader-voted, which is substantial behavioral context.
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?
The description is front-loaded with the core purpose, then adds ranking, result cap, and tag provenance in a logical order. It is generally efficient, though the return-field list partially duplicates what the output schema already provides.
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?
Given the existing output schema and annotations, the description covers the key non-obvious behavior an agent needs: tag requirement, ranking and fallback behavior, matchAll meaning, result cap, and tag trust provenance. Nothing critical for correct invocation appears to be missing.
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 coverage is high at 80%, so the schema already documents most parameter semantics, including pace, limit, moods, and vibes enums. The description adds the important constraint that at least one tag is needed, but it does not clarify the genres parameter or add meaning beyond the schema for limit and pace.
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 gives a specific verb and resource: it finds books in the ShelfClub catalog using mood, vibe, pace, and genre tags. That tag-based discovery focus distinguishes it from generic catalog siblings such as search_books, though no sibling is named explicitly.
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 a concrete usage requirement — at least one tag is needed — but gives no explicit guidance on when to choose this tool over search_books, get_similar_books, or get_trending_books. The intended use is implied by the tag-based filtering, not fully spelled out.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up an author in the ShelfClub catalog by ShelfClub author id, which get_book returns for the authors of a book. Returns the author's name, biography, birth and death dates and shelfclub.app link. With include_books, also returns up to 10 of their books, the most recently published first, each with its ShelfClub id, description, reader rating, series, shelfclub.app link, and mood, vibe, pace and genre tags (machine-generated, or voted for by at least three readers of the book).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ShelfClub id of the author, from the `authorLinks` of a get_book result. | |
| include_books | No | Also return up to 10 of the author's books. |
| Name | Required | Description |
|---|---|---|
| books | No | With `include_books`: the most recently published first. |
| author | No | |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| booksTotal | No | With `include_books`: how many of their books the catalog has. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely new behavior: the optional expansion is capped at 10 books, ordered by most recent publication, and tags are either machine-generated or backed by at least three reader votes — details neither the annotations nor the schema disclose.
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 lookup action and id source before the optional expansion, with no filler. The second sentence's long enumeration of returned book fields partially duplicates the output schema, which keeps it from a 5.
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?
For a two-parameter read tool with an output schema and full annotation coverage, everything an agent needs is present: id provenance, the optional expansion's cap and ordering, and tag provenance semantics. No material gap remains.
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 coverage is 100%, so the baseline is 3, but the description earns more by specifying what include_books actually yields: up to 10 books, newest first, with named fields. That is more than the schema's bare 'Also return up to 10 of the author's books.'
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 ('Look up an author in the ShelfClub catalog') and immediately pins the scope to a ShelfClub author id. It also distinguishes itself from the sibling get_book by explaining the provenance link ('which get_book returns for the authors of a book'), so an agent can route between the two without opening a 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?
It gives clear context for when this tool applies and how to obtain the required id from a get_book result, which is the main workflow trigger. It stops short of stating when not to use it or naming an explicit alternative for author search, so it is strong but not fully explicit about alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Look up one book in the ShelfClub catalog, by its ShelfClub id or by ISBN. Returns its description, authors, reader rating, series, an edition (ISBN, page count, publisher, publication date, language), its shelfclub.app link, and its mood, vibe, pace and genre tags (machine-generated, or voted for by at least three readers of the book). A lookup by id also returns the ShelfClub author id of each author that has an author record, and which of the moods, vibes and pace readers of the book voted for, with how many did.
| Name | Required | Description | Default |
|---|---|---|---|
| id | No | The ShelfClub id of the book, as the other tools return it. Give this or `isbn`, not both. | |
| isbn | No | An ISBN-10 or ISBN-13, with or without hyphens. |
| Name | Required | Description |
|---|---|---|
| book | No | |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover the read-only, idempotent safety profile, and the description adds real detail beyond them: the id path returns extra data (author ids, per-mood/vibe/pace vote counts) that the ISBN path does not, and tags are either machine-generated or reader-voted with a threshold of three voters. This provenance detail is the kind of thing an agent cannot infer from annotations.
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 what the tool does before enumerating the return set. The second sentence is dense and comma-heavy, listing many fields in one breath, but nearly every clause carries information and nothing is padding.
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 the long return-field enumeration is partly redundant, but it does no harm and the id-vs-ISBN behavioral difference is only spelled out here. Nothing an agent needs to invoke the tool correctly is missing.
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 coverage is 100%, so the baseline is 3, but the description adds semantics the schema lacks: the choice of parameter changes what comes back, with the id lookup returning author IDs and vote breakdowns while the ISBN lookup does not. That is meaningful guidance an agent would otherwise miss.
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 ('look up one book') and resource ('ShelfClub catalog'), plus the two keys used to identify it (ShelfClub id or ISBN). This implicitly separates it from the sibling search_books and find_books_by_mood tools, which return sets rather than a single record, but no sibling is named explicitly.
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?
The 'by id or ISBN, not both' rule lives in the schema, not in the description, and nothing states when this single-record lookup should be preferred over search_books or get_similar_books. Usage is only implied by the phrase 'look up one book'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the books in the ShelfClub catalog whose mood, vibe, pace and genre tags overlap most with those of a given book, chosen from its 10,000 most-read books. The tags are machine-generated, or voted for by at least three readers of the book, and a book that has none has no similar books. Returns up to 10 books, each with its ShelfClub id, authors, description, reader rating, series, tags and shelfclub.app link.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The ShelfClub id of the book, as the other tools return it. | |
| limit | No | How many books to return. |
| Name | Required | Description |
|---|---|---|
| books | No | |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world safety, so the description's added value is the substantive context it supplies: the candidate universe (10,000 most-read books), tag provenance (machine-generated or voted by at least three readers), and the zero-tag failure mode. It does not discuss ordering guarantees or tie-breaking, which would have been the final detail.
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 dense sentences that front-load the core behavior, with the caveat and the return shape following in logical order. The return-field enumeration is somewhat listy, but nothing is wasted 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?
For a two-parameter read tool with full schema coverage, annotations, and an output schema, the description covers everything an agent needs in order to call it and interpret results. It slightly duplicates the output schema by listing returned fields.
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 100%, so both parameters are already documented, and the baseline is 3. The description reinforces the id semantics ('a given book') and the cap of up to 10 results, but adds no format or syntax detail beyond the schema.
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 (list) plus a precisely scoped resource (books with overlapping mood/vibe/pace/genre tags relative to a given book), including the candidate pool of the 10,000 most-read books. This is clearly distinguishable from siblings like find_books_by_mood or search_books.
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?
Usage context is clearly implied: call it with a book id when you want recommendations related to that book. It also states an edge-case rule — a book with no tags has no similar books — which helps an agent interpret an empty result rather than retry. No explicit exclusions or named alternatives, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the books trending on ShelfClub: the books its readers have been shelving come first, then the catalog's most widely read books. Returns up to 10 books, each with its ShelfClub id, authors, description, reader rating, series, shelfclub.app link, and mood, vibe and pace tags (machine-generated, or voted for by at least three readers of the book).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many books to return. |
| Name | Required | Description |
|---|---|---|
| books | No | |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the bar is lower; the description still adds real context — the ranking semantics, the 10-item ceiling, and the provenance of vibe/mood/pace tags (machine-generated or reader-voted with a 3-vote threshold). It does not mention pagination or whether the ranking is cached/fresh, but the added disclosure is well beyond the annotations.
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 core behavior and the ordering rule before the return payload. The parenthetical about tag provenance is dense but each clause carries information; nothing is padding.
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?
For a one-parameter read tool with an output schema and full annotation coverage, this is nearly complete: it explains ordering, cap, returned fields and tag provenance. Only ranking freshness/recency window is left unstated.
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 coverage is 100% and the single limit parameter is already documented with default 5 and maximum 10. The description only reinforces the cap ('up to 10 books') and adds no interpretation of what limit trades off against within the two-tier ordering, so the schema does the heavy lifting.
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 gives a specific verb and resource ('List the books trending on ShelfClub') and, crucially, defines the ranking rule (recently shelved first, then most-read), which is the entire distinguishing feature versus siblings like search_books or get_similar_books. An agent can tell what this returns without opening 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?
Usage is implied by the 'trending' framing but there is no explicit when-to-use/when-not guidance and no sibling is named as an alternative for related needs (e.g., mood-based discovery or title search). The agent must infer routing from the word 'trending'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the ShelfClub book catalog by title or author name. Returns up to 10 books, each with its ShelfClub id, authors, description, reader rating, series, shelfclub.app link, and mood, vibe, pace and genre tags (machine-generated, or voted for by at least three readers of the book).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many books to return. | |
| query | Yes | A book title, an author name, or both. |
| Name | Required | Description |
|---|---|---|
| books | No | |
| total | No | How many books in the catalog match, of which `books` is the first few. |
| status | Yes | "try_again_later": the service was busy and looked nothing up, so the other fields are absent. |
| exactMatch | No | False when nothing matched the query as written and `books` holds the closest titles instead. |
| tagProvenance | No | Where the moods, vibes, pace and genres come from. |
| retryAfterSeconds | No | With "try_again_later", when known: how long to wait. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, closed-world and non-destructive, so the safety profile is covered. The description adds real value beyond that: a hard result ceiling of 10, the full field set returned, and the provenance rule that mood/vibe/pace/genre tags are machine-generated or backed by at least three reader votes — a data-quality caveat the annotations cannot express.
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, with the search scope front-loaded and the return payload following. The parenthetical about how tags are sourced earns its place because it changes how an agent should present results.
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 full schema coverage and an output schema present, the definition covers what an agent needs to call it correctly, and the tag-provenance note is a genuine bonus. The only shortfall is the absent routing guidance against the five siblings.
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 coverage is 100%, so both `query` and `limit` are already documented, including the min/max on `limit`. The description restates the result cap ('up to 10 books') and the title-or-author semantics, which echoes rather than extends the schema. Baseline 3 is appropriate.
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 ('Search the ShelfClub book catalog') and narrows the search field to title or author name, which implicitly separates it from find_books_by_mood and get_trending_books. It does not name any sibling explicitly, so the differentiation is inferential rather than stated.
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?
The phrase 'by title or author name' implies when this tool applies, but there is no explicit guidance on when to prefer find_books_by_mood, get_book, or get_similar_books, and no statement of exclusions. The agent must infer routing from the sibling names.
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.
find_books_by_mood1 field changedOutput schema / properties / books / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."get_author3 fields changedInput schema / properties / id / descriptionPrevious value: -"The Shelfclub id of the author, from the `authorLinks` of a get_book result."New value: +"The ShelfClub id of the author, from the `authorLinks` of a get_book result."Output schema / properties / author / properties / id / descriptionPrevious value: -"The Shelfclub id of the author."New value: +"The ShelfClub id of the author."Output schema / properties / books / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."get_book4 fields changedInput schema / properties / id / descriptionPrevious value: -"The Shelfclub id of the book, as the other tools return it. Give this or `isbn`, not both."New value: +"The ShelfClub id of the book, as the other tools return it. Give this or `isbn`, not both."Output schema / properties / book / properties / authorLinks / descriptionPrevious value: -"The authors that have a Shelfclub author record. Present when the book was looked up by id, not by ISBN."New value: +"The authors that have a ShelfClub author record. Present when the book was looked up by id, not by ISBN."Output schema / properties / book / properties / authorLinks / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the author."New value: +"The ShelfClub id of the author."Output schema / properties / book / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."get_similar_books2 fields changedInput schema / properties / id / descriptionPrevious value: -"The Shelfclub id of the book, as the other tools return it."New value: +"The ShelfClub id of the book, as the other tools return it."Output schema / properties / books / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."get_trending_books1 field changedOutput schema / properties / books / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."search_books1 field changedOutput schema / properties / books / items / properties / id / descriptionPrevious value: -"The Shelfclub id of the book."New value: +"The ShelfClub id of the book."get_book1 field changedOutput schema / properties / book / properties / readerTagsAdded value: +{
+ "additionalProperties": false,
+ "description": "Which of the book's moods, vibes and pace at least `minimum` readers of the book voted for, and how many did. A mood, vibe or pace of the book that is not named here is machine-generated only. Present when the book was looked up by id, not by ISBN.",
+ "properties": {
+ "minimum": {
+ "description": "How many readers of a book must vote for a mood, vibe or pace before it is put on the book.",
+ "type": "number"
+ },
+ "moods": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alsoFromCatalog": {
+ "description": "True when the tag is machine-generated as well. False when the readers' votes are all that puts it on the book.",
+ "type": "boolean"
+ },
+ "readers": {
+ "description": "How many readers of the book voted for it.",
+ "type": "number"
+ },
+ "tag": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tag",
+ "readers",
+ "alsoFromCatalog"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ },
+ "pace": {
+ "anyOf": [
+ {
+ "additionalProperties": false,
+ "properties": {
+ "alsoFromCatalog": {
+ "description": "True when the tag is machine-generated as well. False when the readers' votes are all that puts it on the book.",
+ "type": "boolean"
+ },
+ "readers": {
+ "description": "How many readers of the book voted for it.",
+ "type": "number"
+ },
+ "tag": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tag",
+ "readers",
+ "alsoFromCatalog"
+ ],
+ "type": "object"
+ },
+ {
+ "type": "null"
+ }
+ ]
+ },
+ "vibes": {
+ "items": {
+ "additionalProperties": false,
+ "properties": {
+ "alsoFromCatalog": {
+ "description": "True when the tag is machine-generated as well. False when the readers' votes are all that puts it on the book.",
+ "type": "boolean"
+ },
+ "readers": {
+ "description": "How many readers of the book voted for it.",
+ "type": "number"
+ },
+ "tag": {
+ "type": "string"
+ }
+ },
+ "required": [
+ "tag",
+ "readers",
+ "alsoFromCatalog"
+ ],
+ "type": "object"
+ },
+ "type": "array"
+ }
+ },
+ "required": [
+ "minimum",
+ "moods",
+ "vibes",
+ "pace"
+ ],
+ "type": "object"
+}find_books_by_moodget_authorget_bookget_similar_booksget_trending_bookssearch_booksBook discovery using an AI-curated book catalog that eliminates hallucinations and surfaces lesser-known titles.
Read-only access to The Family Almanac's parenting-focused book library, grounded guide metadata...
Personalised book recommendations, filtered to what's on your public library's shelf right now.
Search books and authors, fetch editions, browse subjects, and resolve cover images.
Add one secure layer between your agents and this server.