Skip to main content
Glama
Sign In

Dock

by ai.trydock
OverviewDiscussionsAdmin

update_html

Write an HTML surface's body. Pass any of html / css / js; omitted fields stay unchanged. Pass empty string to clear. The surface renders in a sandboxed iframe with no access to Dock cookies, storage, or parent DOM, and scripts do not run there today: inline <script> and the js field are stored but never execute. Build pages that work without JavaScript; for interaction use CSS (:hover, :focus, transitions), title= attributes for tooltips, and <details>/<summary> for expanders. External CDN fonts and CSS (Google Fonts, Tailwind CDN, Fontsource), video, audio and CSS animations are fine. Text, numbers and charts go in the html itself. Per-field caps: html 256 KB, css 200 KB, js 200 KB, total 600 KB. The sanitizer is allowlist-based: standard HTML/SVG elements (including <canvas>, forms, <style>, <script>, <link>) and id/class/style/aria-*/data-* attributes are kept; anything off the allowlist is removed — e.g. <iframe>, <object>, <embed>, <meta>, <base>, custom elements, inline on*= event-handler attributes, javascript: and data:text/html URIs. Inline on*= handlers are removed and <script> does not run, so nothing script-driven will work. Call validate_html first: parsed.htmlRemoved lists exactly which tags / tag[attr] would be removed. Layout: Dock renders the surface EDGE-TO-EDGE (full-bleed) inside the workspace — the surface itself is the frame. Do NOT put border-radius, an outer border, or a drop-shadow on the root/outermost element unless the owner explicitly asked for that framing, or the specific design genuinely needs it; keep the page root flush and apply rounding to inner cards only. DESIGN LANGUAGE: Dock injects a base stylesheet into every surface — semantic tokens + a small component kit — that automatically follows each VIEWER's light/dark theme. USE these by default and never hardcode a color, including inside SVG: color SVG with classes or var(--dock-*) in CSS, not hex in fill=/stroke=. A hardcoded color looks broken for a viewer on the other theme (a dark surface for a light-mode viewer, and vice-versa). Tokens: var(--dock-canvas|surface|surface-muted|border|border-strong|text|text-2|text-muted|accent|accent-ink|data|data-strong|good|warn|crit), var(--dock-radius|shadow|gap); font is Inter via var(--dock-font). Component classes: .dock-card, .dock-stat/.dock-stat-value/.dock-stat-label, .dock-delta.up|.down, .dock-badge.good|warn|crit|neutral|accent (add a ), .dock-btn(.primary), .dock-table (use td.name for the primary cell, .dock-num for tabular figures), .dock-grid, .dock-eyebrow, .dock-row, .dock-avatar, .dock-field + .dock-input, .dock-bars/.dock-bar(.hot). Put .dock-num on any number so it aligns. This is a DEFAULT floor: override layout and type freely with your own CSS (nothing in the baseline is !important); colors stay on the tokens. CHARTS: draw them as static inline SVG in html (bars, lines, axes, labels and the numbers in the markup). Never rely on a script to render content: the page must read the same with scripts off, and to get_html. Requires editor role. Returns a short receipt, not the page: { surface_slug, url, updatedAt, bytes: { html, css, js }, sanitized } — sanitized lists any field you sent that the sanitizer changed on write. Before you share the surface's link, read it back with get_html and confirm the content and numbers you meant are there.

Input Schema

