Skip to main content
Glama
SlicerBridge

SlicerBridge

verify_files

Read-onlyIdempotent

Re-run validation checks on SlicerBridge-generated 3MF files for colors, paint, plates, size, and settings; optionally slice each file to confirm output.

Instructions

Re-run SlicerBridge's checks on files it wrote (colors, paint, plates, size, settings), and optionally slice each one.

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": {
      "paths": "<paths>"
    },
    "name": "verify_files"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsYes.3mf files, or folders of them.
slice_filesNoAlso slice each file in its slicer (a minute or two each).
source_pathNoThe project they were made from; enables the color and size checks.

Output Schema

NameRequiredDescriptionDefault
resultYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive, closed-world behavior, and the description adds genuinely new context: the specific checks performed, that slicing is opt-in, and its cost ('a minute or two each'). One mild tension exists: slicing produces output files, which sits awkwardly with readOnlyHint=true, though the description does flag it as optional and explicitly time-consuming rather than free. It does not say what happens when a check fails (error vs. report).

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?

A single front-loaded sentence with the core action first and the optional behavior trailed after 'optionally'. The parenthetical check list is dense but each item carries information; nothing is redundant.

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?

With an output schema present, return values need not be explained, and annotations cover the safety profile. The description covers what is checked, the slicing opt-in and its cost, and the source_path dependency, which is enough for correct invocation. Failure semantics (what a failed check looks like) remain 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?

Schema coverage is 100% and all three parameters are documented in the schema, including accepted path types and the source_path precondition for color/size checks. The description only reinforces the check list and slicing option, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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 description uses a specific verb+resource: 're-run SlicerBridge's checks on files it wrote', and enumerates the check domains (colors, paint, plates, size, settings) plus the optional slicing step. An agent can tell this is a verification pass over previously generated artifacts. It stops short of naming how it differs from siblings like inspect_model or brand_check, which likely also examine model files.

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?

'Files it wrote' implies the precondition (this runs on SlicerBridge output, not arbitrary inputs), which is real usage guidance. However, there is no explicit when-not and no comparison to the nearest siblings (inspect_model, brand_check, doctor), so the agent must infer the routing decision itself.

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