get_font_css

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

Beyond the readOnlyHint annotation, the description discloses meaningful behavior: defaults to weight 400 normal, each extra weight/style adding about 1.5KB of CSS, and the variable package changing the font-family to '<Family> Variable'. The 'absolute URLs, safe to inline' note also clarifies the returned CSS is directly usable. Nothing contradicts the readOnly annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Is the description appropriately sized, front-loaded, and free of redundancy?

Four short sentences front-load the artifact list, then add defaults, size impact, and variable behavior in increasing order of specificity. Every sentence earns its place, with no filler or repetition of schema details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, so the description must communicate return content; the artifact enumeration and 'safe to inline' cover that well. Defaults and the variable-package caveat address the most consequential choices. It is slightly vague about the container format of the returned snippets, but the schema fully documents the parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the baseline is 3, but the description adds real value by explaining the weight/style default and the size tradeoff for extra combinations. It also clarifies what variable:true does to the font-family value. It does not discuss subsets or variableFile, but those are already documented in the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens with 'Font embedding snippets' and enumerates exact artifacts: CDN link tags, @import lines, npm install/import lines, the font-family rule, and @font-face CSS. This makes the tool's resource and output unmistakable and clearly distinguishes it from siblings like search_fonts, get_font, and download_font.

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

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

The 'embedding snippets' framing implies the use case, but the description never names sibling tools or states when to prefer get_font_css over get_font or download_font. There are no explicit exclusions or when-to-use/when-not-to-use instructions, so usage guidance is only implied.

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