Skip to main content
Glama
Sign In
Slicewise

Slicewise

by gjlmotea
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

List presets

bambu_list_presets
Read-onlyIdempotent

Lists selectable machine, process, or filament presets for Bambu Studio and filters out inheritance-only intermediates by default, helping you identify a preset to inspect or resolve.

Instructions

Lists machine, process or filament presets. By default only presets selectable in the UI are returned; intermediate presets that exist only to be inherited from (e.g. fdm_process_common) are filtered out. Names listed here do not show real setting values; use bambu_resolve_preset for that. No side effects.

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

Input Schema

NameRequiredDescriptionDefault
kindYes
limitNo
searchNoFilter by a case-insensitive substring of the preset name.
includeAbstractNoWhether to include intermediate presets that exist only to be inherited from and cannot be selected in the UI. Defaults to false.

Output Schema

NameRequiredDescriptionDefault
kindYes
totalYes
entriesYes
returnedYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive and closed-world, so safety needs no restating (and "No side effects" is redundant). The description earns credit for disclosing the non-obvious filtering default: intermediate inheritance-only presets like fdm_process_common are dropped unless overridden, which an agent could not infer from the schema alone.

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?

Three short sentences, front-loaded with the core action, then the default filter, then the sibling pointer. The only waste is the trailing "No side effects," which merely repeats the readOnlyHint/destructiveHint annotations.

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 simple read-only listing tool with an output schema (so return shape needn't be explained) and four parameters, this covers the two things an agent would otherwise get wrong: what the list contains and where real values live. The remaining gap is result capping — nothing tells the agent that `limit` caps at 200 or whether the list can be truncated.

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 50%: `search` and `includeAbstract` are already documented in the schema, and the description restates the abstract-filtering default rather than adding new detail. The `kind` enum is named implicitly by the three categories, but `limit` (1-200, no description in schema) is never addressed, leaving a real gap unpatched.

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

Purpose5/5

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

The description opens with a specific verb and resource ("Lists machine, process or filament presets") and immediately distinguishes the output from the sibling bambu_resolve_preset, which returns real setting values. An agent can tell what it gets here versus what it must call next without opening any schema.

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?

It gives explicit routing: use bambu_resolve_preset when actual setting values are needed, and this tool only when names are sufficient. It also explains the default selection scope (UI-selectable only). It stops short of guidance on other siblings such as bambu_compare_presets or when to widen with includeAbstract, but the core when/when-not split is clear.

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