Skip to main content
Glama
Sign In

ODocs.co

by co.odocs
OverviewDiscussionsAdmin

Get Document Version

get-version
Read-only

Returns the content of one saved version of an ODocs.co document, by its index in list-versions. The default result is a plaintext view (frontmatter: timestamp, title, note; then the content); format:"json" returns { timestamp, title, content }; frontmatter:false returns just the content. 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>",
      "index": "<index>"
    },
    "name": "get-version"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesDocument ID
indexYesVersion index, as listed by list-versions
formatNoResponse format: 'text' (default) is a readable .txt-style view; 'json' is the structured object.
frontmatterNo(text format only) Include the metadata frontmatter block. Default true; false returns just the body.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations already declare readOnlyHint=true and destructiveHint=false, yet the description still discloses the exact return shapes: a default plaintext view with timestamp/title/note frontmatter, a JSON object shape, and body-only output with frontmatter:false. It also flags a non-obvious trait — the note that text is written by anyone with the link — and explains where that note surfaces in each format.

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 purpose and source of the index, then the output variations; every clause carries information. The second sentence is heavily nested with parentheticals, which slightly slows parsing but nothing is wasted.

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?

There is no output schema, so the description carries the return-value burden — and it does so for all three output modes, including the caveat about where the public-write note appears. For a 4-parameter read tool with full annotation coverage, nothing an agent needs 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 baseline is 3; the description goes further by specifying what format:'json' and frontmatter:false actually yield, including that frontmatter is text-only and that the note becomes a second text item in non-frontmatter modes. That adds real meaning about parameter interaction beyond the schema's per-field blurbs.

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 and resource ('Returns the content of one saved version of an ODocs.co document') plus the scoping requirement 'by its index in list-versions', which pins it as the historical-version read as opposed to a current-document read like get-document. An agent can distinguish it from siblings 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 Guidelines4/5

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

The dependency on list-versions for the index gives a clear usage context, and the format/frontmatter options are framed as reader choices. It stops short of explicitly saying when to use this versus get-document for the latest content, so there is no stated exclusion.

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

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