Skip to main content
Glama

cloud_documents

Destructive

Push documents to your Kiln account or pull them back to this computer to sync manuals, drawings, assessments, fair evidence, and insertions.

Instructions

Push your documents to your Kiln account, or pull them back to this computer.

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": {
      "action": "<action>",
      "kind": "<kind>"
    },
    "name": "cloud_documents"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYes``"manuals"``, ``"drawings"``, ``"assessments"``, ``"fair"`` or ``"insertions"``.
limitNoPull only: at most this many records. ``0`` (the default) means the kind's own cap: 200 for fair, 50 for assessments and insertions. Default: 0.
actionYes``"push"`` or ``"pull"``.
remoteNoRemote alias (default: ``"default"``). Default: "default".
serialNoinsertions only — one part's serial. Default: "".
design_idNoThe design (manuals: required; drawings: optional; assessments pull: optional filter). Default: "".
intake_idNoThe drawing intake (assessments: required). Default: "".
bundle_pathNofair push only — an exported evidence bundle (from ``manage_fair_evidence_bundle``) to freeze. Default: "".
record_kindNofair only — one record kind. Default: "".
bundle_digestNofair pull only — fetch and verify one bundle. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.5.1
    • addedInput schema / properties / action / description
      Added value: +"``\"push\"`` or ``\"pull\"``."
    • changedInput schema / properties / bundle_digest / description
      Previous value: -"Default: \"\"."New value: +"fair pull only — fetch and verify one bundle. Default: \"\"."
    • changedInput schema / properties / bundle_path / description
      Previous value: -"Default: \"\"."New value: +"fair push only — an exported evidence bundle (from ``manage_fair_evidence_bundle``) to freeze. Default: \"\"."
    • changedInput schema / properties / design_id / description
      Previous value: -"Default: \"\"."New value: +"The design (manuals: required; drawings: optional; assessments pull: optional filter). Default: \"\"."
    • changedInput schema / properties / intake_id / description
      Previous value: -"Default: \"\"."New value: +"The drawing intake (assessments: required). Default: \"\"."
    • addedInput schema / properties / kind / description
      Added value: +"``\"manuals\"``, ``\"drawings\"``, ``\"assessments\"``, ``\"fair\"`` or ``\"insertions\"``."
    • changedInput schema / properties / limit / description
      Previous value: -"Default: 0."New value: +"Pull only: at most this many records.  ``0`` (the default) means the kind's own cap: 200 for fair, 50 for assessments and insertions. Default: 0."
    • changedInput schema / properties / record_kind / description
      Previous value: -"Default: \"\"."New value: +"fair only — one record kind. Default: \"\"."
    • changedInput schema / properties / remote / description
      Previous value: -"Default: \"default\"."New value: +"Remote alias (default: ``\"default\"``). Default: \"default\"."
    • changedInput schema / properties / serial / description
      Previous value: -"Default: \"\"."New value: +"insertions only — one part's serial. Default: \"\"."
  2. Addedv1.5.0

TDQS

C2.6/5.0
Behavior2/5

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

Annotations already declare destructiveHint=true and readOnlyHint=false, but the description provides no context on what that destruction means: whether push overwrites remote records, whether pull overwrites local files, whether partial failures are possible, or what limits per kind apply. For a destructive two-way sync tool, the description should flag overwrite semantics and any auth requirement; it adds nothing beyond restating the two directions.

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

Conciseness4/5

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

A single well-formed sentence that front-loads both actions with zero filler. It is efficient but arguably under-specified rather than over-long, so it does not reach a 5.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a ten-parameter tool spanning five record kinds with conditional fields (design_id required for manuals, intake_id required for assessments, bundle_path for fair push, bundle_digest for fair pull) and no output schema. The description covers only the generic push/pull axis and omits the kind taxonomy and the conditional requirements an agent needs before calling it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the ten parameters (kind, limit, remote, serial, design_id, intake_id, bundle_path, record_kind, bundle_digest) is already documented in the schema, and the description mentions none of them. Baseline 3 applies: no value added, but no harm because the schema carries the load.

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

Purpose3/5

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

The description gives a clear verb pair (push/pull) and a resource ('documents', 'Kiln account'), but 'documents' is far too generic for a tool whose schema enumerates five distinct kinds (manuals, drawings, assessments, fair, insertions). It also does not distinguish this tool from the many cloud siblings such as cloud_push_branch, cloud_pull_branch, cloud_sync_now, or upload_file, so an agent cannot tell from the text alone which one it wants.

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

Usage Guidelines2/5

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

The description names two actions but never says when to choose push versus pull, what prerequisites exist (e.g. being signed in to Kiln), or how this differs from the cloud_sync_* and cloud_push_*/cloud_pull_* alternatives. Prerequisite and alternative routing are left entirely to inference.

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

Deploy Server

Other Tools