ODocs.co

Get Document

get-document

Read-only

Reads an ODocs.co document by ID. The default result is a readable plaintext (.txt-style) view: a metadata frontmatter (id, title, version, persistent, commentCount, openCommentCount, note) followed by the body. format:"json" returns { id, title, content, version, persistent, commentCount, openCommentCount } as an object; frontmatter:false returns just the body. version is the value patch-document accepts as expectedVersion for conflict detection. openCommentCount is the number of unresolved comment threads; includeComments:true adds the threads to the result. persistent is true for a document saved in the cloud, false for a temporary one. The note (that the text is written by anyone with the link) is the frontmatter's note field in the text view; json and frontmatter:false results carry it as a second text item.

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": {
      "id": "<id>"
    },
    "name": "get-document"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Document ID (UUID from the doc URL)
`format`	No	Response format: 'text' (default) is a readable .txt-style view; 'json' is the structured object.
`frontmatter`	No	(text format only) Include the metadata frontmatter block. Default true; false returns just the body.
`includeComments`	No	Include the comment threads in the result (the same threads list-comments returns). Default false. In json they are a comments array. In text format each thread wraps the text at its anchor (placement="anchor": the commented copy; the wrapped text with the tag's occurrence="N" matches that copy as a find/anchor in patch-document's text-anchored operations; an edit that adds, changes or removes a lower copy renumbers the higher ones; no occurrence means that copy can't be matched by its text alone, only by a find that includes neighbouring text; a quote="…" attribute means the text was edited since and holds the original quote). If the anchor is lost the thread is detached (orphaned="true" state="detached": its text was changed or removed) and it wraps the earliest place its quote appears (placement="text": possibly another copy). A thread overlapping one already wrapped is listed at the end with overlaps="<thread id>"; one whose quote is not found is listed at the end with orphaned="true" state="detached".

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 13, 2026

TDQS

A4.1/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered before the description starts. The description adds genuinely useful context not in annotations: default text view with frontmatter, a json variant with a named field set, and frontmatter:false suppressing the block. It does not describe pagination, size limits, or failure modes (missing ID, permission denied), which keeps it at adequate rather than rich.

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 primary behavior and the default return shape before the format variants, and nearly every clause carries information an agent would otherwise have to guess. It is a dense single block rather than a structured list, and the final sentence about the note field is convoluted for a small detail, costing the top score.

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?

There is no output schema, so the description carries the burden of describing return values, and it does that thoroughly for default text, json, and frontmatter:false results. Gaps remain around error conditions and what happens for a nonexistent or deleted document ID, which an agent calling by ID would want to know.

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 baseline is 3, and the description earns an extra point by giving semantics the schema lacks: version as the expectedVersion patch-document takes, openCommentCount as unresolved threads, and persistent as cloud-vs-temporary. The id parameter and the format/frontmatter enum effects are left to the schema, which is reasonable given coverage.

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?

Opens with a specific verb and resource: 'Reads an ODocs.co document by ID.' The sibling set includes patch-document and create-document, and the description's framing plus the reference to 'the value patch-document accepts as expectedVersion' makes clear this is the read counterpart, so an agent can separate it from the mutating siblings.

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

Usage Guidelines4/5

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

Explain-usage conditions are embedded rather than stated as 'use this when': format/format json/frontmatter:false are given as explicit alternatives with consequences, and includeComments is tied to 'the same threads list-comments returns', routing the agent. It stops short of explicit when-not-to-use guidance such as preferring list-comments for comment-only reads, so not a 5.

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

All ODocs.co 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.

Resources

Need Help?