Skip to main content
Glama
Sign In

Dockito

by ai.dockito
OverviewDiscussionsAdmin

Read a doc

get
Read-only

A doc's file: the current one, or a History entry. Returns its details, then the file's text. A file over 20,000 characters comes back as its outline (headings with line numbers) instead: read the part you need with "lines", or all of it with "full". A sheet comes back as its outline: each sheet's columns, what's in them, and the version to change it at; read gives its rows. Slides come back as their outline and version. "slides": ["s3"] gives those slides as HTML with box IDs, to edit or to rewrite with slide.html. "kit": true gives the theme's classes, the allowed styles and example slides (once is enough); with no doc, for "theme" (default Harbor). "asks": true lists what people asked the AI to do. A board comes back as its table of contents and version. "frames": ["f2"] gives those frames' items, one line each by short ID; "items": ["s12"] gives items whole; "since": N what changed after version N; "positions": true adds @x,y w×h (in the frame's units); "asks": true lists what people asked the AI to do. Word docs: the outline (title, version, pages, words, headings with IDs, pages and word counts, open suggestions and asks, the AI changes setting; about 2 KB for 200 pages). Then read only what you need: "blocks": ["h3"] (a heading and its section, or any block), "from": "p40" (on from a block), "pages": "4-6", "find": ["fees", "termination"] (blocks with IDs, page and a snippet), several at once; "since": N what changed after a version; "suggestions": true the open ones; "asks": true what people asked. Lines start with the block's ID; suggestions show as {++added++}[sg3] and {--deleted--}[sg3]. OpenAPI: the overview and version; "find" a task, then "ops", "schemas", "types" or "call"; "since" what changed. A database design: the DBML up to 80 tables, else the outline; "db" picks a read, "since" what changed after a version, "positions" each table's place. With "comments" or a comment link: the doc's threads, each with its ID, open or resolved, where it sits, and its comments. With "approvals": the doc's version now, the open request, its approvers' answers and the requests before it.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "get"
  }
}

Input Schema

