Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

detect_merge_conflicts

Read-only

Compare two branches or design versions with a three-way diff before merging to show what combines cleanly and which conflicting changes need resolution.

Instructions

Three-way diff of two branches: what merges, and what must be decided.

Free door, tiered answer — Free: Branch · merge · cherry-pick · undo, on the designs you keep · Pro: Branch · merge · cherry-pick · undo, on every design · Business: ✓ · Enterprise: ✓.

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": "detect_merge_conflicts"
  }
}

Input Schema

NameRequiredDescriptionDefault
resolutionsNoSketch basis only: answers to open questions, ``{item_id: choice}``, where a choice is ``prefer_branch_a``, ``prefer_branch_b``, ``apply_neither``, a branch's name or ``original``; ``{"*": choice}`` answers every item not named. On the mesh basis they are not used, and ``basis_note`` says so.
source_linesNoMesh basis only: the ``[start_line, end_line]`` ranges the source side changed in the part's source code. With ``target_lines`` also given, overlapping ranges are reported as conflicts.
target_linesNoMesh basis only: the ``[start_line, end_line]`` ranges the target side changed in the part's source code.
source_branch_idNoId of the branch being merged in. Give it together with ``target_branch_id``; one without the other is refused.
target_branch_idNoId of the branch being merged into. Give it together with ``source_branch_id``.
source_version_idNoDesign version id of the side being merged in. Ignored when both branch ids are given (the source branch's head is used).
target_version_idNoDesign version id of the side being merged into. Ignored when both branch ids are given (the target branch's head is used).
ancestor_version_idNoDesign version id of the common ancestor. Optional: Kiln finds where the two sides really split in the version history and reads from there, saying so in ``basis_note`` when the id given differs. Used as the base only when the history holds no common ancestor.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.5.1
    • addedInput schema / properties / ancestor_version_id / description
      Added value: +"Design version id of the common ancestor. Optional: Kiln finds where the two sides really split in the version history and reads from there, saying so in ``basis_note`` when the id given differs.  Used as the base only when the history holds no common ancestor."
    • addedInput schema / properties / resolutions / description
      Added value: +"Sketch basis only: answers to open questions, ``{item_id: choice}``, where a choice is ``prefer_branch_a``, ``prefer_branch_b``, ``apply_neither``, a branch's name or ``original``; ``{\"*\": choice}`` answers every item not named. On the mesh basis they are not used, and ``basis_note`` says so."
    • addedInput schema / properties / source_branch_id / description
      Added value: +"Id of the branch being merged in.  Give it together with ``target_branch_id``; one without the other is refused."
    • addedInput schema / properties / source_lines / description
      Added value: +"Mesh basis only: the ``[start_line, end_line]`` ranges the source side changed in the part's source code. With ``target_lines`` also given, overlapping ranges are reported as conflicts."
    • addedInput schema / properties / source_version_id / description
      Added value: +"Design version id of the side being merged in.  Ignored when both branch ids are given (the source branch's head is used)."
    • addedInput schema / properties / target_branch_id / description
      Added value: +"Id of the branch being merged into.  Give it together with ``source_branch_id``."
    • addedInput schema / properties / target_lines / description
      Added value: +"Mesh basis only: the ``[start_line, end_line]`` ranges the target side changed in the part's source code."
    • addedInput schema / properties / target_version_id / description
      Added value: +"Design version id of the side being merged into.  Ignored when both branch ids are given (the target branch's head is used)."
  2. Addedv1.5.0

TDQS

C2.4/5.0
Behavior2/5

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

Annotations already declare readOnlyHint, destructiveHint=false and closed-world scope, so safety is covered. The description adds no behavioral context beyond that – nothing on what a conflict result looks like, how the two modes (branch/version vs. sketch/mesh basis) behave, or what happens when branch and version ids are mixed – and half the text is subscription-tier boilerplate unrelated to behavior.

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

Conciseness2/5

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

The description is split between one useful sentence and one sentence of marketing tier gating ('Free door, tiered answer — Free: … Pro: … Business: ✓ …') that is confusing, duplicated across tiers and irrelevant to invocation. The useful content is not front-loaded to completion.

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?

With 8 optional parameters, a nested resolutions object, two distinct operating bases and no output schema, the description should explain at least the shape of a conflict report and the two basis modes. It says only 'what merges, and what must be decided' and spends the remainder on pricing, leaving a complex tool under-explained.

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%, with detailed per-parameter notes (resolutions, source_lines/target_lines, branch vs. version id precedence, ancestor fallback). The description adds no parameter meaning beyond the schema, so the baseline 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 first sentence gives a recognizable verb/resource pair (three-way diff of two branches) but never explicitly says it detects and reports merge conflicts, and it draws no boundary against close siblings such as detect_feature_merge_conflicts, detect_decoration_preset_merge_conflicts or compare_branches.

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 statement of when to call this versus merge_design_branches, source_merge_three_way or the other detect_*_merge_conflicts tools, and no prerequisites (e.g. that it is a read-only pre-check before merging). The only 'guidance' offered is a pricing-tier table, which does not help an agent decide whether to invoke the tool.

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