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

With no annotations, the description carries the full burden and does disclose real behavior: it writes a file at a fixed path, inlines CSS, enforces hard rules, launches a preview server and returns a browser URL. It does not say what happens when hard-rule validation fails, whether an existing preview.html is overwritten, or how the returned URL/port is determined, which keeps it short of a 5.

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 dense sentences, front-loaded with the action and artifact path, followed by the bundled side effects and the fallback rule. Every clause conveys something actionable; nothing is padding.

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 mutation tool with no annotations and no output schema, the description covers the essentials: what file is created, that validation runs, that a preview is started, and what is returned (the browser URL). It is only slightly incomplete on overwrite behavior and failure handling.

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 description coverage is 100%, so the schema already documents all four parameters (html requirements, slug format, title, from_example). The description's note that omitting html falls back to template scaffolding merely repeats the html parameter's schema text, adding no syntax or format detail beyond the structured fields. Baseline 3 applies.

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 (创建/create) and resource (out/<slug>/preview.html) with an exact output path, plus the side effects (inline CSS, hard-rule validation, preview launch). An agent can distinguish it from update_prototype, validate_prototype and start_preview because the description names the file it produces and the bundled steps it performs.

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?

Usage is implied by the create semantics and the file path, and the fallback rule ('html 省略时用模板脚手架') tells the agent when to omit html. However, there is no explicit statement of when to prefer this over update_prototype, validate_prototype or start_preview, nor any exclusion or prerequisite.

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

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

With no annotations, the description carries the burden and does disclose the key traits: it is a write operation producing inlined CSS and stripped hot-reload scripts, written to out/<slug>/<slug>.html, standalone from the preview service. It omits overwrite behavior, permission requirements, and failure modes, so it is strong but not complete.

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 dense sentences, front-loaded with the action and output format. Every clause (inline CSS, strip hot-reload, write path, no preview dependency) carries distinct information with zero padding.

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?

No output schema exists, so the description must convey the result, and it does: a standalone single-file HTML at a stated path for developer handoff. It is sufficient for calling correctly, though it leaves secondary behaviors (e.g., re-export over an existing file) unaddressed.

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% (baseline 3), but the description adds value by showing how the single slug parameter maps to the output path out/<slug>/<slug>.html, clarifying the naming contract beyond the schema's example.

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 (导出/export) and resource (已生成的原型) and names the concrete output (可转发的单文件 HTML). It also indirectly differentiates itself from start_preview by noting it does not depend on the MCP preview service, though it never names that sibling explicitly.

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?

Gives clear context for use: produce a shareable file that a developer can open directly, independent of the preview service. The implicit contrast with start_preview helps routing, but no explicit when-not statement or named alternative is provided.

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

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

With no annotations, the description carries the full burden and does disclose meaningful behavioral traits: it is a mandatory prerequisite call and it enumerates the three payloads returned. It omits output format and pagination details, but for a 0-param read-only getter this is solid disclosure.

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 sentences, both earning their place: the first enumerates the return contents, the second states the mandatory call precondition. Front-loaded with zero filler.

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?

No output schema exists, so the description must summarize return values, and it does list all three returned artifacts plus the calling precondition. Adequately complete, though it could say more about how the rules should be applied.

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 schema has zero parameters, so there is nothing to disambiguate; baseline 4 applies. The description correctly implies no argument is needed.

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 states a specific verb and three concrete resources returned (强制工作流, SKILL.md 全文, visual 规则摘要), which is far more specific than the name 'get_brief' alone. It is clearly distinguishable from all prototype-manipulation siblings.

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?

It gives an explicit precondition: '生成或修改原型前必须先调用' (must be called before generating or modifying a prototype), which routes the agent relative to create_prototype/update_prototype. It does not name those siblings explicitly or state exclusions, so it stops short of a 5.

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

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

With no annotations provided, the description carries the full behavioral burden. It does disclose the important behavioral trait that the three CSS layers must be inlined in a specific order, which an agent could not infer otherwise. It does not describe read-only nature, caching/freshness, or what the returned string looks like structurally beyond 'concatenated'.

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?

A single tightly written sentence with the return composition stated first and the consumption constraint second. Every clause earns its place and nothing is 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?

For a zero-parameter read tool with no output schema, the description covers what is returned and the critical ordering constraint for consuming it. Minor gaps remain – expected format/type of the returned CSS and error behavior – but nothing an agent needs to call it 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?

The tool takes zero parameters, which is the baseline-4 case; there is nothing for the description to disambiguate. Schema coverage is also 100%, so no compensating detail is needed.

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 names the exact resource and its composition – the concatenation of tokens + theme + layout CSS – so an agent knows precisely what this tool returns. It is unambiguous against the prototype-oriented siblings, though it never states the verb 'get' or 'read' explicitly, relying on the name instead.

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 description gives an implicit 'what to do with the result' rule (inline into <style> in this order when generating HTML), which is genuinely useful. However, it never states when to call this tool versus alternatives, nor any prerequisites or conditions for invoking it; usage must be inferred from the returned-content directive.

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

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

No annotations are provided, so the description carries the full behavioral burden. It never states that the call is a safe read-only fetch, what happens when out/<slug>/preview.html does not yet exist (a likely case before create_prototype), or what the response contains. The only behavioral content is the incremental-editing workflow hint, which is thin for a tool with zero annotation coverage.

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?

A single compact sentence with no filler, and the operational constraint (read first) is placed at the front. Slight loss for packing two ideas (read, then edit incrementally) into one clause.

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?

