Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

evaluate_pr_approval

Read-only

Check if a pull request can merge by dry-running its target branch's approval gate, returning allowed status plus a reason such as needs_1_more_approval, blocked_by_change_requests, or gate_satisfied.

Instructions

Dry-run the approval gate on pr_id — returns allowed + a detailed reason ("needs_1_more_approval", "blocked_by_change_requests", "gate_satisfied", or "no_gate_configured").

Needs Kiln Business.

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": {
      "pr_id": "<pr_id>",
      "target_branch_name": "<target_branch_name>"
    },
    "name": "evaluate_pr_approval"
  }
}

Input Schema

NameRequiredDescriptionDefault
pr_idYesThe id of the pull request to check.
org_idNoOptional. The org that owns the pull request's artifact; Kiln reads it from the artifact itself, and a value naming a different org is refused with ``ORG_MISMATCH``.
artifact_typeNoWhat the pull request changes: ``"design"`` (the default), ``"preset"`` or ``"feature"``. Default: "design".
target_branch_nameYesThe name of the branch the pull request would merge into, for example ``main``; its gate is the one checked.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / artifact_type / description
      Previous value: -"Default: \"design\"."New value: +"What the pull request changes: ``\"design\"`` (the default), ``\"preset\"`` or ``\"feature\"``. Default: \"design\"."
    • addedInput schema / properties / org_id / description
      Added value: +"Optional.  The org that owns the pull request's artifact; Kiln reads it from the artifact itself, and a value naming a different org is refused with ``ORG_MISMATCH``."
    • addedInput schema / properties / pr_id / description
      Added value: +"The id of the pull request to check."
    • addedInput schema / properties / target_branch_name / description
      Added value: +"The name of the branch the pull request would merge into, for example ``main``; its gate is the one checked."
  2. Addedv1.5.0

TDQS

A4/5.0
Behavior4/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 safety is covered. The description goes beyond them by disclosing the exact return shape (allowed plus a closed set of reason codes) and a plan-tier requirement ("Needs Kiln Business"), which is behavior the agent cannot infer from structured fields.

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

Conciseness5/5

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

Two short sentences with the core action and return contract front-loaded, followed by the entitlement note. Every clause carries information — the outcome list is what makes the tool interpretable — and there is no filler.

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?

There is no output schema, and the description compensates by spelling out the returned fields and reason codes, which is exactly what an agent needs to interpret results. The entitlement note and the "dry-run" framing round it out; only explicit routing to sibling tools is missing.

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 all four parameters (including org_id's ORG_MISMATCH behavior and artifact_type's enum-like values) are already fully documented in the schema. The description adds essentially no parameter-level meaning beyond naming pr_id, which is the expected baseline of 3 when the schema does the work.

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

Purpose5/5

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

The description states a specific verb and resource — "Dry-run the approval gate on pr_id" — and enumerates the possible outcomes ("needs_1_more_approval", "blocked_by_change_requests", "gate_satisfied", "no_gate_configured"). An agent can immediately tell this apart from set_approval_gate or list_approval_gates because the word "dry-run" and the outcome vocabulary make clear it only evaluates.

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?

"Dry-run" implies the check is non-mutating and done before merging, and "Needs Kiln Business" states an entitlement prerequisite. However, the description never names an alternative tool (e.g. review_design_pull_request, get_design_pull_request, list_approval_gates) or says explicitly when not to use it, leaving usage context implied rather than stated.

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