RestaurantDoctorAI

Read a library entry

restaurantdoctor_read_knowledge

Read-onlyIdempotent

Reads one entry of RestaurantDoctorAI's library in full (a guide, a blog post, a playbook fix, the targets, a fact or a knowledge entry), by its id (such as 'guide:restaurant-prime-cost'), with its title, link and source. A long entry comes 8,000 characters at a time, with its total length: the next part starts at the nextOffset it returns. The query isn't stored; only an anonymous daily count of searches and reads is kept.

Input Schema

Name	Required	Description	Default
`id`	Yes	An entry id, as the library's search and list give it, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'.
`offset`	No	Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: the next part starts at the nextOffset the previous read returned.

Output Schema

Name	Required	Description
`id`	Yes	The entry's id, which reading the entry in full takes.
`url`	Yes	Where a reader can check it: the page on restaurantdoctorai.com, or the fact's own source.
`kind`	Yes
`note`	Yes
`text`	Yes	The entry's text from offset, up to 8,000 characters.
`title`	Yes
`offset`	Yes	Where this part starts, in characters.
`source`	Yes	Who says so, with the date it was checked or updated where there is one.
`truncated`	Yes	More of the entry follows this part (nextOffset says where).
`nextOffset`	Yes
`totalLength`	Yes	The whole entry's length, in characters.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 16, 2026

changedInput schema / properties / offset / description

Previous value: -"Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: send the nextOffset a read gave for the next part."New value: +"Where to start, in characters (default 0, the start). A long entry comes 8,000 characters at a time: the next part starts at the nextOffset the previous read returned."

Changed2 schema fields changedOct 15, 2026

changedOutput schema / properties / id / description

Previous value: -"The entry's id, for restaurantdoctor_read_knowledge."New value: +"The entry's id, which reading the entry in full takes."

changedOutput schema / properties / nextOffset / anyOf

Previous value: -[
-  {
-    "description": "Where the next part starts: send it as offset to restaurantdoctor_read_knowledge.",
-    "type": "number"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "description": "Where the next part starts, in characters: the offset of the next read.",
+    "type": "number"
+  },
+  {
+    "type": "null"
+  }
+]

Changed1 schema field changedOct 14, 2026

changedInput schema / properties / id / description

Previous value: -"An entry id from restaurantdoctor_search_knowledge or restaurantdoctor_list_knowledge, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'."New value: +"An entry id, as the library's search and list give it, e.g. 'guide:restaurant-prime-cost' or 'post:restaurant-break-even-point'."

AddedOct 11, 2026

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false. The description adds meaningful context beyond those annotations: it explains the 8,000-character pagination behavior, the nextOffset return value for continuing, and that queries are not stored beyond anonymous daily counts. It does not cover error behavior or rate limits, so it is not exhaustive.

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 description is front-loaded with the core action and remains compact across three sentences. The parenthetical list of entry types is somewhat long, but each sentence contributes useful detail about scope, pagination, or privacy.

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 the description need not explain return values. It covers the key operational detail for long entries through pagination and nextOffset, and annotations cover the safety profile. It would be stronger if it explicitly routed users from search/list to this read tool.

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%, and the schema already documents both the id and offset parameters with examples and character-count semantics. The description reinforces pagination but does not add meaning beyond what the schema provides, so the baseline score of 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 states a specific verb and resource: it reads one entry of RestaurantDoctorAI's library in full by id, including guides, posts, playbook fixes, targets, facts, and knowledge entries. This clearly distinguishes it from sibling tools like list_knowledge and search_knowledge, which would return multiple or matched entries rather than one full entry.

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?

Usage is implied: the id format and the phrase 'by its id' suggest this tool is used after obtaining an id from search or list. However, the description does not explicitly say when to use this tool instead of search_knowledge or list_knowledge, nor does it state exclusions or prerequisites.

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

All RestaurantDoctorAI 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.