Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

cloud_pull_branch

Destructive

Downloads a saved design or branch from your Kiln cloud account to this machine so you can work on it locally.

Instructions

Bring a design you saved to your Kiln account down to this machine.

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": {
      "design_id": "<design_id>"
    },
    "name": "cloud_pull_branch"
  }
}

Input Schema

NameRequiredDescriptionDefault
remoteNoRemote alias, as registered with ``cloud_remote_add`` (default: ``"default"``). Default: "default".
branch_idNoThe branch to pull, by id. Omitted along with ``branch_name``, the design's default trunk.
design_idYesThe design's id, as ``list_designs`` returns it.
branch_nameNoThe branch to pull, by name, when no ``branch_id`` is given.
since_version_idNoSkip versions up to this one, already present locally. Omitted, every version on the branch.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed5 schema fields changedv1.5.1
    • addedInput schema / properties / branch_id / description
      Added value: +"The branch to pull, by id.  Omitted along with ``branch_name``, the design's default trunk."
    • addedInput schema / properties / branch_name / description
      Added value: +"The branch to pull, by name, when no ``branch_id`` is given."
    • addedInput schema / properties / design_id / description
      Added value: +"The design's id, as ``list_designs`` returns it."
    • changedInput schema / properties / remote / description
      Previous value: -"Default: \"default\"."New value: +"Remote alias, as registered with ``cloud_remote_add`` (default: ``\"default\"``). Default: \"default\"."
    • addedInput schema / properties / since_version_id / description
      Added value: +"Skip versions up to this one, already present locally.  Omitted, every version on the branch."
  2. Addedv1.5.0

TDQS

C2.5/5.0
Behavior2/5

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

Annotations declare readOnlyHint=false and destructiveHint=true, so the agent knows this mutates local state, but the description frames the operation purely as 'bringing down', which reads as harmless. It says nothing about overwriting local branch state, conflict handling, or what happens to uncommitted local work — the exact behavior that makes this destructive. Some credit for adding the cloud-account-to-local-machine direction, but no risk disclosure.

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?

One short sentence with no filler, so nothing is wasted, but it is under-specified rather than concise. Being front-loaded does not help when the content itself is too thin for a destructive write operation.

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?

For a five-parameter, destructive, non-open-world operation with no output schema, the description should at minimum say what local state is affected and that a remote must already be configured. None of that is present; the one-line description is far below what this tool's complexity warrants.

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% and five parameters are all documented in-schema, including defaults for remote and the branch_id/branch_name fallback. The description adds no additional meaning, so the baseline of 3 applies.

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 verb phrase 'Bring ... down to this machine' plus 'a design you saved to your Kiln account' gives a rough sense of a cloud-to-local transfer, but the tool is named cloud_pull_branch and the description never mentions branches at all, calling the resource a 'design'. Against siblings like cloud_pull_feature_branch, cloud_pull_preset_branch, and cloud_clone_design, an agent cannot tell what is actually being pulled or how this differs.

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?

There is no when-to-use guidance, no prerequisites (e.g. remote must be registered first), and no mention of alternatives. With three near-identical pull siblings and a clone sibling in the list, the absence of any routing signal is a real gap.

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