MakersMCP

Overview Schema Source Related Servers Discussions Admin

Fonts of a website

make_font_kit

Extract a website’s fonts in a headless browser and save them in one folder with usage roles, license details, free alternatives, and ready-to-use FONTS.md, fonts.css, and fonts.json files.

Instructions

Reads a website in a headless browser and saves its fonts in one folder: which font draws its headings, body text, buttons and code, every font file the page loads, how each one is licensed, and the closest free font for each one that is not free. FONTS.md is for people and agents, fonts.css for pages, fonts.json for tools. The license of each font is written next to it so the user can decide what to use. (easyfontkit 0.1.2, on this machine.)

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "url": "<url>"
    },
    "name": "make_font_kit"
  }
}

Input Schema

Name	Required	Description
`url`	Yes	The website, like https://linear.app
`files`	No	Set to false to read the font files without saving them.
`out_dir`	No	Folder to save into, absolute or relative to /app. Default: easyfontkit-{host}.
`wait_seconds`	No	How long to wait for the result before returning a job_id to wait on. 45 is safe for clients that stop a tool call after 60 seconds.
`timeout_seconds`	No	Give up after this many seconds (default 120).

Output Schema

Name	Required	Description
`kit`	Yes
`tool`	Yes
`files`	No
`folder`	No	Where the kit saved its files.
`job_id`	Yes
`passed`	No	For checks: whether the check passed.
`status`	Yes
`exit_code`	No
`last_line`	No	What the kit was doing last.
`expires_at`	No	When the download links stop working.
`next_action`	No
`elapsed_seconds`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 7, 2026

TDQS

A3.7/5.0

Behavior3/5

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

The annotations already declare readOnlyHint=false, idempotentHint=false and openWorldHint=true, and the description is consistent with them by disclosing that a headless browser is driven and files are written to disk. It adds useful context (license captured next to each font so the user can decide what to use, non-free fonts mapped to a free substitute), but it omits the asynchronous job model entirely: the schema's wait_seconds/job_id path and the wait_for_job sibling imply long-running, resumable jobs, which is a meaningful behavioral trait left undisclosed.

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?

Front-loaded with the core action and artifact in the first clause, then the contents, then a per-consumer file guide. The trailing parenthetical version string ("easyfontkit 0.1.2, on this machine") is the only sentence that doesn't earn much space.

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?

An output schema exists, so return values need not be described, and the description covers the substantive behavior a caller needs: what is fetched, what is saved, where, and what the license data enables. The one real gap relative to this tool's complexity is the long-running job / wait_for_job handoff, which is only discoverable from the schema.

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 description coverage is 100%, so the baseline is 3. The description reinforces the default output-folder behavior and the purpose of the artifacts, but adds nothing about the non-obvious parameters such as files=false or the wait/timeout interaction.

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?

"Reads a website in a headless browser and saves its fonts in one folder" gives a specific verb, a specific resource, and the produced artifact. It then enumerates exactly what lands in that folder (per-role fonts, font files, license status, free replacements), which is enough to distinguish it from siblings like make_brand_kit or take_screenshots without opening the schema.

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 the use case (you want a site's typeface stack and licensing) and explains which of the three output files each audience should consume, but it never says when to choose this over a sibling tool or when not to use it. No prerequisites, exclusions, or alternative routing are given.

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

Deploy Server