Skip to main content
Glama
Crawlora-org

Crawlora MCP

Official

audible_charts

Fetch a page of an Audible chart to see ranked titles with real chart position, price, and rating, filtered by category, language, duration, or membership level.

Instructions

Get an Audible chart (audible.com/charts). Returns one page of an Audible chart — a ranked list with real chart position, price, and rating. This endpoint is less stable than the rest of this family. Its own filters (category, access level, language, duration, Audible-Originals-only) were individually verified to actually change results. category_id, access_level, and content_type=podcasts are mutually exclusive.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based result page, default 1, 20 results per page
chartNoChart type, default most_listened
durationNoRuntime-length filter, default all
languageNoLanguage filter, default all
category_idNoRestrict to a category id from GET /audible/categories
access_levelNoMembership access level, default all
content_typeNoContent type, default audiobooks
originals_onlyNoRestrict to Audible Originals only

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.17.5
    • addedInput schema / properties / access_level / enum
      Added value: +[
      +  "all",
      +  "free",
      +  "plus",
      +  "premium"
      +]
    • addedInput schema / properties / chart / enum
      Added value: +[
      +  "most_listened",
      +  "bestselling"
      +]
    • addedInput schema / properties / content_type / enum
      Added value: +[
      +  "audiobooks",
      +  "podcasts"
      +]
    • addedInput schema / properties / duration / enum
      Added value: +[
      +  "all",
      +  "oneHourLess",
      +  "oneToThreeHour",
      +  "threeToSixHour",
      +  "sixToTenHour",
      +  "tenToTwentyHour",
      +  "twentyHourMore"
      +]
    • addedInput schema / properties / language / enum
      Added value: +[
      +  "all",
      +  "danish",
      +  "english",
      +  "french",
      +  "german",
      +  "italian",
      +  "japanese",
      +  "polish",
      +  "portuguese",
      +  "russian",
      +  "spanish",
      +  "swedish"
      +]
  2. Addedv1.16.0

TDQS

A3.8/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 burden and does meaningfully: it discloses the return contents, the one-page/ranked nature, that the endpoint is 'less stable than the rest of this family,' and that its filters were individually verified to change results. It stops short of noting auth needs, rate limits, or total page counts, so it is strong but not exhaustive.

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?

Four sentences, front-loaded with purpose then return shape, followed by stability and constraint notes. Each sentence carries information, though the stability remark could be tightened without losing 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 an 8-parameter tool with no annotations and no output schema, the description covers return contents, page semantics, stability caveat, filter behavior, and a cross-parameter constraint. The remaining gap (pagination limits, category_id source) is partly covered by the schema, so it is largely complete.

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

Parameters4/5

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

Schema coverage is 100%, so the baseline is 3, and the description earns above-baseline by adding a constraint absent from the schema: category_id, access_level, and content_type=podcasts are mutually exclusive. It also enumerates the filter families, though it does not explain individual enum values.

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?

States a specific verb and resource ('Get an Audible chart') plus the concrete return shape (ranked list with chart position, price, rating). This is clear on its own, but it never distinguishes itself from the closely-named sibling audible_author_charts, leaving the agent to infer which chart tool to pick.

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?

The mutual-exclusivity note ('category_id, access_level, and content_type=podcasts are mutually exclusive') gives real usage constraints. However, there is no explicit when-to-use vs alternatives guidance against siblings like audible_author_charts, audible_editorial_list, or audible_search, so routing is left to inference.

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