Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

decoration_info

Read-only

Retrieve full details for a saved decoration—settings, content paths, tags, processing pipeline, and library location. Verify configuration and locate files before reuse.

Instructions

Get full details about a saved decoration.

        Shows the decoration's proven settings, content paths, tags,
        processing pipeline, and library location.

        :param name: Decoration name or slug.
        :returns: Dict with full decoration details and file paths.

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

Input Schema

NameRequiredDescriptionDefault
nameYesDecoration name or slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / name / description
      Added value: +"Decoration name or slug."
  2. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already establish readOnlyHint=true, destructiveHint=false, and openWorldHint=false, so safety needs no restating. What the description adds is genuinely useful: it discloses the scope of data exposed, including local file paths and library location, which tells an agent that the response carries filesystem information. It stops short of describing pagination, error cases, or response shape details beyond the generic returns line.

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?

The definition is short and front-loaded, leading with the verb and resource before the return-content list. The Sphinx-style :param line is redundant boilerplate against a schema that already documents `name`, while the :returns line earns its place because no output schema exists.

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, read-only lookup tool with no output schema, the description is close to sufficient: it names the kinds of data returned and confirms a dict with file paths. The remaining gap is that the exact keys of the returned dict are only sketched, leaving an agent to inspect the response rather than plan around it.

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?

The single parameter has 100% schema coverage with the description "Decoration name or slug," and the description repeats that text verbatim in the :param line, adding no new meaning. With full schema coverage, the baseline of 3 applies; the description neither clarifies slug formatting nor what happens if a plain display name is ambiguous.

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?

The description uses a specific verb and resource ("Get full details about a saved decoration") and then enumerates the exact facets returned: proven settings, content paths, tags, processing pipeline, and library location. This distinguishes it from list_decorations, which presumably returns summaries, though the sibling is never named explicitly.

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 phrase "a saved decoration" combined with the required `name` parameter implies this is a lookup for a decoration you can already identify, and the contrast with listing tools is inferable from "full details." However, there is no explicit when-to-use statement, no mention of list_decorations as the discovery alternative, and no prerequisites or error behavior for an unknown name.

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