Skip to main content
Glama
Sign In
Crawlora-org

Crawlora MCP

Official
by Crawlora-org
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Remote

datasets_apple_books_search

Search Apple Books public catalog records for ebooks, audiobooks, authors, and series using filters like genre, rating, narrator, and release date.

Instructions

Search Apple Books records. Searches named public ebook, audiobook, author, and series records stored from Apple's public catalog. kind values: book, audiobook, author, series, audiobook_series. Unavailable records are excluded. Sort: relevance (requires q), rating_count_desc, rating_desc, release_date_desc, name_asc, crawled_at_desc. Billing: 1 credit per returned record, minimum 2.

Input Schema

NameRequiredDescriptionDefault
qNoFull-text query over name, artist, series, narrator and description; max 256 characters
freeNoFilter for free titles
kindNoRecord kind: book, audiobook, author, series, audiobook_series
pageNo1-based page, default 1; page * page_size must be <= 10000
sortNoSort: relevance, rating_count_desc, rating_desc, release_date_desc, name_asc, crawled_at_desc
genreNoExact Apple Books genre label; use facet=genres to discover values, max 128 characters
artistNoExact author or artist name, max 128 characters
seriesNoExact series name, max 128 characters
countryNoExact discovery storefront country, max 128 characters
currencyNoExact currency code, max 128 characters
narratorNoExact audiobook narrator, max 128 characters
providerNoExact audiobook provider, max 128 characters
artist_idNoExact numeric Apple Books artist ID, max 128 characters
page_sizeNoPage size, default 20, max 100
publisherNoExact ebook publisher, max 128 characters
min_ratingNoMinimum average rating from 0 through 5
discovery_sourceNoExact crawl source, max 128 characters
min_rating_countNoMinimum rating count, 0 or greater

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.17.18

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations, the description carries the full load and adds real behavioral facts beyond the schema: unavailable records are filtered out, the relevance sort is only valid when q is supplied, and the call is billed at 1 credit per returned record with a 2-credit minimum. Missing are any notes on auth, rate limits, or what a response record contains, which prevents 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.

Conciseness4/5

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

Purpose is front-loaded in the first sentence, followed by scope, constraints, and billing in a compact run. It loses a point because re-listing the full `kind` and `sort` enum values duplicates the schema verbatim and pads the definition without adding meaning.

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

Completeness4/5

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

For a broad 18-parameter search with no annotations and no output schema, the description covers the essentials an agent needs to call it: scope, exclusion behavior, the q/sort dependency, and the credit cost model. It leaves the shape of returned records and the paging limits to the schema, which is acceptable given full parameter coverage.

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 description coverage is 100%, so the baseline is 3. The description largely restates the kind and sort enums already documented in the schema, and its only net-new parameter insight is the coupling between sort=relevance and q, which is genuinely useful but small relative to 18 parameters.

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?

The description opens with a concrete verb and resource ('Search Apple Books records') and enumerates the record kinds covered, so the agent knows exactly what corpus is queried. It does not, however, distinguish this tool from near-identical siblings such as apple_books_search, apple_books_audiobook_search, or datasets_apple_books_item, which sit in the same namespace.

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

Usage Guidelines3/5

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

Usage is only implied: 'Searches named public ebook, audiobook, author, and series records' and the note that unavailable records are excluded hint at scope, and the 'relevance (requires q)' note is a useful precondition. There is no statement of when to prefer this tool over apple_books_search or when to fall back to datasets_apple_books_facets for genre discovery.

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

Deploy Server

Other Tools