Skip to main content
Glama

Dock

by ai.trydock

update_doc

Replace a workspace's doc body. Takes EITHER TipTap JSON (content) OR Markdown (markdown): pass markdown when you're producing prose from scratch (CommonMark + GFM is the format every LLM emits natively), pass TipTap JSON when you need structural edits to an existing doc (round-trip from get_doc, mutate, write back). Beyond CommonMark + GFM, the markdown layer recognizes:

  • alt text → inline image. Use ANY publicly-reachable URL (HTTPS preferred — HTTP fires browser mixed-content warnings; data: URIs are rejected by allowBase64: false). Renders block-feeling via CSS (max-width 100%, rounded corners, drop shadow) even though the underlying node is inline. The alt text is the accessible label and shows in place of the image if the URL fails to load — always include it. To attach a user-uploaded file, hit POST /api/workspaces/:slug/upload-image from the human-side UI first to get a Vercel Blob URL, then reference that URL in the doc markdown.

  • A lone video-file URL on its own line (extension .mp4 / .m4v / .webm / .mov / .mkv, signed-params + timestamp fragments tolerated) → native HTML5 <video controls preload="metadata"> player. Source URL is referenced directly: no iframe, no transcoding, no quality loss. Vercel Blob is the canonical hosting (5 GB per file, served with HTTP range requests so 4K masters stream cleanly), but ANY publicly-reachable HTTPS URL works. Sample shape: a paragraph containing only https://cdn.dock.ai/2025-launch-walkthrough.mp4. Mid-paragraph URLs stay as plain links — surrounding prose disqualifies the auto-promotion (matches the oEmbed convention).

  • ```mermaid fenced code → diagram (15 sub-types: flowchart, sequence, gantt, ER, state, class, mindmap, timeline, pie, quadrant, sankey, XY-chart, packet, block, journey)

  • $x$ inline math, $$x$$ block math (LaTeX, KaTeX-rendered, scripts/href disabled)

  • > [!NOTE] / [!TIP] / [!IMPORTANT] / [!WARNING] / [!CAUTION] GFM-style callouts

  • ```svg fenced code → sanitized SVG embed (the universal escape hatch for custom diagrams; scripts and event handlers stripped at write time)

  • XBODY → collapsible toggle

  • [[slug]] / [[org/slug]] / [[slug#tab]] / [[slug#row-id]] / [[slug|display]] → cross-references to another workspace, surface, or row. Resolved against your accessible workspace set; targets you can't see render as plain text on the reader's side (no info leak). Every cross-ref creates a Backlink row so the target's 'referenced from' sidebar shows this doc.

  • @Label → @-mention of a user or agent. <kind> is agent or human; <id> is the principal id. Optional query params ?org=<slug> (agents) or ?email=<addr> (humans) for renderer hints. Mentioning a human writes a doc_mention row to their inbox + sends a deep-link email; mentioning an agent fires the doc.mention_added webhook so the agent service can wake up and reply. Re-saving a doc that already mentions someone does NOT re-fire — only newly-added mentions notify (computed from a diff against the previous body). Use this from agent code to ping a teammate when a doc you wrote needs their eyes.

  • A lone URL on its own line from a safelisted provider (YouTube, Vimeo, Loom, Figma, CodePen, GitHub gists) → sandboxed iframe embed. Other URLs stay as regular links. Surrounding prose disqualifies the auto-embed.

Per-format caps: max 50 Mermaid diagrams (30 KB source each), max 500 math expressions (8 KB source each), max 50 SVG blocks (100 KB source each post-sanitize), max 200 cross-refs per doc, max 500 @-mentions per doc, max 20 embeds per doc, max 20 videos per doc (5 GB per file at upload time), max 200 images per doc. See /docs/doc-formats for examples. Last-write-wins; no CRDT merge. Emits doc.updated + doc.heading_added + doc.mention_added events as applicable. Requires editor role. Multi-surface workspaces optionally accept surface_slug to write to a specific doc tab; omitted writes the primary doc surface. Append-only updates have a dedicated append_doc_section tool that doesn't require fetching the body first.

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.
contentNoTipTap document JSON: `{ type: 'doc', content: [ ... ] }`. Use this when round-tripping from get_doc to preserve formatting. Mutually exclusive with `markdown` (content wins if both are passed).
markdownNoMarkdown body (CommonMark + GFM). Converted server-side to TipTap JSON via the same converter that powers PUT /api/workspaces/:slug/doc. Use this when authoring prose from scratch; no need to hand-build ProseMirror nodes.
surface_slugNoOptional doc surface slug for multi-doc workspaces. Omit to write the primary doc surface. Use list_surfaces to see available slugs.
if_unmodified_sinceNoOptional precondition. ISO 8601 timestamp (typically the `updatedAt` you read via `get_doc`). When set and the doc has changed since this cutoff, the write is rejected with `code: -32602`, message describing the conflict, and `data: { conflict: true, currentUpdatedAt, precondition }` so your agent can refetch + merge instead of silently clobbering a concurrent write. Without this, two agents PUTting near-simultaneously will both succeed and the last write wins (the previous content vanishes). Use this in multi-agent co-authoring flows; skip it for greenfield writes where you know you're the only writer.

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 of behavioral disclosure. It discloses last-write-wins with no CRDT merge, event emissions (doc.updated, doc.heading_added, doc.mention_added), required editor role, data URI rejection (allowBase64: false), video auto-promotion rules, and per-format caps. This is exceptionally transparent.

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?

The description is long but exceptionally well-structured with bullet points for each markdown feature. It front-loads the core purpose and format-choice guidance, then provides concrete examples and constraints for each feature. Every sentence earns its place; the length is warranted by the tool's complexity.

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 complex write tool with 5 params, no output schema, and no annotations, the description is fully complete. It covers input format nuances, limits, events, permissions, conflict behavior, cross-tool alternatives, and even references the upload-image endpoint for attaching files. It leaves no practical questions unanswered.

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 substantial meaning beyond the schema. It explains markdown syntax (CommonMark + GFM), TipTap JSON structure, surface_slug default behavior, and the exact conflict error code (-32602) with data shape for if_unmodified_since. All five parameters are enriched with practical usage details.

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 'Replace a workspace's doc body' — a specific verb+resource. It clearly distinguishes between the two input formats (TipTap JSON vs Markdown) and explicitly names append_doc_section as the alternative for append-only updates, making it distinct from sibling tools like update_doc_section.

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?

The description gives explicit when-to-use guidance: 'pass markdown when you're producing prose from scratch... pass TipTap JSON when you need structural edits'. It also points to append_doc_section for append-only updates and explains the if_unmodified_since precondition for multi-agent co-authoring flows, covering both alternatives and exclusions.

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