Skip to main content
Glama
Sign In

Dockito

by ai.dockito
OverviewDiscussionsAdmin

Ask for, give or reject a doc's approval

approval

As the user. request: ask people to approve the doc as it is now (the user needs Edit; "to" are names, "@Full Name" or "@First", each with Comment or Edit on the doc, at most 10), with "message", "due" (yyyy-mm-dd) and "lock" (nobody can change the doc until it's approved, rejected or cancelled). One open request a doc; they're told in the app. The version asked on is kept as a saved point in History. approve (a "reason" optional) or reject (a "reason" needed) the open request, as one of its approvers, on "version", the doc's version you read (get with "approvals" says it): a newer one refuses it, so read again and answer on the latest (to approve an older version, restore it first). Any rejection closes it, and it's approved once every approver has approved the latest version. cancel withdraws it (its requester, or whoever manages the doc). The token needs Publish or Everything.

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": {
      "doc": "<doc>",
      "action": "<action>"
    },
    "name": "approval"
  }
}

Input Schema

NameRequiredDescriptionDefault
toNorequest: who approves, by name ("@Mia Chen", "@Max").
docYesThe doc's link or its code.
dueNorequest: when it's due, yyyy-mm-dd.
lockNorequest: lock the doc while it's pending.
actionYesrequest, approve, reject or cancel.
reasonNoapprove: an optional note; reject: what to change (needed).
messageNorequest: what to look at.
versionNoapprove, reject: the doc's version you read, from get with "approvals" (needed).

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=false, readOnlyHint=false), the description discloses side effects the annotations do not: lock freezes the doc, the requested version is saved as a point in History, any rejection closes the request, approval requires every approver on the latest version, requesters are notified in-app, and the token needs Publish or Everything. That is substantial behavioral context that the annotation set alone cannot convey.

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?

Every clause carries information, but it is delivered as one dense run-on paragraph with action keywords buried mid-sentence in quotes, so an agent must parse carefully to separate request rules from approve/reject rules. It is efficient in length but poorly structured and not front-loaded per action.

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 an 8-parameter, four-action mutation tool with no output schema, it covers prerequisites, side effects, versioning pitfalls, and notification behavior well. What it lacks is any statement of what a successful call returns (e.g. the resulting request state or identifier), which matters slightly given no output schema.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: "to" entries carry permission requirements and a cap of 10, "due" is yyyy-mm-dd, "lock" means nobody can change the doc until resolved, and "version" must match the doc's current version or the call is refused. Only minor gaps remain (e.g. format of doc codes or name-matching fallbacks).

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 title and the action keywords ("request", "approve", "reject", "cancel") clearly frame this as a doc approval-workflow tool, distinct from neighbours like share, publish or comment. It is specific about the resource (a doc's approval) and the four operations, but it never explicitly names a sibling tool it differs from, so the differentiation is inferred rather than stated.

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 spells out per-action conditions: request needs Edit and approvers with Comment/Edit (max 10), approve/reject must be done as an approver on the version you read, and "a newer one refuses it, so read again and answer on the latest (to approve an older version, restore it first)". It also explains cancel's authority rules and the one-open-request limit, which is real when/when-not guidance with an explicit alternative path (restore).

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