proofcut

Overview Schema Source Related Servers Discussions Admin

fonts

DestructiveIdempotent

Check if a caption font truly renders on this machine: compare fontconfig's presence report against a pixel render test, and optionally install the vendored face or test a project's caption style.

Instructions

Will the caption font actually draw on this machine?

Reports two answers side by side and does not merge them: fontconfig says whether the family is present, render burns the family and an impossible family and compares the pixels. Identical pixels mean the name is substituting whatever fontconfig claims — the only way to settle which face drew is to measure a render.

path is optional: with a project, this checks the font that project's caption style would burn; without one, proofcut's default. install copies the vendored face where this OS's font system looks (fontconfig, CoreText or DirectWrite) and is off by default, because it writes into the home directory.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`path`	No	A project directory, or nothing. Omitting it means no project here — never the bound one — and reports proofcut's own default caption face; with a project, it reports the face that project's caption style would burn.
`install`	No	Copy the vendored face where this OS's font system looks (fontconfig, CoreText or DirectWrite). Off by default, because it writes into the home directory.

Output Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed7 schema fields changedv0.25.0Sep 16, 2026

addedInput schema / properties / install / description

Added value: +"Copy the vendored face where this OS's font system looks (fontconfig, CoreText or DirectWrite). Off by default, because it writes into the home directory."

removedInput schema / properties / install / title
```
Removed value: -"Install"
```

removedInput schema / properties / path / anyOf

Removed value: -[
-  {
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]

addedInput schema / properties / path / description

Added value: +"A project directory, or nothing. Omitting it means *no project* here — never the bound one — and reports proofcut's own default caption face; with a project, it reports the face that project's caption style would burn."

removedInput schema / properties / path / title
```
Removed value: -"Path"
```

addedInput schema / properties / path / type

Added value: +[
+  "string",
+  "null"
+]

removedInput schema / title
```
Removed value: -"fontsArguments"
```

First observedv0.24.0Sep 15, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the annotations, the description discloses important behavioral traits: the tool reports two answers side by side without merging them, uses an impossible-family render comparison to detect substitution, and has an install flag that writes into the home directory. This adds real context about side effects and output semantics that annotations alone do not provide.

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

Conciseness5/5

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

Despite its length, every sentence earns its place: the opening question sets intent, the next two explain the core mechanism and non-merging behavior, and the final paragraph covers the two parameters. The structure front-loads the most important behavioral facts.

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

Completeness5/5

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

The description fully covers what the tool does, how it does it, the optional behaviors, and the side-effect risk of install. The output schema is present, so return-value details do not need to be spelled out. Nothing an agent needs to correctly select and invoke this tool is missing.

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

Parameters3/5

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

Schema coverage is 100%, so the baseline is 3. The description restates the path and install semantics already present in the schema and adds some rationale about why the impossible-family comparison matters, but it does not meaningfully extend the schema's parameter documentation.

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?

The description opens with a concrete diagnostic question and then specifies exactly what the tool reports: fontconfig presence versus an actual render comparison. It clearly identifies the resource (caption font, default or project-specific) and the unique two-answer behavior that distinguishes it from sibling tools.

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?

The description gives clear context for when to use the tool: when you need to know whether a caption font will actually draw on this machine, rather than just whether the family is present. It explains the path semantics and the default behavior, though it does not explicitly name alternatives or say when not to use it.

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

Deploy Server