Fetch one page of Audible's ranked author chart, providing rank, author identity, image metadata, and canonical author URI for tracking top authors.
Get Audible's top-author chart. Returns one page of Audible's ranked author chart. It exposes only rank, author identity, image metadata when available, and a canonical author URI; author detail is not included.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | 1-based result page, default 1 |
Changes observed during successful MCP inspections.
v1.17.5Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations and no output schema, the description carries the full burden and does so reasonably well: it discloses that exactly one page is returned, enumerates the fields exposed (rank, author identity, image metadata when available, canonical author URI), and explicitly excludes author detail. It does not mention page size or total available pages.
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 short clauses, purpose front-loaded, with the field list and the exclusion following in an efficient order. No 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 one-parameter read-only chart endpoint with no annotations and no output schema, the description covers purpose, paging behavior, and return contents, which is close to sufficient. The remaining gap is how many results per page and whether more pages exist.
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% and the single 'page' parameter is already documented as 1-based with a default. The description adds nothing about pagination depth or page size, so the baseline 3 applies.
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 ('Get Audible's top-author chart') and pairs it with a precise scope statement ('ranked author chart'). It is readily separable from the sibling audible_charts because it names authors specifically, though it never explicitly contrasts itself with that sibling.
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 note that 'author detail is not included' implicitly steers the agent elsewhere for author-level data, but no alternative tool is named and there is no when-to-use guidance. Usage is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.