Skip to main content
Glama
30book-mcp

30book-mcp

by sepehr071

Book details

sb_book
Read-onlyIdempotent

Fetches detailed data for one book by ID, including authors, publisher, prices, stock, ISBN, categories, rating, tags, and description, plus optional review blurb and stats.

Instructions

One book: authors, translators, publisher, prices, stock, ISBN, details, categories (codes for sb_browse), rating, tags, description.

Use after sb_search for details and author / publisher ids. review_text and stats only with include_blurb. Next: sb_similar, sb_reviews.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "book_id": "<book_id>"
    },
    "name": "sb_book"
  }
}

Input Schema

NameRequiredDescriptionDefault
book_idYesBook id from sb_search / listings, e.g. 167515.
max_charsNoCut description here (0 = no cut).
include_blurbNoAlso return review_text (blurb) and stats.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds conditional behavior the annotations cannot: review_text and stats are returned only when include_blurb is set, which changes the response shape. It does not mention failure modes for invalid book ids, but the core behavioral surprise is disclosed.

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?

The field list and the workflow guidance are both front-loaded, and there is no filler or restated title. The telegraphic fragments ('One book:', 'Next: sb_similar, sb_reviews.') are efficient but slightly clipped, costing a little readability without wasting words.

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 three-parameter read tool with no output schema, the description usefully enumerates the returned fields and flags the conditional blurb/stats payload, which is the main thing an agent must anticipate. Remaining gaps (max_chars truncation behavior, error handling for bad ids) are minor and largely covered by the schema.

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 book_id, max_chars and include_blurb are already documented, and the description's note that include_blurb yields review_text and stats largely restates the schema. The one value-add is that returned categories are codes usable with sb_browse; max_chars is not mentioned at all in the description, so the baseline 3 applies.

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?

The description opens with 'One book:' and enumerates the exact resource payload (authors, translators, publisher, prices, stock, ISBN, categories, rating, tags, description), so an agent immediately knows this is a single-book detail fetch by id. It further distinguishes itself by noting categories are 'codes for sb_browse', separating its role from the browse/search siblings.

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

Usage Guidelines5/5

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

It explicitly positions the tool in a workflow: 'Use after sb_search for details and author / publisher ids' tells the agent the prerequisite and the reason to call it. It also names follow-on tools ('Next: sb_similar, sb_reviews'), giving concrete alternatives for adjacent needs rather than leaving routing to inference.

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