Skip to main content
Glama

nucleo-fonts-import

Idempotent

Download a Google Fonts family and selected weights as local woff2 files for WordPress design tokens, replacing any existing import of that family.

Instructions

Downloads a Google Fonts family locally (woff2 in uploads) and makes it available to the tokens. Replaces the same family already imported. Network or format errors return ok false.

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": {
      "family": "<family>",
      "weights": "<weights>"
    },
    "name": "nucleo-fonts-import"
  }
}

Input Schema

NameRequiredDescriptionDefault
familyYesFamily name, for example "Inter".
italicNoDownloads the italic variants instead of the regular ones.
weightsYesWeights to download: multiples of 100 between 100 and 900, at most 9.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare mutation, idempotency and non-destructiveness, and the description adds real context beyond them: the downloaded artifact format and location (woff2 in uploads), the replace-existing-family semantic, and the error contract (ok false on network or format failures). It does not cover whether previously imported weights/variants are dropped on replacement, which is the main remaining ambiguity.

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 with zero redundancy, ordered from what it does to the replacement side effect to failure behavior. Every sentence earns its place.

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 mutating network-backed import with no output schema, the description supplies destination, side effect and failure signal, which is nearly everything an agent needs to call it. The gap is whether non-listed weights are removed by the replacement, and nothing is said about any required permissions or setup.

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 family, weights and italic are already fully documented including the multiple-of-100 and count limits. The description adds only indirect meaning for family via the replacement rule; the baseline 3 applies when the schema carries parameter detail.

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?

States a specific verb and resource: downloads a Google Fonts family locally as woff2 into uploads and exposes it to the tokens. That resource is inherently distinct from the media/site import siblings. It stops short of explicitly naming a sibling for contrast, which keeps it from a 5.

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 (bringing a Google Fonts family into the design system) and states a replace-on-reimport rule, but never says when to prefer it over alternatives or what prerequisites exist. Usage must be inferred from the purpose statement.

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