NameRequiredDescriptionDefault
jsNoJS source. Stored alongside html/css but not executed: html surfaces render with scripts off today. 200 KB cap (matches the top-level `update_html` description; the server enforces `HTML_SURFACE_LIMITS.jsBytes` = 200_000).
cssNoCSS source. Applied inside the sandbox iframe. You can also `<link rel="stylesheet">` external stylesheets from any HTTPS CDN (Tailwind CDN, Google Fonts, icon kits); CSS works, scripts do not.
htmlNoHTML body. Sanitized server-side (smells stripped; `<script>` and `<link>` are kept, but scripts do not run in the surface today, so use `<link>` for CDN stylesheets and fonts only). Use `validate_html` first for a pre-flight check.
slugYesThe workspace slug.
surface_slugNoOptional html surface slug. Omit to write the primary html surface.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changed
    • changedInput schema / properties / css / description
      Previous value: -"CSS source. Applied inside the sandbox iframe. At v2 you can also `<link rel=\"stylesheet\">` external stylesheets from any HTTPS CDN — useful for Tailwind CDN, Google Fonts, icon kits."New value: +"CSS source. Applied inside the sandbox iframe. You can also `<link rel=\"stylesheet\">` external stylesheets from any HTTPS CDN (Tailwind CDN, Google Fonts, icon kits); CSS works, scripts do not."
    • changedInput schema / properties / html / description
      Previous value: -"HTML body. Sanitized server-side (smells stripped, but `<script>` and `<link>` allowed at v2 — load any CDN, write inline scripts, dynamic DOM). Use `validate_html` first for a pre-flight check."New value: +"HTML body. Sanitized server-side (smells stripped; `<script>` and `<link>` are kept, but scripts do not run in the surface today, so use `<link>` for CDN stylesheets and fonts only). Use `validate_html` first for a pre-flight check."
    • changedInput schema / properties / js / description
      Previous value: -"JS source. Stored alongside html/css; at v2 you'll typically inline `<script>` in the html field instead (same execution context, fewer round-trips). 200 KB cap (matches the top-level `update_html` description; the server enforces `HTML_SURFACE_LIMITS.jsBytes` = 200_000)."New value: +"JS source. Stored alongside html/css but not executed: html surfaces render with scripts off today. 200 KB cap (matches the top-level `update_html` description; the server enforces `HTML_SURFACE_LIMITS.jsBytes` = 200_000)."
  2. Changed1 schema field changed
    • changedInput schema / properties / js / description
      Previous value: -"JS source. Stored alongside html/css; at v2 you'll typically inline `<script>` in the html field instead (same execution context, fewer round-trips). 100 KB cap."New value: +"JS source. Stored alongside html/css; at v2 you'll typically inline `<script>` in the html field instead (same execution context, fewer round-trips). 200 KB cap (matches the top-level `update_html` description; the server enforces `HTML_SURFACE_LIMITS.jsBytes` = 200_000)."
  3. Changed3 schema fields changed
    • changedInput schema / properties / css / description
      Previous value: -"CSS source. Applied inside the sandbox iframe."New value: +"CSS source. Applied inside the sandbox iframe. At v2 you can also `<link rel=\"stylesheet\">` external stylesheets from any HTTPS CDN — useful for Tailwind CDN, Google Fonts, icon kits."
    • changedInput schema / properties / html / description
      Previous value: -"HTML body. Sanitized server-side. Use `validate_html` first for a pre-flight check."New value: +"HTML body. Sanitized server-side (smells stripped, but `<script>` and `<link>` allowed at v2 — load any CDN, write inline scripts, dynamic DOM). Use `validate_html` first for a pre-flight check."
    • changedInput schema / properties / js / description
      Previous value: -"JS source. Stored but not executed at v1 (sandbox scripts-off)."New value: +"JS source. Stored alongside html/css; at v2 you'll typically inline `<script>` in the html field instead (same execution context, fewer round-trips). 100 KB cap."
  4. Added

TDQS

A4.5/5.0
Behavior5/5

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

With no annotations, the description carries the entire burden and does so: sandboxed iframe with no cookies/storage/parent DOM, scripts stored but never executed, allowlist sanitizer with concrete removed elements, per-field and total byte caps, and the shape of the receipt including `sanitized`. It even discloses that inline on* handlers are stripped, which is exactly the kind of non-obvious write-side behavior an agent must know.

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

Conciseness3/5

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

Core mechanics are front-loaded and clear, but the description balloons into a design-system manual (tokens, component classes, chart authoring, full-bleed framing rules). Much of that is output-quality guidance rather than tool-selection guidance, which dilutes the invocation-relevant content for an agent deciding whether and how to call the tool.

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?

Complete for a mutation tool with five parameters and no output schema: it specifies return shape ({ surface_slug, url, updatedAt, bytes, sanitized }), the sanitizer contract, the scripts-off rendering model, size limits, and the validate-then-write-then-read-back workflow.

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 real semantics beyond the schema: empty string clears a field, omitted fields are untouched, and per-field caps (html 256 KB, css 200 KB, js 200 KB, total 600 KB) are stated. It does not explain the relationship between `slug` and `surface_slug` beyond what the schema already says.

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 ('Write an HTML surface's body') and immediately defines partial-update semantics ('Pass any of html / css / js; omitted fields stay unchanged'). An agent can distinguish this from get_html, validate_html, and update_surface 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?

Gives explicit sequencing guidance ('Call validate_html first', 'read it back with get_html before you share') and states the editor-role prerequisite. It stops short of stating when to choose update_surface versus update_html, so it is not a full routing map.

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