Read-only MCP server for verified book recommendations and reading lists.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
Average 4.3/5 across 6 of 6 tools scored.
Each tool targets a distinct query type: book-centric recommendations, topic lists, person-centric recommendations, series ordering, summaries, and general search. The overlap between search_books and get_book_recommenders is clarified by their descriptions, so there is no real ambiguity.
All tools follow a consistent verb-first pattern: get_ or search_ followed by a descriptive noun. This makes the tool names predictable and easy to remember.
Six tools is well-scoped for a book recommendation server, covering the core user intents without unnecessary bloat. Each tool earns its place and there is no sense of redundancy or missing functionality.
The tool set covers the full range of book-related queries: searching, finding recommendations by book or person, curated topic lists, series order, and summaries. There are no obvious gaps that would prevent an agent from answering common user questions.
get_book_recommendersWho recommends this book?AReturn every verified person who recommends a given book, each with their quote about it and a link to the original source. This is MRB's signature dataset — use it when a user asks 'who recommends Sapiens?', 'is Zero to One worth reading?', or wants social proof / expert opinions on a specific title. Accepts a title ('Sapiens') or author+title for disambiguation.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Book title, e.g. 'Sapiens' or 'Zero to One' |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and non-destructive behavior, lowering the burden. The description adds that results are 'verified' and include quotes/links, plus disambiguation via author+title, but doesn't go into deeper behavioral specifics like auth requirements, rate limits, or edge-case handling. This is modest added context, consistent with a 3.
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?
The description is three sentences, front-loaded with the core action, followed by usage examples and disambiguation guidance. Every sentence serves a purpose—no fluff, no redundancy.
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 single-parameter, read-only tool with an output schema, the description adequately covers purpose, usage, and parameter quirks. It could mention behavior when no recommenders are found or specific formatting of the author+title input, but overall it is sufficiently complete given the tool's simplicity.
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 coverage is 100%, so the schema already documents the title parameter. However, the description adds significant meaning by noting the tool 'Accepts a title ("Sapiens") or author+title for disambiguation.' This clarifies how to handle ambiguous titles, which is not present in the schema's simple 'Book title' description.
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?
The description starts with a specific verb+resource: 'Return every verified person who recommends a given book, each with their quote about it and a link to the original source.' This clearly distinguishes it from siblings like get_person_recommendations or search_books by emphasizing the output structure and the unique 'signature dataset' angle.
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?
It provides explicit when-to-use examples: 'use it when a user asks "who recommends Sapiens?", "is Zero to One worth reading?", or wants social proof / expert opinions on a specific title.' It lacks explicit when-not-to-use or alternative references, but the context is clear and well-scoped.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_listGet a consensus best-books listAReturn one of MRB's 1,300+ consensus 'best books' lists for a topic (startups, stoicism, finance, sci-fi…). Every book on a list was recommended by at least two independent expert sources and is ranked by how many sources mention it. Use this when a user asks for 'the best X books' and you want a ranking backed by multiple experts rather than one opinion. Accepts a topic name ('startup', 'personal finance') or MRB list slug.
| Name | Required | Description | Default |
|---|---|---|---|
| list | Yes | Topic or list slug, e.g. 'startup' or 'stoicism' | |
| limit | No | Max books to return (default 20) |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare this as read-only, idempotent, and non-destructive. The description adds meaningful behavioral context by explaining that each book was recommended by at least two independent sources and ranked by mention count, which sets expectations about the list construction and ranking methodology.
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?
The description is three sentences: purpose, methodology, usage context, and parameter clarification. It is front-loaded, non-redundant, and contains no filler, making it highly concise and well-structured.
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 two-parameter retrieval tool with a full output schema, the description covers purpose, methodology, usage guidance, and input format. Nothing critical is missing given the annotations and schema already provide safety and return-type context.
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?
The input schema already documents both parameters with examples and 100% coverage. The description reinforces the 'topic or slug' input format but adds little new meaning beyond what the schema provides, so the baseline of 3 is appropriate.
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?
The description clearly states the tool returns one of MRB's 1,300+ consensus 'best books' lists for a topic, using a specific verb and resource. It distinguishes from sibling tools by emphasizing 'consensus' and 'multiple experts,' which is unique compared to person-specific or search tools.
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 description explicitly provides a use case: 'when a user asks for "the best X books" and you want a ranking backed by multiple experts rather than one opinion.' It gives clear context but does not name alternatives or provide when-not-to-use conditions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_person_recommendationsGet a person's book recommendationsAReturn every book a specific person (entrepreneur, investor, author, celebrity…) has recommended, with their verified quote about each book and a link to the original source (interview, podcast, post). Use this when a user asks 'what books does Naval Ravikant recommend?', 'Tim Ferriss's favorite books', or wants reading habits of a specific public figure. Accepts a name ('Naval Ravikant') or MRB slug ('naval-ravikant').
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max books to return (default 20) | |
| person | Yes | Person's name or MRB slug, e.g. 'Naval Ravikant' |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| mode | Yes | |
| items | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds meaningful behavioral context beyond that: it mentions returning 'verified quote' and 'link to the original source', and that the input can be a name or a slug, which helps set expectations.
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?
The description is three sentences with no wasted words: purpose, usage examples, and input format. It is front-loaded with the main action and reads efficiently.
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?
The description covers what the tool does, when to use it, and how to specify the person. An output schema exists, so return details are handled elsewhere. The only gap is that 'Return every book' is slightly contradicted by the optional limit parameter (default 20), which is not acknowledged in the description.
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%, so the baseline is 3. The description repeats the person parameter example ('Naval Ravikant') and the slug form, but this largely duplicates the schema's own description and does not add significant meaning or clarify the limit parameter beyond what the schema already provides.
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?
The description uses a specific verb and resource: 'Return every book a specific person... has recommended'. It also includes concrete query examples ('what books does Naval Ravikant recommend?') that clearly distinguish it from sibling tools like search_books and get_book_recommenders.
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?
Explicit usage guidance is provided with the phrase 'Use this when a user asks...' followed by concrete examples. However, it does not explicitly state when not to use the tool or name alternative tools, so it stops short of full when-not/alternatives coverage.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_series_reading_orderGet a series' reading orderAReturn the complete publication-order book list for a book series — the order the author released them, including novellas and companion volumes where cataloged. Use this when a user asks 'what order do I read John Grisham?', 'Harry Potter books in order', or how many books a series has. Accepts a series or author name ('Jack Reacher', 'Brandon Sanderson').
| Name | Required | Description | Default |
|---|---|---|---|
| series | Yes | Series or author name, e.g. 'Jack Reacher' or 'John Grisham' |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly/destructive hints, so the description adds value by specifying the output scope ('complete publication-order', including novellas/companion volumes) and the accepted input forms (author or series name). The caveat 'where cataloged' sets expectations about data availability, though it does not cover edge cases or error behavior.
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?
The description is three sentences, each serving a clear purpose: function, usage triggers, and input specification. It is front-loaded with the primary action and uses concise, high-context language without redundancy.
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 tool with a single well-documented parameter, complete annotations, and an output schema, the description covers all necessary context: what it does, when to use it, and what input it accepts. No additional return-value detail is needed given the output schema exists.
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?
The schema provides 100% parameter coverage with a description and example for 'series'. The tool description largely repeats the schema's parameter details ('Accepts a series or author name') and adds only a minor extra example ('Brandon Sanderson'). Since the schema carries the semantic weight, the description adds minimal additional value.
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?
The description clearly states the tool's function with a specific verb ('Return') and resource ('complete publication-order book list for a book series'). The examples like 'Harry Potter books in order' and the scope (including novellas/companion volumes) distinguish it from sibling tools such as search_books or get_summary.
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 description explicitly provides when-to-use guidance with concrete example queries ('what order do I read John Grisham?', 'Harry Potter books in order', 'how many books a series has'). It does not mention when-not-to-use or alternative tools, but the stated triggers are clear and actionable.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_summaryGet a book summaryAReturn MRB's one-page summary of a book: the overview plus chapter-by-chapter notes (~435 titles available). Use this when a user asks 'summarize Atomic Habits', 'what is Sapiens about?', or wants the key ideas without reading the book. Set full_text=true only when the user explicitly wants the complete chapter notes — they can be very long.
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Book title, e.g. 'Atomic Habits' | |
| full_text | No | Include full chapter contents (default false: overview + chapter titles) |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (read-only, idempotent), the description adds valuable context: the availability limit (~435 titles), the default behavior of full_text, and the warning that full chapter notes can be very long. This helps the agent set expectations for output size.
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?
The description is two sentences, front-loaded with the main purpose and example queries, and contains no filler. Every clause contributes useful information.
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?
Given the output schema exists and annotations cover safety, the description is sufficiently complete. It mentions content composition, availability, and parameter behavior. Minor gap: no explicit handling for titles not in the ~435 set, but the output schema likely covers error responses.
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 coverage is 100% with descriptions for both parameters. The description adds further semantic guidance on when to set full_text=true ('only when the user explicitly wants the complete chapter notes') and warns about length, which enriches parameter understanding.
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?
The description clearly states the tool returns MRB's one-page summary of a book, including overview and chapter-by-chapter notes. It distinguishes itself from sibling tools (recommenders, lists, person recommendations, series order, search) by specifying the exact resource it provides.
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 description gives explicit use cases: 'summarize Atomic Habits', 'what is Sapiens about?', or key ideas without reading. It does not explicitly mention when to avoid this tool, but the context strongly implies it is for summary requests, which is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_booksSearch booksASearch Most Recommended Books' human-curated catalog by book title or author name. Returns ranked matches with author, publication year, how many verified people recommend each book, the top recommenders, a sourced quote, and a buy link. Use this when a user asks about a specific book, an author's books, or wants recommendations matching a title they half-remember. For 'who recommends X?' prefer get_book_recommenders; for 'what does person X recommend?' prefer get_person_recommendations.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Max results (default 6) | |
| query | Yes | Book title or author name, e.g. 'Atomic Habits' or 'Cormac McCarthy' |
| Name | Required | Description |
|---|---|---|
| url | Yes | |
| mode | Yes | |
| items | Yes | |
| source | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, destructiveHint=false, and idempotentHint=true, so the safety profile is covered. The description adds valuable context beyond annotations: the catalog is 'human-curated,' results are 'ranked,' and include 'verified people' recommenders. It also discloses the return payload components (quote, buy link). No contradictions with annotations.
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 sentences, front-loading the core action and resource, then listing return values, then providing usage context and alternatives. Every sentence earns its place with no redundant filler or repetition of annotation fields.
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 2-parameter search tool with a rich output schema and strong annotations, the description comprehensively covers the tool's purpose, result contents, usage triggers, and sibling differentiation. It also notes the 'half-remembered title' use case, making it complete for an agent to decide when to invoke.
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%, with both 'query' and 'limit' already fully described (including examples and default). The description largely restates the schema's query semantics ('book title or author name') without adding new parameter-level insights. Thus the baseline of 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?
The description opens with a specific verb ('Search') and a clear resource ('Most Recommended Books' human-curated catalog') scoped by 'book title or author name.' It distinguishes itself from siblings by detailing the return fields (ranked matches, author, publication year, recommenders, quote, buy link) and explicitly contrasts with get_book_recommenders and get_person_recommendations.
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?
Provides explicit when-to-use guidance: 'when a user asks about a specific book, an author's books, or wants recommendations matching a title they half-remember.' It also names alternatives for related queries ('who recommends X?' → get_book_recommenders; 'what does person X recommend?' → get_person_recommendations), covering both inclusion and exclusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
No comments yet. Be the first to start the discussion!