Skip to main content
Glama
RuloGB

compendio-mcp

by RuloGB
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Read a document

read_doc

Retrieve a specific markdown doc section with frontmatter, or receive an outline for large docs. Missing paths return closest matching alternatives.

Instructions

Reads one section of a document, along with its frontmatter. Built for sections, not whole files: pass section whenever you can. Omitting it returns the entire document when it is small or cannot usefully be split into sections; a large document with sections returns its outline instead (H2 and H3 headings, each with an estimated token size), so call again with one of those headings as section. To read or summarize a whole document, start from its outline and request the sections you need. When a user names a section in a .md document, pass that named section here after locating the indexed path with docs_overview if necessary. If the path does not exist, it responds with the 3 closest matching paths instead of failing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pathYesDocument path, relative to the docs directory
sectionNoHeading (or part of it) of the section to read, e.g. 'Business rules', or a heading from read_doc's outline. Use the section field of a search_docs result. Sections name a region of a document, not a single fragment: a large section returns all of its parts joined.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • changedInput schema / properties / section / description
      Previous value: -"Heading (or part of it) of the section to read, e.g. 'Business rules'. Use the section field of a search_docs result. Sections name a region of a document, not a single fragment: a large section returns all of its parts joined."New value: +"Heading (or part of it) of the section to read, e.g. 'Business rules', or a heading from read_doc's outline. Use the section field of a search_docs result. Sections name a region of a document, not a single fragment: a large section returns all of its parts joined."
  2. First observedv0.1.0

TDQS

A4.6/5.0
Behavior4/5

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

The description discloses key behaviors beyond the schema: it returns an outline for large documents, estimates token sizes, returns the 3 closest matching paths on failure, and joins all parts of a large section. Since no annotations are provided, the description carries the full burden and does so well, though it doesn't mention any side effects or permissions (which are likely irrelevant for a read operation).

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 dense but well-organized, front-loading the core behavior and then covering edge cases. It's longer than strictly necessary, but every sentence adds operational value—no filler or repetition of schema details.

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

Completeness5/5

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

For a read tool with no output schema and no annotations, the description covers all essential context: what it returns, how to handle large documents, how to use it with sibling tools, and failure behavior. An agent has enough information to call it correctly in all documented scenarios.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents both parameters. The description adds value by explaining the section parameter's role in the outline workflow and how it relates to search_docs results, and clarifies that sections name a region, not a single fragment. This goes beyond the schema's basic descriptions.

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 clearly states the tool reads one section of a document along with its frontmatter, and explicitly distinguishes it from whole-file reading. It names the sibling tools (docs_overview, search_docs) and explains when to use them, making the purpose unambiguous.

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?

The description provides explicit guidance: pass section whenever possible, omit it for small documents, and use the outline for large documents. It also explains how to handle user-named sections in .md files and what to do if the path doesn't exist, covering both normal and edge-case usage.

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

Deploy Server

Other Tools