Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

list_feature_cherry_pick_candidates

Read-only

List isolatable modifications in a source feature version compared with an ancestor to identify changes suitable for cherry-picking.

Instructions

Enumerate isolatable modifications in source relative to ancestor.

Needs Kiln Pro.

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": {
      "ancestor_feature_version_id": "<ancestor_feature_version_id>",
      "source_feature_version_id": "<source_feature_version_id>"
    },
    "name": "list_feature_cherry_pick_candidates"
  }
}

Input Schema

NameRequiredDescriptionDefault
source_feature_version_idYesFeature version id holding the changes to list. Both versions must exist (``FEATURE_NOT_FOUND``).
ancestor_feature_version_idYesFeature version id the source is compared against.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv1.5.1
    • addedInput schema / properties / ancestor_feature_version_id / description
      Added value: +"Feature version id the source is compared against."
    • addedInput schema / properties / source_feature_version_id / description
      Added value: +"Feature version id holding the changes to list.  Both versions must exist (``FEATURE_NOT_FOUND``)."
  2. Addedv1.5.0

TDQS

B3.1/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is covered upstream. The description adds only the tier dependency; it says nothing about what a candidate record contains or how results are ordered or bounded, which matters for a listing tool with no output schema.

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?

Two short sentences with the operation stated first and the prerequisite second, no filler. The brevity is efficient, though it comes at the cost of the missing sibling differentiation rather than packing in useful detail.

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

Completeness3/5

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

For a read-only listing tool with complete schema documentation and no output schema, the description is barely adequate. An agent still cannot tell how this differs from list_cherry_pick_candidates or list_decoration_cherry_pick_candidates, nor what the returned candidates look like.

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 coverage is 100%, so both parameters are fully documented, including the FEATURE_NOT_FOUND condition. The phrase "source relative to ancestor" does add directional meaning (source changes measured against the ancestor baseline) beyond the schema's symmetric-looking fields, but nothing else.

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?

"Enumerate isolatable modifications in source relative to ancestor" gives a verb and the notion of a diff, but leans on undefined jargon ("isolatable modifications") and never says these are feature-version changes. With siblings named list_cherry_pick_candidates and list_decoration_cherry_pick_candidates, the description does nothing to signal that this variant operates on feature versions.

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?

"Needs Kiln Pro" is a genuine selection-relevant prerequisite (an agent on a non-Pro tier should not call it), and the diff framing implies it precedes cherry_pick_feature_modification. However, no alternative is named and no when-not condition is given, so the agent must infer the workflow position itself.

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