Skip to main content
Glama

ass_glyph_check

Detect missing glyphs for subtitle text or a style's font. Checks a line or custom text against a font family and lists characters the font cannot render.

Instructions

Missing glyphs for a line's text or for a style's font.

The string checked is text when given, otherwise the plain text of line index (override tags removed). The font comes from family when given, otherwise from the style named by style (its Fontname, Bold and Italic) -- when neither is given the style of the line is used, and failing that the system default sans.

Returns {source, doc_id, index, style, requested, resolved_family, substituted, bold, italic, text, missing: [{char, codepoint, codepoint_hex, fallbacks}], missing_count, missing_chars, missing_codepoints, checked, covered, coverage_source}.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
textNo
indexNo
styleNo
doc_idNo
familyNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.7/5.0
Behavior4/5

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

With no annotations provided, the description carries full burden and does a good job: it explains that override tags are removed, how the font is resolved through fallbacks, and what the output contains. It stops short of explicitly stating that the operation is read-only or has no side effects, which keeps it from a 5.

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

Conciseness3/5

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

The description is front-loaded with a clear purpose sentence and well-structured input logic. However, it includes a long return-value specification even though an output schema exists, which makes it less concise than it could be.

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?

Given the tool's complexity, zero annotation coverage, and an output schema, the description is mostly complete: it covers input resolution, fallback behavior, and output fields. It misses doc_id semantics and any explicit read-only assurance, which are minor gaps for a check tool.

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 0%, so the description must compensate, and it does for four of five parameters: it defines when text vs. index is used, and when family vs. style is used, including fallback to line style then system default. The doc_id parameter is not explained at all, leaving one gap.

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 states a specific check: 'Missing glyphs for a line's text or for a style's font.' It clearly identifies the resource (glyphs in text/font) and the action (checking for missing ones). It does not explicitly differentiate from siblings like ass_font_coverage or ass_check_font_substitution, so it falls short of a 5.

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 description explains the input resolution (text vs. index, family vs. style) but never states when to use this tool versus alternatives such as ass_font_coverage or ass_check_font_substitution. Usage is implied by the parameter logic rather than made explicit.

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