guide-registry

List the book catalog

list_books

Read-only

List the books on this front's catalog, one row per work, with kind (book_profile|free_book_page) and availability (available|preorder) tags. Filter by kind, availability, topic or q (title/author); page with limit/offset.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "list_books"
  }
}

Input Schema

Name	Required	Description
`q`	No	Substring of the title or author.
`kind`	No	book_profile (a profile exists) \| free_book_page (held, no profile yet).
`limit`	No	Rows per page. Default 100, max 500.
`topic`	No	Substring of the book's genre or history branch.
`offset`	No	Rows to skip, for paging.
`availability`	No	available \| preorder.

Output Schema

Name	Required	Description	Default
`books`	Yes
`count`	Yes
`limit`	Yes
`offset`	Yes
`filters`	Yes
`api_version`	Yes
`total_matching`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 10, 2026

TDQS

A3.7/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnlyHint true, destructiveHint false, closed-world), so the bar is lower. The description adds real value by disclosing the result granularity ('one row per work') and that kind/availability are tag facets, but says nothing about default ordering, whether unavailable works are excluded, or how the total count is conveyed.

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?

A single dense sentence, front-loaded with the resource and granularity, then the filter and paging mechanics. No filler, though the clause packing the tag enumerations makes it slightly harder to scan than a two-sentence split would be.

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?

An output schema exists, so return values need not be explained, and all six parameters are optional and fully described in the schema. Filtering and paging are covered; only ordering/default sort and the behavior of a fully unfiltered call are left unstated, which is a minor gap.

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 and the schema already documents every parameter including the limit default/max. The description's parenthetical 'q (title/author)' and mention of topic restate schema semantics rather than extending them, adding no format or matching details beyond what is already structured.

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

Purpose5/5

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

States a specific verb and resource ('List the books on this front's catalog') and adds output granularity ('one row per work') plus the tag fields returned. An agent knows immediately this returns a paginated catalog listing rather than a single record, and the resource differs plainly from the list_answers/list_guides siblings.

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?

It explains how to narrow results ('Filter by kind, availability, topic or q') and how to page ('limit/offset'), which is helpful operational guidance. However, it gives no when-to-use vs when-not guidance, no mention of when to reach for a search-style sibling instead, and no note on whether unfiltered calls are expensive at the default page size.

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

All guide-registry tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?