Skip to main content
Glama
Sign In

Dockito

by ai.dockito
OverviewDiscussionsAdmin

Publish a doc

publish
Idempotent

Publishes Markdown, HTML or an OpenAPI .yaml/.json (answers what changed and breaks). A file with the same name in that place updates its doc (same link, a new History entry); otherwise it becomes a new doc. Unchanged content is skipped. A .csv becomes a new live sheet, typed as Excel opens it; after that it changes with edit_sheet, never by a file. Slides: An .html file of slides (1920×1080) makes new Slides: , one per slide, each element a box with a class and left/top/width/height in px, or inside a div class="stack" or "grid". Before your first deck, get with "kit" (and a "theme") gives the classes and an example. Pictures: files beside it, or https URLs. Replies with the outline and anything to fix. After that it changes with edit_slides. Boards: A .canvas file (JSON Canvas: text, link, file and group nodes, edges) makes a new board, laid out as given: groups become frames, text nodes stickies, links embeds, edges connectors; up to 500 nodes and edges. An empty .canvas makes an empty board. A template starts one instead: "template" with an empty .canvas (start-stop-continue, 4ls, mad-sad-glad, brainstorm, workshop, design-sprint). After that it changes with edit_board. To change part of a Markdown or HTML doc, use edit_doc, not a whole new file. An existing private doc is made public from Share in the Dockito app.

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": {
      "name": "<name>",
      "content": "<content>"
    },
    "name": "publish"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNo"project" or "project/folder". Default: the workspace's Docs. Ask the user when a doc belongs in a project; never guess.
docNoUpdate this doc (link or code) instead of matching by name.
newNoA new doc even if one with this name is there.
nameYesThe file name, with .md, .html, .csv, .canvas, .yaml, .json or .docx: "plan.md". It titles the doc and matches it next time.
filesNoSlides only. Pictures the .html names, as {"photo.webp": "<base64>"}, 10 MB in all. https URLs in it are fetched. More of the person's pictures go in later with upload.
titleNoA new doc's title. Default: the file name without its extension. An existing doc keeps its title; rename changes it.
publicNoAnyone with the link can open it, no sign-in. Only when the user asked. Only for a new doc.
contentYesThe whole file; a .docx (a new Word doc) as base64.
messageNoKeep this entry as a saved point, with this note.
templateNoBoards only: a new board from a template, with an empty .canvas: start-stop-continue (retro), 4ls (Liked, Learned, Lacked, Longed for), mad-sad-glad, brainstorm, workshop (an agenda with an icebreaker and timed sections), design-sprint (Monday Map to Friday Test). Its frames come with prompts and guiding stickies; fill them with edit_board.
workspaceNoWorkspace slug. Default: the only one, else the user's personal one.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (which only say non-read-only, non-destructive, idempotent, closed-world), the description discloses real side-effect semantics: same-name files update in place on the same link but add a History entry, unchanged content is skipped, CSV becomes a live sheet then is never updated by file, and there are hard limits (500 nodes/edges, 10 MB of pictures). It also surfaces the return behavior ('Replies with the outline and anything to fix') and a permission caveat that making an existing private doc public must happen in the app, not here.

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?

It is one unbroken block covering six formats with no paragraphing, bullets, or headings, so the reader must parse ~250 words linearly to find the branch relevant to them. Individual sentences are front-loaded and dense, but the template list and several parameter facts are duplicated from the schema, adding length without new information.

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 an 11-parameter, multi-format tool with no output schema, the description covers every branch (docs, OpenAPI, CSV, slides, boards), states what the call returns, and routes follow-up mutations to the correct sibling. Nothing an agent needs to call this correctly across formats appears to be 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 description coverage is 100%, so the schema already carries the per-parameter burden and baseline is 3. The description still adds interaction-level meaning the schema does not, notably how 'doc' and 'name' compete for matching, that a template is started by pairing an empty .canvas with the 'template' value, and that an empty .canvas yields an empty board; it does, however, restate the template enum values that the schema already lists.

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 opening sentence names a specific verb (publishes) and enumerates the exact resource types handled (Markdown, HTML, OpenAPI .yaml/.json, .csv, .html slides, .canvas). It repeatedly distinguishes itself from siblings by naming edit_doc, edit_sheet, edit_slides, edit_board and edit_openapi as the tools for subsequent changes, so an agent can tell which tool to pick 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 Guidelines5/5

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

Explicit when-to-use/when-not rules are given per format: 'To change part of a Markdown or HTML doc, use edit_doc, not a whole new file', a .csv 'after that it changes with edit_sheet, never by a file', and equivalent routing for slides and boards. It also states a prerequisite ('Before your first deck, get with "kit"') and a deferral rule ('Ask the user when a doc belongs in a project; never guess').

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

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