Skip to main content
Glama
Sign In

Dock

by ai.trydock
OverviewDiscussionsAdmin

get_doc

Read a workspace's doc (TipTap rich-text) body. Format is negotiable via format: markdown (default — CommonMark + GFM, ready to feed to an LLM or render in a non-ProseMirror surface), content (TipTap JSON, round-trippable into update_doc for structural edits), text (plain text, best for search, summarisation, word-count heuristics), or all for the legacy three-in-one shape. Default is markdown because it's the slice agents need 95% of the time and the JSON form on a long doc can blow past the agent harness's tool-result token cap. Pass format: "content" only when you're round-tripping into update_doc for a structural edit. A workspace can hold any combination of doc and table surfaces, one or many of either kind; omit surface_slug to read the primary doc surface, or pass it to target a specific doc surface (use list_surfaces to enumerate). An unwritten or absent doc returns the requested format empty (markdown="", content={}, text=""); a surface_slug that doesn't match any live doc surface 404s.

Input Schema

NameRequiredDescriptionDefault
slugYesThe workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL; both resolve to the same workspace.
formatNoWhich serialization to return. Default `markdown`. Use `content` to round-trip TipTap JSON back into update_doc for structural edits. Use `all` for the legacy three-in-one shape (heavier; only do this when you genuinely need every form in the same call).
headingNoOptional. Return only the section under this heading (exact heading text): the heading through the next heading of the same or higher level, the same range update_doc_section writes. Use it to read a large doc a section at a time. A missing heading returns the headings that exist; a heading used more than once is refused rather than guessed.
surface_slugNoOptional doc surface slug for multi-doc workspaces. Omit to read the primary doc surface. Use list_surfaces to see available slugs.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / heading
      Added value: +{
+  "description": "Optional. Return only the section under this heading (exact heading text): the heading through the next heading of the same or higher level, the same range update_doc_section writes. Use it to read a large doc a section at a time. A missing heading returns the headings that exist; a heading used more than once is refused rather than guessed.",
+  "type": "string"
+}
  2. Changed1 schema field changed
    • addedInput schema / properties / format
      Added value: +{
+  "description": "Which serialization to return. Default `markdown`. Use `content` to round-trip TipTap JSON back into update_doc for structural edits. Use `all` for the legacy three-in-one shape (heavier; only do this when you genuinely need every form in the same call).",
+  "enum": [
+    "markdown",
+    "content",
+    "text",
+    "all"
+  ],
+  "type": "string"
+}
  3. Changed1 schema field changed
    • changedInput schema / properties / slug / description
      Previous value: -"The workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL — both resolve to the same workspace."New value: +"The workspace slug. Accepts either the bare slug ('my-workspace') or the org-prefixed form ('my-org/my-workspace') as shown in the dashboard URL; both resolve to the same workspace."
  4. First observed

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and largely meets it: it discloses the token-cap hazard of TipTap JSON on long docs, the empty-doc return shape per format, the 404 on a non-matching surface_slug, and the heading edge cases (missing heading returns existing headings, duplicate heading is refused). It does not touch permissions/sharing requirements for reading a workspace, which is the main remaining gap.

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 action and the format negotiation, and every sentence is information-bearing. It is on the long side and re-states several schema parameter descriptions, which is the only reason it falls short of 5.

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?

With no annotations and no output schema, the description does the heavy lifting: it explains what each format returns structurally and what an unwritten doc yields. It stops short of describing the full return envelope (e.g. whether title/metadata accompany the body), leaving a small gap for a read tool with no output schema.

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, but the description adds a decision rationale the schema lacks: why markdown is the default (agent-relevant slice 95% of the time, JSON risks blowing the tool-result token cap). Most other parameter prose (enum meanings, heading semantics, surface_slug) is duplicated from the schema, so the gain over structured data is real but modest.

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?

"Read a workspace's doc (TipTap rich-text) body" states a specific verb and resource, and the format enumeration plus the update_doc round-trip note distinguish it cleanly from siblings like get_html, get_row, and update_doc. An agent can identify the tool's job without opening the 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 explicit routing rules per format (markdown as the default for LLM/render consumption, content only when round-tripping into update_doc, text for search/summarisation, all only for the legacy three-in-one shape) and states when to omit vs supply surface_slug, pointing at list_surfaces for enumeration. Exclusions are stated, not inferred.

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

All Dock 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