miromiro

Extract fonts

extract_fonts

Read-onlyIdempotent

Use when the user asks which fonts a site uses or wants to match its typography: every @font-face file with family/weight/style/format, Google Fonts links and preloads, grouped per family in families (pass fields='families' for just that). On a type-foundry site the families served are demo cuts (subset, features stripped), flagged demo:true with a note - pass that on, they are not the usable typeface. Not for: colors (use extract_brand) or code (use extract_code). Lists trim to 50; pass limit (up to 200) for more.

Input Schema

Name	Required	Description
`url`	Yes	The website URL
`fresh`	No	Skip the 24-hour cache and re-extract the live page - use when the site just changed and a cached result would be stale. Charged normally; the fresh result replaces the cached copy.
`limit`	No	Max entries per list (default 50, up to 200).
`fields`	No	Optional comma-separated fields to return (e.g. 'families')
`render`	No	Force a real browser so the page's JavaScript runs before it is read. Slower, and adds 5 credits. Usually not needed: when the plain read comes back as a JavaScript app shell or the site refuses it (401/403/406) or timed out, the server already re-runs the page in a browser by itself at no extra cost, and usage.autoRender says so. Pass it for images, videos or Lottie that only load on scroll, with screenshot=true, or when a result is still thin after that automatic pass. If a 403 says the browser was refused too, the site cannot be extracted - do not retry. extract_code always runs in a real browser at no extra cost, so render=true is not needed there (only together with screenshot=true). On extract_design_tokens, render=true only permits the browser: the plain read still runs first, and the 5 credits are charged only if the browser was actually needed.
`screenshot`	No	Requires render=true. Adds a screenshot field to the result: a public URL of a capture of the page (live 7 days), taken by the same browser that rendered it. Pass true for the 1440x900 viewport or 'full' for the entire page height. No extra credits beyond the render surcharge. Useful for showing the user what the extracted site looks like.
`full_output`	No	Skip long-string trimming. Responses still cap at ~100KB total.
`response_format`	No	How much to return. 'concise' keeps lists to 10 entries and strings short - right for a summary or a chat answer. 'detailed' returns everything the tool has (same as limit=200 + full_output=true). Omit for the default, which fits a typical chat context. The generated code is never trimmed in any mode.

Output Schema

Name	Required	Description
`url`	Yes
`note`	No	Only present when demo/trial families were found - tell the user, these files are subset and feature-stripped, not the usable typeface
`count`	No
`fonts`	No	Every font file / stylesheet found
`usage`	No	Credit usage for the authed key (spent, remaining, monthly limit).
`families`	No	Grouped per-family summary - what most callers want
`truncation_note`	No	Present when the result was trimmed to fit chat context - says what was dropped and how to get more (limit / full_output arguments, or the REST API).
`googleFontsLinks`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedOct 18, 2026

TDQS

A4.6/5.0

Behavior4/5

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

The annotations already declare this is a read-only, idempotent, open-world operation, so the safety bar is low. The description contributes genuinely non-obvious domain behavior: on type-foundry sites the served families are demo cuts with stripped features, flagged demo:true, and the agent is told to pass that caveat on. Default trimming behavior is also disclosed, though caching/auto-render behavior is only in the schema.

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 use case, then payload, then the demo caveat, then exclusions — the ordering matches how an agent needs the information. It is dense with semicolons and clauses, but every clause carries a distinct instruction rather than padding.

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?

With an output schema present, return shape need not be spelled out, and 8 parameters are fully covered by schema descriptions plus targeted guidance in the description. Accuracy-critical edge cases (demo fonts, list trimming, wrong-tool boundaries) are all addressed, so an agent has everything needed to call and interpret this correctly.

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 description coverage is 100%, so the baseline is 3; the description earns above that by telling the agent why and when to use fields='families' and limit rather than merely restating their types. The caveat that the 50-entry trim is a default rather than a hard cap is the kind of semantic detail the schema alone would bury.

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 verb and resource and enumerates exactly what is returned: every @font-face file with family/weight/style/format, Google Fonts links and preloads, grouped per family. It also explicitly disambiguates from siblings ('Not for: colors (use extract_brand) or code (use extract_code)'), so an agent can pick it without opening a schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Opens with the triggering user intent ('Use when the user asks which fonts a site uses or wants to match its typography') and names the two alternatives to use instead for adjacent asks. It goes further with narrower routing: pass fields='families' for just the grouped output, and pass limit up to 200 when the 50-entry trim cuts results.

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

All miromiro tools Inspect

Try in Browser

Claude Code, inside the Godot 4 editorFlockbay puts an AI agent in the real Godot 4 editor: it writes GDScript, runs your game and fixes what breaks. Free, or bring your own Claude Code or Codex.flockbay.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.