With no output schema and no annotations, the description should say what comes back (the HTML) and the missing-file case; it does neither, leaving the title to carry the return-value meaning. It is adequate for a trivial one-parameter read but not complete.

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 description coverage is 0% and the single slug parameter is undocumented in the schema. The description partially compensates by embedding slug in the path template out/<slug>/preview.html, which hints it is a directory/identifier, but it never defines what a slug is or its format.

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 title states the resource (current prototype HTML) and the description names the concrete artifact path out/<slug>/preview.html, so an agent can infer it retrieves the current prototype markup. However the description is framed as a workflow instruction ('before modifying, read...') rather than a statement of what the tool returns, and it does not distinguish itself from siblings like get_brief or list_prototypes.

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?

It gives a clear usage moment ('修改前读取' – read before modifying) and implicitly steers toward incremental edits over rewriting from scratch. But it names no alternative tools and gives no conditions for when not to call it, so the guidance is implied rather than explicit.

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

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

With no annotations, the description carries the full burden. It usefully discloses the data source (the out/ directory) and that preview URLs are included, which is real behavioral content. It says nothing about ordering, emptiness, or whether results are filtered by user/session.

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?

A single short sentence that front-loads the action and scope with no filler. Every clause earns its place.

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 simple zero-param list tool this covers the essentials, and with no output schema it correctly mentions the returned preview URLs. However it omits the shape of the returned items (identifiers/names) that an agent would need to chain into get_prototype or start_preview.

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 tool takes zero parameters, so the baseline is 4. The schema is trivially empty and there is no parameter meaning for the description to add or omit.

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 (列出/list) and resource (原型/prototypes) plus the scope ('out/ 下已生成的原型') and the payload (预览 URL). It is clearly distinguishable from get_prototype (single fetch), but it never names a sibling to sharpen the boundary.

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?

No when-to-use guidance, prerequisites, or alternatives are given. The listing behavior implies discovery before operating on a prototype, but the description leaves that entirely to inference.

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

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

No annotations are provided, so the description carries the full burden. It does disclose the key traits: localhost binding, hot-reload behavior, and that it returns a URL for the built-in browser. It omits server lifecycle details such as port persistence, blocking behavior, idempotency, or how the service is stopped.

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?

A single tight sentence that front-loads the action ('启动...服务') and ends with the return value. No filler or redundant clauses.

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 side-effecting server-start tool with no annotations and no output schema, the description covers the essentials of what happens and what is returned. It remains silent on the operational details an agent would want (prerequisites, port conflicts, lifecycle), leaving a meaningful gap.

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 description coverage is 100%, so the schema already documents the optional slug parameter and its fallback behavior. The prose adds nothing beyond what the schema states, so the baseline of 3 is appropriate.

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 gives a specific verb+resource: it starts a hot-reload HTTP server on 127.0.0.1 and returns a URL for the built-in browser. This is clearly distinguishable from siblings liked list_prototypes or export_prototype. However, it does not explicitly state what it is not, so it earns a 4 rather than a 5.

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?

There is no when-to-use guidance, no prerequisites (e.g. must a prototype exist first?), and no mention of alternatives or when not to call it. The agent must infer its place in the workflow purely from the name and the sibling list.

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

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

Discloses real side effects beyond what structured data carries: overwriting existing HTML, a validation gate, and notifying open preview pages to reload. With no annotations covering any of this, that's meaningful behavioral context. It stops short of saying what happens on validation failure or whether the write is reversible.

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 short clauses, side effect and validation gate front-loaded ahead of the reload notification. No wasted words.

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?

A mutation tool with no annotations and no output schema carries a high disclosure burden. The description covers overwrite, validation, and reload notification, but omits what happens on validation failure, the slug's role, and any notion of the return value.

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 50%. The description says 'existing prototype HTML' and the schema documents html as '完整 preview.html，不要只交片段' (full file, no fragments), so html is well covered; slug remains undocumented in both description and schema. Baseline 3 given partial coverage.

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+resource (覆盖已有原型 HTML / overwrite existing prototype HTML) and distinguishes itself from the get/create siblings. It doesn't explicitly disambiguate against validate_prototype or start_preview beyond the reload mention.

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 '校验通过后写入' phrasing implies the validation gate and the hot-reload behavior, giving some context for when this runs. But there's no explicit when-to-use vs when-not, nor any alternative tool named (e.g. create_prototype for new prototypes).

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

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

With no annotations, the description carries the full burden, and it does disclose two key traits: validation is static and nothing is written to disk. However, it omits how hard-rule violations are surfaced, whether both inputs may be passed together, and what the check returns.

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?

A single short sentence with the mode (静态检查) and the safety constraint (不写盘) front-loaded; nothing is padded or repeated from the title.

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 and no annotations, so the description is the sole source of behavior, and it leaves the validation rule set, failure/return shape, and parameter interaction unspecified. It is adequate to identify the tool's role but not to invoke it confidently.

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 description coverage is 0%, so the description must compensate, and it does add the crucial semantic that html and slug are alternative inputs ('HTML 或已有 slug'). It still gives no format, length, or mutual-exclusion rules for either parameter.

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?

Names a specific action (静态检查/static validation) and the two accepted inputs (HTML 或已有 slug), which is more than the tool name alone conveys. It does not explicitly differentiate itself from siblings like create_prototype, but the '不写盘' clause hints at the distinction.

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 phrase '按 Skill 硬规则' implies this is the pre-write gate, and '不写盘' contrasts implicitly with the create/update siblings, but the description never states when to call this versus create_prototype or update_prototype, nor any prerequisites.

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