Skip to main content
Glama
30book-mcp

30book-mcp

by sepehr071

Genres, nations, awards and tags

sb_collections
Read-onlyIdempotent

Retrieves homepage collections—genres, nations, award lists, and tags—and returns their IDs for use with browsing tools.

Instructions

Home-page genres, nations, award lists and tags; ids go to sb_browse(kind=...).

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": "sb_collections"
  }
}

Input Schema

NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A3.6/5.0
Behavior3/5

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

The annotations already declare readOnly, idempotent, non-destructive and open-world, so the safety profile is covered. The description adds only that these are home-page curated lists and that returned ids are intended for sb_browse(kind=...) — useful but thin. It says nothing about volume, ordering, or what a collection entry contains.

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 short sentence with zero padding, and the resource list comes before the follow-up routing hint. Slightly telegraphic: 'Home-page genres' is compressed phrasing that takes a moment to parse as 'collections featured on the home page'.

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 zero-parameter, read-only discovery tool with no output schema and rich annotations, the description covers what it returns and what to do with the results. The main missing piece is any sense of the shape or size of the returned collection lists.

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?

The tool takes zero parameters, which is the baseline-4 case, and the description correctly implies no input is required. However, it introduces the notion of 'kind' values that are consumed by a different tool, without enumerating them, so the semantic link is only partially closed.

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?

Names the concrete resources returned (genres, nations, award lists, tags) and scopes them as home-page collections, which separates it from sibling tools like sb_browse and sb_categories. The verb is implicit rather than stated ('Home-page genres...' rather than 'List genres'), but the resource is unambiguous.

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

Usage Guidelines4/5

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

Gives an explicit continuation path: collect ids here, then pass them to sb_browse(kind=...). That is real routing guidance an agent can act on. It does not state exclusions (e.g., when to prefer sb_categories or sb_browse directly), so it falls short of a full when/when-not treatment.

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