NameRequiredDescriptionDefault
dbNoA database design. No option: the DBML up to 80 tables, else the outline: a line a table with its keys, links (→ table) and column count, by group. Then read only what's needed: {"outline":true} · {"tables":["orders"],"hops":1} (in full as DBML, the tables 1 to 3 refs away as outline lines) · {"find":"invoice"} (names first, then types, settings and notes; "type:uuid", "set:cascade", "note:lender" look in one place) · {"refs_to":"users.id"} (every ref, index, group, view and dep naming it) · {"impact":"orders.coupon_id"} (what a drop or type change breaks: the columns to change too, what a drop takes, where deleting a row cascades, lineage downstream) · {"path":["payments","users"]} (the shortest joins, as SQL) · {"since":12} (only what changed since version 12). A long answer ends "…and N more" with the read that gives the rest.
docNoThe doc's link or its code.
kitNoSlides only. The theme's classes, styles and example slides. With no doc: for "theme" and "density". Once a session is enough.
opsNoOpenAPI: operationIds or "POST /v1/refunds".
asksNoSlides, boards and Word docs. What people asked the AI to do: open and taken asks.
callNoOpenAPI: "PostRefunds" or {"op", "lang": "curl"|"fetch"|"python"}.
findNoOpenAPI: a task in words, "refund a payment". Word docs: words to find, "fees" or ["fees", "termination"]: blocks with IDs, page and a snippet.
fromNoWord docs: read on from this block, "p40", as far as 8,000 words.
fullNoThe whole file, however long. OpenAPI: "yes" past the warning.
pageNo
textNoHTML as readable text: no tags, scripts or styles, headings and list items kept as # and -. Often a few times shorter, for reading: edit_doc matches the HTML source. Markdown is already text. Slides: the outline.
depthNoOpenAPI: ref levels expanded.
entryNoA History entry number. Default: current.
groupNoOpenAPI: a group's operations.
itemsNoBoards only. These items whole, untrimmed: ["s12", "k3"] (50 at most).
linesNoOnly these lines of the file: "120-260", "120-" (to the end) or "120".
pagesNoWord docs: pages, "4" or "4-6".
sinceNoSlides, boards and Word docs: the version you read last. Slides: the outline marks who else edited which slide after it. Boards and Word docs: only what changed after it.
themeNoWith "kit" and no doc: the theme, Harbor, Harbor Dark, Paper, Slate (default Harbor).
typesNoOpenAPI: ["PostRefunds"] or {"ops", "lang": "ts"|"zod"|"pydantic"}.
blocksNoWord docs: blocks by ID, ["h3", "p14"]; a heading gives its section.
exportNoOpenAPI: a download link to the file as this.
framesNoBoards only. These frames' items, one line each by short ID, in reading order: ["f2"] (IDs or names, 10 at most).
slidesNoSlides only. These slides as HTML with data-box IDs: ["s3"] (IDs or names).
commentNoA thread's ID (cth_…): only that thread. A comment link as "doc" does the same.
densityNoWith "kit" and no doc: the density (default comfortable).
outlineNoOnly the details and the outline: each heading with the line it starts on.
refs_toNoOpenAPI: what uses a schema.
schemasNoOpenAPI: schema names.
breakingNoOpenAPI: with "since", only what breaks.
commentsNoThe doc's comment threads instead of its file: open (default with true), resolved or all.
approvalsNoThe doc's approval request and its history instead of its file.
positionsNoBoards only. Adds @x,y w×h to each line, in the frame's units, for placing things yourself. Most changes need none: use "in", "near", arrange and cluster. Database designs: // @x,y after each table, its place on the canvas.
suggestionsNoWord docs: the open suggestions, with IDs, who and what.
descriptionsNoOpenAPI: with descriptions.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true and destructiveHint=false, and the description adds genuinely useful behavior beyond that: the 20,000-character truncation to outline, the outline-first-then-drill pattern for Word docs, the per-version 'since' delta semantics, and the warning gate on OpenAPI 'full': "yes" past the warning. It does not state how large responses are bounded generally (only 'about 2 KB for 200 pages' for Word outlines) or how pagination/truncation suffixes ('…and N more') are surfaced consistently.

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?

Given 35 parameters across eight document types, length is partly earned, and it does front-load the core file-read behavior. But it is one undifferentiated wall of prose with no separators or grouping, mixing modality contracts, parameter tutorials and edit guidance, so an agent must scan the whole block to find the branch relevant to its document type.

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?

For a tool this broad with no output schema, the description covers the main return shapes (outline for sheets, HTML for slides, TOC for boards, block IDs and suggestion markers for Word) and the truncation fallbacks. Gaps remain for secondary parameters (text, page, export, depth, group, breaking, descriptions) and for how 'lines'/'full' interact with the outline path, but the high schema coverage and readOnly annotations absorb most of that risk.

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 97%, so the baseline is 3 and the schema already carries most parameter meaning. The description still adds cross-parameter routing that the schema cannot express per-parameter: which option applies to which document type, that 'kit' requires no doc and only needs one call, and that 'positions' is usually unnecessary because 'in', 'near', arrange and cluster exist. That is real added value, though it leaves 'text', 'page', 'export', 'depth', 'group', 'breaking' and 'descriptions' entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('A doc's file... Returns its details, then the file's text') and enumerates the document types it handles: files, sheets, slides, boards, Word docs, OpenAPI, DBML designs. An agent can tell it is the general read entry point. It does not distinguish itself from the sibling tool literally named 'read', which is a real ambiguity given both exist.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

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

Usage is conveyed per-modality rather than as explicit when/when-not rules: 'A file over 20,000 characters comes back as its outline... read the part you need with "lines", or all of it with "full"' tells the agent how to escalate, and 'kit: true ... (once is enough)' captures a caching rule. But nothing says when to call this instead of the sibling 'read', 'history', or 'changes', even though 'since' and 'entry' overlap conceptually with those tools.

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