Skip to main content
Glama
Sign In
Kiln

Kiln

by codeofaxel
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python

recommend_static_dissipative_material

Read-only

Recommend static-dissipative materials for ESD-safe 3D printed parts. Assess a named grade against application, printer compatibility, and service temperature.

Instructions

Which static-dissipative material for this job -- or whether the one you named fits.

Free door, tiered answer — Free: Safety basics — always free · Pro: Safety basics · Business: Grade selection & sourcing for your printer · Enterprise: + Audit-ready ESD program support.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "recommend_static_dissipative_material"
  }
}

Input Schema

NameRequiredDescriptionDefault
materialNoOptional -- assess ONE named grade (e.g. "PETG-ESD", "abs_esd") instead of ranking the family. Default: "".
printer_idNoOptional printer to route against -- each candidate carries that machine's own compatibility verdict. Default: "".
applicationNoWhat the part does -- e.g. "SMT board nest", "component tote", "ICT fixture", "device enclosure". Default: "".
max_service_temp_cNoOptional hard service temperature the part must survive, in Celsius.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changedv1.5.1
    • changedInput schema / properties / application / description
      Previous value: -"Default: \"\"."New value: +"What the part does -- e.g. \"SMT board nest\", \"component tote\", \"ICT fixture\", \"device enclosure\". Default: \"\"."
    • changedInput schema / properties / material / description
      Previous value: -"Default: \"\"."New value: +"Optional -- assess ONE named grade (e.g. \"PETG-ESD\", \"abs_esd\") instead of ranking the family. Default: \"\"."
    • addedInput schema / properties / max_service_temp_c / description
      Added value: +"Optional hard service temperature the part must survive, in Celsius."
    • changedInput schema / properties / printer_id / description
      Previous value: -"Default: \"\"."New value: +"Optional printer to route against -- each candidate carries that machine's own compatibility verdict. Default: \"\"."
  2. Addedv1.5.0

TDQS

B3.3/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 one genuinely behavioral fact not in the annotations: the answer is tier-gated, so on Free/Pro the response is limited to safety basics while grade selection and sourcing require Business. That caveat is useful but is delivered as an upgrade pitch with garbled repetition ('Safety basics — always free · Pro: Safety basics'), and nothing is said about the shape of the result or how verdicts are expressed.

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 tight and front-loaded. The second line, however, is plan/pricing boilerplate that repeats 'Safety basics' twice, uses an em-dash chain instead of structure, and consumes roughly half the description without telling an agent how to call the tool. It should be either cut or reduced to a single caveat about tier-limited answers.

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 zero required parameters, no output schema, and full schema coverage, the description only needs to say what comes back and how modes behave. It covers the two request modes but says nothing about the response (ranked candidates with per-printer compatibility verdicts) or what happens when application/temperature are omitted. Adequate but with clear gaps for a tool whose value is entirely in its returned recommendation.

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 optional parameters are already documented, including the material/printer_id/application distinction. The description reinforces the material parameter's dual role (name one grade to assess versus omit it to rank the family), but adds no format, range, or interaction semantics beyond that. Baseline 3 is appropriate when the schema carries the detail.

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 gives a concrete verb and resource: it recommends a static-dissipative material for a job, or validates a named grade against that job. It states the two operating modes (rank the family vs. assess ONE named grade), which is specific. It does not differentiate itself from the many sibling material tools (recommend_material, recommend_design_material, get_material_recommendation), so an agent must infer the niche from the title alone.

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 implied by 'for this job -- or whether the one you named fits', which suggests calling it when selecting a material or checking a candidate. There are no explicit exclusions, no prerequisites (e.g. printer_id needed for a per-machine verdict), and no named alternative among the crowded set of material-recommendation siblings. The tier line hints at what is available per plan but is not framed as usage guidance.

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