读取官网实时模板

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=false and destructiveHint=false, so the safety profile is covered. The description adds one genuinely useful behavioral fact beyond that: that guide.extra.node_list entries with action_type=input carry the authoritative node_key. It says nothing further about freshness or size of the returned spec, and since an output schema exists that gap is tolerable.

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 compact clauses, front-loaded with the behavioral fork over the single parameter, then the input-key caveat. Dense and mostly waste-free; the node_list sentence is cryptic out of context but earns its place as a correctness warning.

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?

This is a low-complexity single-parameter read tool with an output schema, so the description does not need to explain return values. It covers mode selection, the one parameter, and the key pitfall (do not guess first/last), leaving only minor gaps around code format.

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 carry the meaning of code, and it does: omitting it returns the complete spec set, supplying it narrows the response to one template. What is missing is any hint of the expected code format or how to obtain a valid one.

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 retrieval operation with two modes: no code returns the full official tool-specs, a code returns the specified template. The verb-plus-resource is clear, but it never distinguishes this lookup from the similarly named sibling pavo_apply_template, so an agent must still infer 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?

The two-mode behavior implies when to pass code versus omit it, and the closing warning tells the agent not to guess first/last when locating input keys. There is no explicit statement of when this tool is required versus alternative siblings such as pavo_apply_template or pavo_list_nodes, so the guidance is implied rather than prescribed.

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