build_type_scale

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

With no annotations provided, the description carries the full burden, and it delivers key behavioral details: values are generated as clamp() functions, they interpolate continuously with viewport size rather than stepping at breakpoints, and the narrow end deliberately uses a gentler ratio for readability. It does not state whether the tool writes files or returns raw code, but for a build/generation tool the output is reasonably characterized as 'clamp() values.'

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?

Two tightly written sentences deliver the core purpose, output format, behavioral model, and a design rationale without any filler. The most critical information — what is built and in what form — is front-loaded.

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?

For a six-parameter tool with no output schema, the description gives enough to invoke it correctly: it names the output form (clamp() values) and explains the scaling behavior. It stops short of describing the exact return structure (e.g., custom properties vs. raw strings), which is a minor gap, but an agent can safely call it with defaults and understand what it will produce.

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?

The input schema covers all six parameters and their defaults, so the description does not need to repeat parameter mechanics. It does add useful context by explaining why the ratio behaves gently at the narrow end and why the scale is viewport-interpolated, but it does not enrich understanding of specific parameters like base_rem or steps_up beyond 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 a specific verb and resource: 'Build a fluid modular type scale as clamp() values.' It further clarifies the output and behavior ('interpolate with the viewport instead of stepping at breakpoints'), distinguishing it from a static breakpoint-based type scale and from sibling tools like suggest_fonts or build_palette.

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 intended use case is implied through 'fluid modular type scale' and 'interpolate with the viewport' — an agent can infer this is for responsive typography. However, it never explicitly states when not to use it or names an alternative sibling, so the routing decision is left to inference rather than direct guidance.

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