Font Design MCP

by Kydaix

Overview Schema Source Related Servers Score Discussions Admin

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation5/5
Each tool has a clear, distinct purpose across project lifecycle, glyph editing, spacing, rendering, validation/build, and history. No two tools overlap ambiguously.
Naming Consistency4/5
Most tools follow a resource_action pattern (project_create, glyph_get, history_list), but render_glyph and render_text use action_resource, creating a minor inconsistency.
Tool Count5/5
13 tools is well-scoped for a font design server, covering projects, glyphs, spacing, rendering, building, validation, and history without bloat.
Completeness4/5
Core workflows are covered, including project lifecycle, glyph editing, spacing, validation, build, and history. However, explicit glyph create/delete and project delete operations are absent, leaving minor lifecycle gaps.
Average 3.4/5 across 13 of 13 tools scored. Lowest: 2.2/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 1 commit in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior1/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description does not disclose side effects, permissions, authentication requirements, or potential limitations. Annotations indicate readOnlyHint false but provide no additional context, leaving behavioral impact unclear.
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?
The description is extremely concise, consisting of two sentences with no redundant or extraneous content. It efficiently communicates the primary action and an optional feature.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness1/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (8 parameters, output schema, optional comparison logic), the description is far too minimal. It omits critical details about parameter semantics, output format, revision handling, and error behavior (e.g., 'missing Unicode is reported'). The description does not adequately prepare an agent to use the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 8 parameters with zero description coverage. The text vaguely references 'revision' and 'compare_revision' but does not explain the meaning or expected values of parameters like width, dark, kern, sizes, or project_id. No parameter-level detail is provided.
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 clearly states the tool compiles a revision, shapes with HarfBuzz, and returns monochrome FreeType PNGs, also mentioning an optional comparison feature. It is specific enough to understand the core function, though it does not explicitly differentiate from sibling tools such as render_glyph.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines1/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided on when to use this tool versus alternatives like render_glyph or font_build. The mention of 'optional same-conditions revision comparison' describes a feature, not a usage context or decision criterion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false, so the description must carry behavioral transparency. It mentions 'Persist' implying a side effect, but does not explain what persists or whether it modifies state. It lacks details on side effects, idempotency, or error behavior.
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?
The description is brief and front-loaded with the primary action. It avoids excessive detail, though the word 'Persist' adds mild ambiguity without much benefit.
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 eight parameters and no schema descriptions, the description leaves too much unspecified. It does not mention output format specifics, parameter constraints, or any context about revisions and comparison, making it incomplete for reliable invocation.
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% and the description only vaguely references 'UFO revision', 'guides/handles', and 'comparison'. It fails to map parameters like width, height, guides, points, revision, and compare_revision to their meanings or relationships.
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 clearly identifies the resource (glyph) and the action (render and return PNG content), and it distinguishes from text rendering by referencing a 'UFO revision'. The phrase 'Persist and return' is somewhat ambiguous about whether it saves or simply produces, but the core purpose is clear.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit guidance on when to use this tool versus alternatives like render_text or glyph_get. It mentions 'Comparison uses the same frame' which hints at compare_revision, but does not clarify scenarios or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses key behavioral details: operations are applied atomically, and adjusting bearings can move outlines while advances do not. However, it does not mention revision checks, validation failures, or other side effects like potential destructive changes.
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?
The description is concise and well-structured, using two short sentences to convey core purpose and a key behavioral nuance without unnecessary detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description names the supported operation types and a key side effect, which is helpful. However, it lacks guidance on parameter usage and expected revision handling, making it only partially complete for a tool with a complex operations union.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The description provides no explanation of the parameters, including project_id, expected_revision, operations, or the operation discriminators. With 0% schema description coverage, the description leaves all parameter semantics to the 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?
The description clearly states the tool's purpose: atomically setting advances, side bearings, kerning groups, or pairs. It names the specific spacing resources and adds a useful distinction between bearings and advances.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not explain when to use this tool versus alternatives like glyph_edit or font_update, and it does not mention concurrency controls such as expected_revision. The atomicity hint is useful but not sufficient as usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Discloses that it reports errors, warnings, and observations, but does not clarify side effects such as whether a compiled TTF artifact is persisted; annotations are all false and add no clarity.
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?
Two concise sentences with no redundant phrasing; the structure is clear and easy to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema is present so return values need not be described, but the lack of parameter semantics and explicit usage guidance leaves the tool partially under-specified.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
No parameter descriptions are provided; corpus and revision semantics are unexplained, and the schema has 0% description coverage.
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 action ('Run technical checks, compile a TTF, inspect tables and corpus coverage') and clearly distinguishes the tool by noting it does not assess artistic merit.
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?
Implies a validation-focused use case and explicitly excludes artistic assessment, but does not clearly indicate when to use this over sibling tools like font_build or project_inspect.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds useful behavioral context by stating it does not alter UFO sources and returns persistent paths/hashes. Does not contradict the annotations, though it could mention whether existing build artifacts are overwritten.
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?
Three concise sentences with no fluff; each sentence adds relevant information about behavior, output, and side effects.
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?
Provides output and side-effect context but lacks essential parameter explanations and prerequisites such as requiring an existing project or how revision null is interpreted.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has three parameters with zero descriptions, and the description does not explain project_id, formats, or revision. 'From a frozen revision' only vaguely hints at the revision parameter.
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?
Clearly states the tool builds TTF/WOFF2 binaries from a frozen revision and returns persistent paths/hashes. This distinguishes it from sibling tools like font_validate and render_glyph.
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?
Implies use when compiled font binaries are needed from a frozen revision, but does not explicitly compare with sibling tools or state 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.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description explicitly states the create action, which is consistent with the annotation readOnlyHint=false. It adds context about the workspace and initial content, but does not disclose potential side effects such as overwriting or behavior on name conflicts. Since annotations already cover mutability, the added context earns a slightly above baseline score.
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?
The description is a single, concise sentence that starts with the action verb and includes essential context. There is no redundant or extraneous information, making it well-structured and efficient.
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?
While the description provides some context about the workspace and initial content, it does not explain the meaning of the required 'metadata' field or the optional 'metrics' and 'brief'. Given the schema's complexity and the creation context, the description is insufficient for an agent to fully understand what information to provide.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema description coverage is 0%, and the description provides no information about the parameters 'brief', 'metrics', or 'metadata'. Since the schema is not self-explanatory for these parameters and the description completely omits them, it fails to compensate for the lack of schema-level descriptions.
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 clearly states the verb 'Create' and the resource 'project', while specifying the workspace and initial content ('Unicode UFO sources and technical glyphs'). This distinguishes it from sibling tools like project_open and project_update.
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 implies usage for project creation but does not explicitly explain when to use this tool versus alternatives. There is no mention of exclusions or specific scenarios, leaving the usage guidance to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond annotations (readOnlyHint false, destructiveHint false), the description adds that it creates a new revision and preserves history, clarifying the additive nature. It also implies a concurrency check via expected_revision. However, it does not mention failure modes or side effects on the current working revision.
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?
The description is a single, concise sentence with no irrelevant information. It efficiently covers the core action, key requirements, and a critical behavioral guarantee (preserves history).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
While the purpose is clear and the output schema is present (so return values are not needed), the description lacks details on when to use the tool, what happens to the current state, and potential error conditions. The requirement of expected_revision is a critical precondition, but other context is sparse.
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?
The schema has zero description coverage for parameters. The description mentions 'expected_revision' but does not explain 'target_revision', 'project_id', or 'summary'. It fails to map each parameter to its role, leaving the agent to infer that 'target_revision' is the revision to restore and 'summary' is likely a commit message.
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 clearly states the tool's purpose: restoring a committed revision by creating a new revision. It distinguishes itself from siblings by emphasizing the non-destructive, additive nature (preserves history) and the requirement for expected_revision, making the action unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides a precondition (requires expected_revision) but offers no guidance on when to use this tool versus alternatives like history_list or project_update. It lacks contextual cues for selecting this tool over others.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations are all false (readOnlyHint=false, destructiveHint=false), so the description carries the behavioral burden. It adds three genuinely useful traits: atomicity of the update, the optimistic-concurrency requirement (expected_revision), and a specific failure mode (UPM changes on nonempty fonts fail). This goes well beyond the bare annotations without contradicting them.
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?
Two tight sentences: the first front-loads purpose and atomicity, the second adds the revision requirement and a failure caveat. No filler, though 'nonempty fonts' is slightly cryptic without definition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
An output schema covers return values, and the description addresses the key gotchas (revision, UPM failure). But it leaves gaps: how to obtain expected_revision, what happens on mismatch, and whether multiple sub-resources can be updated in one call (atomicity hints yes but is unstated). Adequate but not comprehensive for a 7-parameter mutator.
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?
With 0% schema description coverage, the description must compensate for the 7 parameters. It covers expected_revision, metadata, brief, decision, and UPM (units_per_em) conceptually, but it omits summary, project_id, and any detail about the nested Metrics/Decision/Metadata structures. Partial compensation, not full.
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 uses a specific verb ('update') with a clear resource ('metadata, brief or decision journal'), which distinguishes it from siblings like project_create and project_inspect. It doesn't explicitly name a differentiating sibling, but the scoping to project-level sub-resources makes the purpose unambiguous and non-tautological.
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 implies usage context through 'Requires expected_revision,' which signals a concurrency-control workflow (obtain revision, then update), and the UPM caveat warns against a failure condition. However, it never explicitly states when to prefer this over project_create/project_inspect or what to do when the revision mismatches — the workflow is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false. The description adds useful context about the stability of IDs and the coordinate system (Y upwards), which goes beyond annotations. No contradiction exists.
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?
The description is a single sentence that front-loads the action and lists the data items. It is concise, with every element contributing meaning.
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?
The description covers what is read and the coordinate system, and the output schema presumably details the return structure. It omits explanation of the optional revision parameter and error behavior, but these are minor gaps given the annotations and output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters1/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain any of the parameters (project_id, glyph_id, revision). The agent must infer meaning solely from names, which is inadequate given the lack of schema descriptions.
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 uses a specific verb 'Read' and enumerates the exact data elements (contour/point/component/anchor IDs, advance, bounds, bearings) and clarifies the coordinate system (Y upwards). This clearly distinguishes it from siblings like glyph_edit and render_glyph.
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 implies usage for reading glyph data but does not explicitly state when to use it vs alternatives such as glyph_edit or render_glyph. There are no conditions, exclusions, or alternative tool references.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing safety and idempotency. The description adds behavioral context by mentioning that it verifies committed sources and returns a revision, which are useful traits beyond the annotation coverage. No contradiction with annotations.
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?
The description is a single sentence that front-loads the primary action and resource, with no redundant words. Every clause adds information, making it highly efficient.
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 simple tool with one parameter and an existing output schema, the description covers the essential purpose and key behaviors. It does not need to explain return values since the output schema handles that. However, it could have provided a brief note on when to use it relative to siblings, but overall it is sufficiently complete for a low-complexity operation.
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?
With schema description coverage at 0%, the description should compensate for missing parameter details. The only parameter, project_id, is mentioned generically as 'by ID' but not elaborated on (format, pattern, constraints). The schema provides the pattern, but the description adds no semantic value beyond what is already inferable from the 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?
The description clearly states the action ('Reopen'), the resource ('server-created project'), the method (by ID), and additional details (verifies committed sources, returns revision). It distinguishes itself from siblings like project_create and project_inspect by specifying the reopen operation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description does not provide any guidance on when to use this tool versus alternatives. It implies usage for reopening an existing project but does not mention conditions, exclusions, or alternative tools, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description discloses atomicity, that offcurve points are handles, that replacements must be explicit, and that removed IDs are returned. These details go beyond the annotations (which only indicate read-only and destructive hints) and give an agent useful behavioral context about how the tool operates.
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?
The description is three short sentences with no redundant phrasing. It front-loads the core action and includes only essential behavioral notes, making it highly efficient for an agent to parse.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness3/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is complex with many operation types, yet the description omits critical context such as the need for expected_revision for optimistic concurrency, the meaning of 'typed' operations, and error scenarios. It does mention removal returns, and the output schema exists, but overall the description leaves gaps for such a complex tool.
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?
With 0% schema description coverage, the description should compensate, but it only offers a few hints (explicit replacements, removed IDs) that relate to a subset of operations. It does not explain required parameters like project_id, expected_revision, or the operations structure, leaving most parameters semantically opaque.
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 clearly states the action ('Apply an atomic typed vector batch') and the resource ('a named glyph'), and it implies modification, distinguishing it from read-only tools like glyph_get. The mention of 'removed IDs' and 'replacements' further clarifies it as an editing operation.
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 implies that this tool is used for editing glyphs, but it does not explicitly state when to use it versus siblings like glyph_get or spacing_edit, nor does it mention any prerequisites such as an open project. It provides no exclusionary guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description states an inspection action, and annotations confirm read-only, idempotent, non-destructive behavior. No contradictions. It could further note that no modifications will occur, but annotations already cover the main safety profile.
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?
The description is a single, concise, front-loaded sentence with no redundant or extraneous content.
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?
The description covers the main purpose and parameter implications, and an output schema is present, so return values need not be described. It lacks explicit note on null revision semantics, but the context is otherwise adequate.
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?
The description partially explains parameters: 'specified revision' clarifies revision, and 'paginated glyph inventory' implies limit/offset. However, project_id is not explained, and there are no schema-level descriptions. The meaning of a null revision is also left implicit.
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 clearly states the action ('Inspect') and the resource/scope: revision, metadata, metrics, kerning, and paginated glyph inventory. This is specific enough to distinguish it from similar project and glyph tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines2/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no explicit guidance on when to use this tool versus alternatives such as project_open, glyph_get, or history_list. Usage must be inferred from the tool name and read-only annotations.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already mark the tool as read-only, idempotent, and non-destructive. The description adds useful context by specifying only committed revisions are listed and uncommitted stages are excluded, reinforcing the safe read-only behavior.
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?
The description is concise, well-structured, and front-loaded with the primary action. It avoids redundancy and communicates the key exclusions in a single sentence.
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?
The description is complete enough for a simple listing operation, especially with an output schema present. It conveys scope and exclusions, though it leaves parameter details unspecified, which is a minor gap.
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?
The schema has no parameter descriptions and the tool description only mentions pagination generically. It does not explain the meaning of project_id, limit, offset, or revision, leaving agents to infer their roles.
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 clearly states the tool lists committed revisions and summaries with pagination, and explicitly excludes interrupted uncommitted stages. This distinguishes it from related history operations.
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?
It communicates when to use the tool — for committed revision history — and what is excluded. It does not explicitly name alternative tools like history_restore, but the scope is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Font Design MCP MCP server – quality and maintenance score on Glama

Copy to your README.md:

[![Font Design MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Kydaix/Font-Design-MCP/badges/card.svg)](https://glama.ai/mcp/servers/Kydaix/Font-Design-MCP)

Score Badge

Copy to your README.md:

[![Font Design MCP MCP server – quality and maintenance score on Glama](https://glama.ai/mcp/servers/Kydaix/Font-Design-MCP/badges/score.svg)](https://glama.ai/mcp/servers/Kydaix/Font-Design-MCP)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/Kydaix/Font-Design-MCP'

If you have feedback or need assistance with the MCP directory API, please join our Discord server