Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

generate_magnet_qc_plan

Read-only

Generate a Business-tier QC plan for a magnetized printed product, covering per-machine fit, validation tests, and fleet-wide quality checks.

Instructions

Generate a Business-tier QC plan for a magnetized printed product.

Free door, tiered answer — Free: Warnings — always free · Pro: Sizing and fit for the hardware you bought · Business: + Per-machine fit, validation tests and QC plans across your fleet · Enterprise: + Child-safety & supplier vetting for magnets.

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

Input Schema

NameRequiredDescriptionDefault
coatingNoThe coating proposed, as the ``coating_id`` a magnet recommendation returns. Checked against a wet, outdoor or body-adjacent context; empty skips the check. Default: "".
use_caseYesProduct/use description, e.g. "removable access panel", "magnetic badge", "wall-mounted tool holder", "phone mount".
max_temp_cNoExpected maximum service temperature in degrees C, if known; omitted, no heat-margin check is made.
environmentNoindoor, humid, sweat, outdoor, hot_car, washdown, etc. Defaults to ``indoor``. Default: "indoor".
grade_classNoThe grade used, as the ``grade_class_id`` a magnet recommendation returns; with ``max_temp_c`` it adds a heat-margin check. Empty skips it. Default: "".
body_adjacentNoTrue for wearables, badges, phone/watch accessories, etc. Default: false.
magnet_familyNoThe magnet family used, e.g. "neodymium", "ferrite". Read together with ``retention_method`` for the risk read; empty skips that part. Default: "".
child_accessibleNoTrue if children may access/mouth it. Default: false.
retention_methodNoHow the magnet is mounted, e.g. "mechanical", "adhesive", "pocket". Adhesive-only is flagged for a commercial batch; with ``magnet_family`` it also reads recorded field outcomes. Default: "".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed9 schema fields changedv1.5.1
    • changedInput schema / properties / body_adjacent / description
      Previous value: -"Default: false."New value: +"True for wearables, badges, phone/watch accessories, etc. Default: false."
    • changedInput schema / properties / child_accessible / description
      Previous value: -"Default: false."New value: +"True if children may access/mouth it. Default: false."
    • changedInput schema / properties / coating / description
      Previous value: -"Default: \"\"."New value: +"The coating proposed, as the ``coating_id`` a magnet recommendation returns.  Checked against a wet, outdoor or body-adjacent context; empty skips the check. Default: \"\"."
    • changedInput schema / properties / environment / description
      Previous value: -"Default: \"indoor\"."New value: +"indoor, humid, sweat, outdoor, hot_car, washdown, etc. Defaults to ``indoor``. Default: \"indoor\"."
    • changedInput schema / properties / grade_class / description
      Previous value: -"Default: \"\"."New value: +"The grade used, as the ``grade_class_id`` a magnet recommendation returns; with ``max_temp_c`` it adds a heat-margin check. Empty skips it. Default: \"\"."
    • changedInput schema / properties / magnet_family / description
      Previous value: -"Default: \"\"."New value: +"The magnet family used, e.g. \"neodymium\", \"ferrite\".  Read together with ``retention_method`` for the risk read; empty skips that part. Default: \"\"."
    • addedInput schema / properties / max_temp_c / description
      Added value: +"Expected maximum service temperature in degrees C, if known; omitted, no heat-margin check is made."
    • changedInput schema / properties / retention_method / description
      Previous value: -"Default: \"\"."New value: +"How the magnet is mounted, e.g. \"mechanical\", \"adhesive\", \"pocket\".  Adhesive-only is flagged for a commercial batch; with ``magnet_family`` it also reads recorded field outcomes. Default: \"\"."
    • addedInput schema / properties / use_case / description
      Added value: +"Product/use description, e.g. \"removable access panel\", \"magnetic badge\", \"wall-mounted tool holder\", \"phone mount\"."
  2. Addedv1.5.0

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare a safe, closed-world read (readOnlyHint true, openWorldHint false, destructiveHint false), so the description's main job is to add output-shape context – which it does by disclosing that the response degrades by tier (warnings only at Free, sizing at Pro, per-machine fit and QC plans at Business, child-safety and supplier vetting at Enterprise). That is genuinely useful behavioral context beyond the annotations, though it never says whether a lower-tier call errors, truncates, or returns upsell text.

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

Conciseness3/5

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

The opening sentence is a clean, front-loaded statement of purpose. The second sentence is a long marketing tier ladder that consumes more space than the actual tool behavior and opens with the opaque phrase 'Free door, tiered answer', which does not earn its place in a tool definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With nine parameters, no output schema, and no enumeration of what a 'QC plan' actually contains, the description leaves the return value underspecified – an agent knows it gets 'a plan' but not whether that is structured checks, text, or a document reference. Tier gating is covered, but plan contents and failure behavior at insufficient tier are not.

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 all nine parameters individually documented, so the baseline of 3 applies. The description text adds no parameter-level meaning beyond what the schema already says; the useful hints (coating_id/grade_class_id coming from a magnet recommendation) live in the schema, not the description.

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 first sentence names a specific verb and resource: generate a QC plan for a magnetized printed product, scoped to Business tier. It is clear what is produced, but it never distinguishes itself from adjacent magnet tools such as check_magnet_design, recommend_magnet_for_product, or review_magnet_supplier_packet, so an agent must infer the boundary.

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?

Usage is only implied: the tier ladder tells the agent what it gets at each subscription level, and several parameter descriptions hint the tool is called after a magnet recommendation ('as the coating_id a magnet recommendation returns'). There is no explicit statement of when to use this versus check_magnet_design or when it is inappropriate.

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