Skip to main content
Glama
conversor3mf

conversor3mf

ajustar_purga

Calibrates color-swap purge for ACE slots or hex colors and saves the adjustment for future 3MF conversions, correcting smeared or insufficient color transitions.

Instructions

Calibra a purga de uma troca de cor e guarda para as próximas conversões.

de/para: número do slot do ACE ("2") ou cor (#RRGGBB). de = cor que estava no bico, para = cor que entra (a que saiu manchada). mudanca: "mais" (+20%), "menos" (-20%) ou um fator (ex.: "1.5"). Para valer num arquivo já convertido, chame aplicar_purga depois.

Input Schema

NameRequiredDescriptionDefault
deYes
paraYes
mudancaNomais

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.3.0

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description carries the burden and does disclose the key trait: it stores calibration persistently ("guarda para as próximas conversões") and requires aplicar_purga to affect an existing file. It does not describe return values, whether the calibration is reversible, or any permission constraints.

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?

Front-loads the purpose, then parameter semantics, then the follow-up caveat. Sentences are dense and useful; minor slack in the parenthetical color clarification but nothing wasted.

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 3-param mutation tool with no annotations and no output schema, the description covers purpose, all parameter meanings, and the critical apply-after caveat. Only missing pieces are the response/return behavior and failure modes.

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

Parameters5/5

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

Schema description coverage is 0%, so the description must fully compensate and does: it explains de accepts an ACE slot number ("2") or hex color (#RRGGBB), defines para as the incoming/blotched color, and specifies mudanca values ("mais" +20%, "menos" -20%, or a factor like "1.5"). This adds substantial meaning beyond the bare schema.

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 ("Calibra a purga de uma troca de cor") and adds persistence semantics ("guarda para as próximas conversões"). It also names the sibling aplicar_purga as the follow-up step, so an agent can distinguish it from ver_purga/nivel_purga/ajustar_purga without opening schemas.

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?

Explicitly routes the agent: "Para valer num arquivo já convertido, chame aplicar_purga depois," which clarifies this tool only calibrates/stores, not applies. It gives clear usage context but no explicit when-not condition or full comparison against ver_purga/nivel_purga.

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