Slicewise

Overview Schema Source Related Servers Discussions Admin

Flatten a preset inheritance chain

bambu_resolve_preset

Read-onlyIdempotent

Flattens a BambuStudio preset's inherits chain into complete settings and records each value's source level, so you can retrieve actual parameter values instead of relying on sparse leaf files.

Instructions

Flattens a preset's inherits chain into the complete settings and records which level each value comes from. A BambuStudio leaf preset usually declares only a few dozen keys and inherits everything else from its parents, so to know the real value of any parameter you must look at the flattened result, not the leaf preset file. Use this whenever you need an actual setting value. 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": {
      "name": "<name>",
      "kind": "<kind>"
    },
    "name": "bambu_resolve_preset"
  }
}

Input Schema

Name	Required	Description
`keys`	No	Return only these parameters. Omit to return all of them (a process preset has about 200 keys).
`kind`	Yes
`name`	Yes

Output Schema

Name	Required	Description
`kind`	Yes
`name`	Yes
`origin`	Yes
`settings`	Yes
`provenance`	Yes	Which level of the inheritance chain each key actually comes from. Machine G-code may come from that level's template entry, named like "<preset> template machine_start_gcode".
`settingCount`	Yes
`inheritanceChain`	Yes	The inheritance chain, from the leaf preset to the root.

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Nov 7, 2026

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, and non-destructive behavior, so the bar is lower; the description reinforces this with 'No side effects' and adds genuine context about how BambuStudio inheritance works, explaining why the leaf file is not the source of truth. It omits failure behavior for an unknown preset name or missing parent chain, which would be useful for a resolver.

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

Conciseness5/5

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

Three tight sentences, front-loaded with the action and payoff, then the rationale, then the safety note. No filler and no repetition of schema content.

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?

An output schema exists, so return values needn't be explained, and annotations cover safety. The description supplies the conceptual model needed to interpret the result correctly. The remaining gap is what happens on an unresolved or invalid preset name, which matters for a lookup tool with two required identifiers.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is only 33%: the 'keys' parameter is documented in the schema but 'name' and 'kind' are bare, and the description mentions none of the three. The one piece of helpful scale information (a process preset has ~200 keys) already lives in the schema, so the description adds nothing about required inputs or how kind selects the preset namespace.

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?

States a specific verb and resource — flattening a preset's inherits chain — and adds the distinctive outcome that each value is attributed to its source level. This clearly separates it from siblings like bambu_list_presets or bambu_compare_presets, which do not resolve inheritance.

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?

Gives an explicit trigger: 'Use this whenever you need an actual setting value,' backed by the reasoning that leaf presets declare only a few dozen keys. It stops short of naming alternatives such as bambu_describe_parameters or bambu_list_presets as the thing to use when you don't need resolved values.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server