Skip to main content
Glama

Dock

by ai.trydock

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 tab (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

TableJSON 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).
surface_slugNoOptional doc surface slug for multi-doc workspaces. Omit to read the primary doc surface. Use list_surfaces to see available slugs.

TDQS

A5/5.0
Behavior5/5

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

No annotations are provided, so the description carries the full burden. It discloses edge-case behavior: 'An unwritten or absent doc returns the requested format empty...' and 'a surface_slug that doesn't match any live doc surface 404s.' It also warns about JSON responses blowing past token caps, which is crucial behavioral context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Although long, every sentence earns its place — format semantics, surface targeting, edge cases, and error behavior — with no redundancy. It is front-loaded with the core purpose and the default format rationale.

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, the description covers all relevant contexts: format selection rationale, surface selection, empty results for unwritten docs, 404 errors for invalid surfaces, and token cap concerns. An agent has everything needed to invoke the tool correctly.

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

Parameters5/5

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

Schema coverage is 100%, but the description adds deeper meaning: it explains markdown is CommonMark+GFM ready for LLMs, that JSON is round-trippable into update_doc, and that text is best for search/summarisation. This goes beyond the enum descriptions and clarifies when each format should be selected.

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 opens with 'Read a workspace's doc (TipTap rich-text) body' — a specific verb and resource. It distinguishes itself from siblings by explicitly referencing update_doc and list_surfaces, and explains format variants, 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?

It gives explicit when-to-use guidance: 'Pass `format: "content"` only when you're round-tripping into update_doc for a structural edit' and explains the default markdown choice based on agent needs. It also directs users to list_surfaces for enumerating doc surfaces, clearly separating alternatives.

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
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

TDQS

A3.8/5.0
Disambiguation4/5

Most tools have clearly distinct purposes, with detailed descriptions that prevent confusion. The main ambiguity arises from send_message vs. the referenced but missing message_teammate tool, and add_column vs. update_surface for schema changes, but these are mostly clarified by the descriptions.

Naming Consistency4/5

The naming convention is predominantly verb_noun with underscores (e.g., create_workspace, list_rows, update_doc). Exceptions like 'search' and 'address_book' (no noun) and the two-word 'react_to_comment' are minor deviations in an otherwise consistent pattern.

Tool Count1/5

With 68 tools, the surface is far too large for an MCP server, exceeding the 50+ threshold for extreme mismatch. This volume creates excessive selection overhead for agents and suggests the tool set could be consolidated or split into focused servers.

Completeness3/5

The server covers broad functionality across workspaces, docs, tables, HTML, comments, files, webhooks, and billing. However, notable gaps exist: the explicitly referenced message_teammate tool is missing (preventing agent-to-agent waking), and there is no create/upload file tool or create API key tool, which creates dead ends in workflows.

Resources