Skip to main content
Glama

Load Font

photopea_load_font
Idempotent

Load a custom TTF or OTF font from a URL into Photopea so it can be used for adding and editing text; find its PostScript name with list_fonts after loading.

Instructions

Load a custom font from a URL (TTF or OTF; Photopea cannot open WOFF2) into Photopea. The font becomes available for add_text and edit_text. Use list_fonts to find the PostScript name after loading.

Input Schema

NameRequiredDescriptionDefault
urlYesURL to a .ttf or .otf font file

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.2.1
    • changedInput schema / properties / url / description
      Previous value: -"URL to a font file (.ttf, .otf, or .woff2)"New value: +"URL to a .ttf or .otf font file"
  2. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

Beyond the annotations (openWorldHint=true, idempotentHint=true, destructiveHint=false), the description adds real value: the format restriction (TTF/OTF, not WOFF2) and the fact that the font is registered and usable by later text tools. It omits failure behavior for unreachable URLs and whether the font persists beyond the current document, but the added context is substantive.

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 short sentences, front-loaded with the action and format constraint, followed by the downstream effect and the follow-up call. No filler or repetition of the name/title.

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 one-parameter, no-output-schema tool, the description covers input format, effect, and next step. Minor gaps remain around error handling for bad URLs and font lifetime, but nothing essential to invoking it correctly is missing.

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 already 100% for the single url parameter, so the baseline is 3; the description earns an extra point by adding a format constraint (TTF/OTF; WOFF2 unsupported) that the schema does not encode.

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?

Specific verb plus resource: 'Load a custom font from a URL ... into Photopea.' It names the accepted formats and the immediate effect on the session, which cleanly separates it from sibling list_fonts and from add_text/edit_text.

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 states the workflow context: the font becomes available for add_text and edit_text, and list_fonts should be called afterwards to resolve the PostScript name. It does not state exclusions (e.g., fonts already installed, remote URL/CORS limits), so it stops short of full when/when-not guidance.

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