Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

resolve_model_source

Read-only

Trace a .3mf or .gcode.3mf file back to its source by reading Kiln notes or embedded metadata, returning model title, designer, URL, slicer, and plate objects.

Instructions

Identify where a model file came from.

A file Kiln downloaded from a marketplace or a generator answers from
the note Kiln left beside it, in any format (``came_from`` says it in
a sentence).  Otherwise a .3mf or .gcode.3mf answers from its embedded
metadata: MakerWorld metadata and generic 3MF metadata (Title,
Designer, Application, License, etc.).

Returns the model title, designer, model URL (if available), slicer
application name, and a list of objects on the plate.

Use this when you need to trace a file back to its source — for
example, to find the original STL files on MakerWorld when the
.gcode.3mf only contains pre-sliced G-code without mesh geometry.

:param file_path: Path to the .3mf or .gcode.3mf file.
:returns: Dict with source marketplace, model URL, designer info,
    and plate object names.

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

Input Schema

NameRequiredDescriptionDefault
file_pathYesPath to the .3mf or .gcode.3mf file.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.5.1
    • addedInput schema / properties / file_path / description
      Added value: +"Path to the .3mf or .gcode.3mf file."
  2. First observedv0.1.0

TDQS

A3.6/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 safety is covered. The description adds real behavioral value by disclosing the precedence of resolution sources (Kiln's note in any format, then MakerWorld or generic 3MF metadata) and the fallback when no note exists. It does not say what happens when a file is neither, or whether the call touches the network for marketplace lookups.

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?

Front-loaded with the core purpose, then detail in decreasing priority. The trailing reST :param:/:returns: block partially duplicates the schema and the prose, costing some efficiency but not obscuring the key information.

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?

No output schema exists, so the description carries the return shape and does so concretely: title, designer, model URL, slicer application name, and plate object names, plus which metadata fields feed them. Combined with the single required parameter, an agent has enough to call it correctly; only error/empty-result behavior is unstated.

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?

With a single parameter at 100% schema description coverage, the schema already documents file_path fully; the description merely repeats 'Path to the .3mf or .gcode.3mf file' via a :param: line. Baseline 3 applies since no additional syntax, path-scope, or validation semantics are offered.

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 opening line gives a specific verb and resource ('Identify where a model file came from'), and the follow-up explains the resolution chain (Kiln's came_from note first, then embedded 3MF/MakerWorld metadata). It stops short of naming near-siblings such as extract_file_metadata or get_design_source, so an agent must infer why this differs from a generic metadata extractor.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicit 'Use this when you need to trace a file back to its source' with a concrete scenario — locating original STLs on MakerWorld when a .gcode.3mf holds only pre-sliced G-code. There is no statement of when NOT to use it or which sibling to pick for plain metadata reads, which keeps it below a 5.

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