font_manage

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It does describe core behaviors: create operations, 'optionally save to disk', derivation from a base font, and inspect-only behavior for get_font_info. However, it does not disclose editor-session side effects, persistence rules beyond save_path, overwrite behavior, error conditions, or what happens to resources not saved to disk.

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

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

The description is a scannable bullet list with no filler; each line presents an operation and its signature or a needed call-shape detail. The note about canonical call shape and flat-parameter compatibility is useful rather than redundant. The structure allows an agent to quickly locate the relevant operation.

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

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

Given the generic input schema and lack of annotations, the description supplies the essential operation catalog, parameter signatures, and invocation shape, and an output schema exists to document return values. The main gaps are the absence of tool-selection guidance against sibling tools and deeper behavioral caveats. An agent can still correctly select and invoke the documented operations, so this is above minimum viability but not fully complete.

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

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

Schema description coverage is 0% and the params object is generic free-form, so the description is the main source of parameter meaning. It provides full call signatures with defaults for every operation, conveying parameter names, optionality, and basic types. It stops short of explaining value domains such as weight ranges, variation_embolden scale, hex color format, or save_path behavior, so it is not a fully comprehensive reference.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with a clear domain statement and then enumerates four concrete operations, each with a specific verb and resource: 'Create a SystemFont resource', 'Create a FontVariation resource', 'Create a LabelSettings resource', and 'Inspect metadata and properties'. This makes it clear that font_manage handles font/label resource creation and inspection, distinguishing it from the many other *_manage sibling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Does the description explain when to use this tool, when not to, or what alternatives exist?

The title and operation list imply when the tool is relevant: creating or inspecting font and label styling resources. However, the description never explicitly tells the agent when to prefer font_manage over related tools like theme_manage, ui_manage, or resource_manage, and it gives no exclusions or alternative routing. This is clear implied usage, but not explicit guidance.

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