Skip to main content
Glama
30book-mcp

30book-mcp

by sepehr071

Reader reviews of a book

sb_reviews
Read-onlyIdempotent

Fetch a book's reader comments and rating summary by book ID, with optional full-text reviews to assess reader feedback.

Instructions

Reader comments and the rating summary; only the first comments on the page are available.

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_reviews"
  }
}

Input Schema

NameRequiredDescriptionDefault
book_idYesBook id from sb_search / listings, e.g. 167515.
full_textNoWhole texts instead of 400 chars.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.4.0

TDQS

C2.9/5.0
Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds one genuinely useful behavioral caveat — that only the first comments on the page are returned — but it is vague ('the page' is undefined, no count given) and says nothing about ordering or whether the rating summary is aggregate-only. That is real added value, but thin.

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 compact sentence with no filler, and the truncation caveat is placed right after the content statement. The phrasing 'the first comments on the page' is slightly clumsy but nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with full annotation coverage this is close to adequate, but it omits how many comments are returned, whether pagination exists, and whether the rating summary is a count/average. No output schema exists, so the description is the only place these expectations could be set, and it does not set them.

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 both book_id and full_text are already documented, including the 400-char default behavior. The description adds no further meaning to either parameter; baseline 3 applies when the schema carries the parameter burden.

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

Purpose3/5

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

The description names the resource ('reader comments and the rating summary') but supplies no verb (list/get/fetch) and never mentions the book it is keyed to — that link only comes from the title. An agent can infer the content type but not the operation shape (list vs. single fetch) from the description alone.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no indication of how this relates to sb_book or other siblings, and no prerequisites stated (e.g. that a book id must come from sb_search/listing first). The agent must fall back on the title and schema to decide when to call it.

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