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

Annotations already cover the safety profile (readOnlyHint true, non-destructive, closed world), so the bar is lower. The description nonetheless adds real behavioral context: roughly 3,000 tokens of cost, verbatim asset-token substitution, the prohibition on pasting base64, and the publish-time scoring side effect. It stops short of describing the document's structure or whether the payload is chunked.

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?

Front-loaded with the imperative call to action, then cost, then the token mechanics. Dense but every sentence earns its place — the token/base64 guidance and the scoring rationale both change agent behavior. Slightly long, but not padded.

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 carries the burden of describing returns — and it does, listing the standard's components and the brand payload (colours, typefaces, asset tokens for logo and fonts). Nothing an agent needs in order to call it and use its output correctly is missing.

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. The description goes beyond the schema by tying `doc_name` to the downstream `brand_from` argument on host_html_content and by explaining the asset-token verbatim rule, which gives the agent a reason to preserve the exact doc name it reads from.

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?

States a specific verb and resource: it returns the docfarm house standard plus the user's brand (colours, typefaces, asset tokens). It is immediately distinguishable from siblings like app_read_doc or get_skills, and even enumerates the sub-topics inside the standard (archetype, type scale, spacing, logo rules, motion, budgets, language rules).

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?

Explicit when-to-use ('READ THIS FIRST, before writing a single line of HTML') plus a named downstream dependency: pass the same doc name as `brand_from` on host_html_content. It also explains why reading first matters (scoring on publish), which routes the agent correctly rather than by inference.

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