Skip to main content
Glama
Sign In
Fatia MCP

Fatia MCP

by anthonydaros
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

check_filament_availability

Compare a sliced 3MF project's per-slot filament consumption against your declared remaining grams to check if stock suffices, accounting for copies and a safety margin.

Instructions

Compare sliced-project per-slot consumption against caller-supplied remaining filament grams. Read-only, no printer or stock service connection. Copies multiply the entire project. Sufficiency is an estimate; metadata may omit purge and tower waste. Missing slots or plate consumption remain unknown.

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": {
      "path": "<path>",
      "filaments": "<filaments>"
    },
    "name": "check_filament_availability"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathYesSliced 3MF with per-filament consumption metadata.
copiesNoNumber of copies of the entire project.
filamentsYesUser-declared stock assignment; each slot must refer to a separate supply, not the same spool counted twice.
safety_margin_percentNoReserve added to recorded consumption; it cannot guarantee coverage of unrecorded waste.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv1.1.47

TDQS

A4.3/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it declares read-only behavior, no printer or stock service connection, that copies multiply the entire project, and that results are estimates because metadata may omit purge and tower waste. It also discloses the unknown cases — missing slots or plate consumption — which is exactly the caveat an agent needs before reporting sufficiency.

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?

Five short sentences, front-loaded with the core comparison, and nothing is redundant. The telegraphic fragments ('Copies multiply the entire project.') are dense but slightly clipped, which costs a little readability without wasting space.

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 four-parameter analysis tool with no output schema, the description covers inputs, offline behavior, and the estimation caveats well. What it does not describe is the return shape or how per-slot shortfalls are reported, which matters somewhat given no output schema exists.

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

Parameters4/5

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

Schema coverage is 100%, so baseline is 3, but the description adds real meaning beyond it: 'copies multiply the entire project' clarifies the scope of the copies parameter, and the sufficiency-estimate sentence frames how safety_margin_percent should be trusted. The filaments semantics are mostly left to the schema's own stock-assignment note.

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: compare sliced-project per-slot consumption against caller-supplied remaining grams. That is clearly distinct from siblings like analyze_print_waste, estimate_print_cost, and preflight_check, and an agent can pick it without opening the schema.

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 rather than stated: the caller must already know stock grams and pass them in, and the tool works offline with no printer connection. However, it never names an alternative (e.g., analyze_print_waste) or explicitly says when to prefer this over those siblings, so selection relies on inference.

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