Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

archive_feature

Destructive

Hide a mechanical feature from default listings while preserving all versions, branches, link events, and outcomes. Requires Kiln Pro.

Instructions

Archive a mechanical feature — hide it from default listings while preserving every version, branch, link event, and outcome.

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": {
      "feature_id": "<feature_id>"
    },
    "name": "archive_feature"
  }
}

Input Schema

NameRequiredDescriptionDefault
feature_idYesId of the feature to archive. Every version of it is flagged; ``versions_updated`` says how many.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / feature_id / description
      Added value: +"Id of the feature to archive.  Every version of it is flagged; ``versions_updated`` says how many."
  2. Addedv1.5.0

TDQS

A3.8/5.0
Behavior4/5

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

Beyond the annotations (destructiveHint=true, readOnlyHint=false, openWorldHint=false), the description discloses the preserved surface area — versions, branches, link events, outcomes — which is exactly the reassurance an agent needs before calling a destructive-hinted tool. It adds the plan requirement (Kiln Pro) but does not mention reversibility via unarchive or any rate/permission behavior.

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, the effect and the data-preservation guarantee front-loaded, with the licensing prerequisite as a trailing footnote. 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?

For a one-parameter, annotated tool with no output schema, the description covers purpose, scope of impact, and prerequisites adequately; the return field is documented in the schema. Only the relationship to unarchive_feature/delete_feature is left for the agent to infer.

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% and the schema itself already explains feature_id and the versions_updated return count, so the description need not restate it. The description adds nothing parameter-specific, which is the expected baseline when the schema does the work.

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

Purpose4/5

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

"Archive a mechanical feature" is a specific verb+resource, and "hide it from default listings while preserving every version, branch, link event, and outcome" defines the exact effect, implicitly contrasting with delete_feature. It stops short of naming that sibling outright, so the agent must infer the contrast rather than being routed to it.

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?

The "Needs Kiln Pro" line is a genuine prerequisite, and the preservation wording implies when this is preferable to deletion. However, no explicit when-to-use/when-not or alternative (delete_feature, unarchive_feature, retire_feature_branch) is named, so selection guidance is left implicit.

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