open_wechat_html_in_browser

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

With no annotations, the description carries the burden of behavioral disclosure. It states that the tool opens a file in a browser, which implies a read-only, non-destructive action, but it does not mention potential side effects like launching an external application, whether the browser will block, or what happens if the file path is invalid. The workflow instruction adds context, but some behavioral details remain implicit.

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?

The description is two sentences with no wasted words. The first sentence front-loads the core action, and the second provides essential workflow guidance. Every word earns its place, making it highly concise and well-structured.

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 single-parameter tool, the description covers the purpose, the workflow, and the necessary context (cached file from conversion). It doesn't elaborate on error handling or return values, but given the tool's simplicity and the schema already documenting the parameter, the description is sufficiently complete. A brief note about the file not existing would be a minor enhancement, but it's not critical.

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 covers the single parameter (cache_path) with a clear description stating it is returned by convert_markdown_to_wechat_html. The tool description adds the word 'cached' and the workflow context, but this is largely redundant with the parameter description. Baseline 3 is appropriate since the schema already provides the essential meaning.

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 clearly states the action (open), the target resource (cached WeChat HTML file), and the destination (default browser). It also includes the follow-up workflow (select all, copy, paste), making the tool's purpose unambiguous and distinct from the sibling tools that convert or list themes.

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 provides clear context: it is used after converting Markdown to WeChat HTML, as it references the cached file. The second sentence explains exactly what to do next, effectively telling the user when to use this tool (as an intermediate step) and what actions follow. It doesn't explicitly mention alternatives, but no real alternatives exist for this specific open-and-copy workflow.

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