Skip to main content
Glama
conversor3mf

conversor3mf

aprender_purga

Learns the purge values Anycubic Slicer Next calculated from saved project folders or .3mf files so those settings can be reused.

Instructions

Aprende a purga que o Anycubic Slicer Next calculou em projetos salvos por ele (pastas ou .3mf).

Input Schema

NameRequiredDescriptionDefault
pastas_ou_arquivosYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden. It never says whether 'aprender' merely reads values or persists them into some configuration, whether existing learned values are overwritten, what permissions or file access are needed, or what comes back. For a mutation-ambiguous tool with zero annotation coverage this is a real gap.

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?

One front-loaded sentence with no filler; the source constraint is stated immediately after the verb. It is efficient, though brevity here partly reflects under-specification rather than tight editing.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and no annotations, the description would need to explain what 'learning' produces and where the result goes. It says nothing about the return value, error behavior for non-project paths, or persistence, leaving an agent unable to predict the outcome of the call.

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 coverage is 0% for the single required parameter 'pastas_ou_arquivos'. The description partly compensates by confirming it accepts both folders and .3mf files, but it omits whether recursion into subfolders happens, whether multiple paths are processed together, and what happens on a path that isn't a slicer project.

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?

States a specific verb ('aprende') and resource ('purga'), plus the source ('projetos salvos pelo Anycubic Slicer Next (pastas ou .3mf)'). That is enough for an agent to tell it reads purge data from existing project files rather than computing or applying purge, though it never names the sibling ver_purga or explains how it differs.

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?

The phrase 'em projetos salvos por ele' implies the precondition (files must come from Anycubic Slicer Next), but there is no explicit when-to-use, no exclusion, and no routing to ver_purga, ajustar_purga, nivel_purga or aplicar_purga, all of which sit adjacent. The agent must infer the choice from the sibling names alone.

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