Skip to main content
Glama

get_doc

Read-onlyIdempotent

Read a document's outline and metadata by default, then request a single section or the full body; use version checks before editing.

Instructions

Read a document. By DEFAULT returns metadata plus the outline (headings) and NOT the body — a document is far larger than a task, and a body you read stays in your context for the rest of the session. Read the outline first, then pass section="" for just that part; body=true returns the whole page and should be the exception. The returned version is what update_doc takes as base_version. If you addressed the document by an old path or a bare slug, the reply carries moved_to (its current path); a bare slug shared by several documents fails with 409 and the list of full paths.

Input Schema

NameRequiredDescriptionDefault
docYesDocument UUID, or a slug path like 'architecture/adr/adr-004' (a path also needs project_id). A path survives the document being moved: the old path still resolves, and so does a bare slug ('adr-004') when exactly one live document in the project has it. When the reference was not the live path, the reply carries moved_to — the document's current path; use that from now on. A bare slug shared by several documents is a 409 ('Ambiguous document slug') listing the full paths: pick one and repeat the call with the full path or the UUID. The UUID never changes.
bodyNoReturn the full markdown body. Prefer section= when you need one part.
sectionNoReturn only this section: a heading's text, or its anchor from the outline.
project_idNoProject UUID. Required only when doc is a slug path.
version_onlyNoReturn just the version — the cheap 'has this changed since I read it?' check before a write.
outline_depthNoLimit the outline to headings at this level or shallower (e.g. '2' for chapters, not every subsection). Default: all levels.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already declare readOnly/idempotent/non-destructive, but the description adds substantial non-obvious behavior: the default omits the body, the context-cost rationale, moved_to on stale paths, and the 409 with candidate paths on ambiguous slugs. These are real operational traits beyond what the annotations convey.

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?

Front-loaded with the default behavior and rationale, then progressively narrower options, using dashes and a compact list-like flow. Slightly long, and the final sentence about moved_to/409 partially duplicates the doc parameter's schema text, but the density of operational content justifies the length.

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?

No output schema exists, so the description carries the return-shape burden itself: it names the metadata+outline default, the full-body case, moved_to, the 409 error shape, and the version field used as base_version. Nothing an agent needs to call or interpret the result is missing.

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 baseline is 3, but the description adds cross-parameter workflow meaning the schema cannot: outline-then-section sequencing, body=true as the exception, and version_only as the pre-write freshness check. It also surfaces the moved_to/409 resolution behavior alongside the doc parameter.

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?

States a specific verb+resource ("Read a document") and immediately scopes the default return (metadata + outline, not body), which differentiates it from list_docs, search_docs, and update_doc. The relationship to update_doc is called out explicitly via base_version, so an agent can place the tool without opening a schema.

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?

Gives an explicit recommended workflow (read outline first, then section=), states the exception case for body=true, and provides an alternative path (version_only) for the cheap change check before a write. When-not guidance is present rather than implied.

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