install_widget

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 does disclose the mutation mechanism (editing an HTML file) and the deprecation status, which is real value, but it says nothing about idempotency (what happens if the widget is already installed), whether the edit is reversible, error behavior when no entry point is found, or permission requirements expected of a file-writing tool.

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?

Three sentences, front-loaded with the most decision-relevant fact (deprecation) before purpose and behavior. No filler, though the auto-detection clause slightly restates what the file_path schema already says.

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 annotations and no output schema, the description must stand alone for a file-mutating tool. It covers purpose, alternative, and targeting, but omits failure modes, idempotency, and confirmation of what state results after injection — gaps an agent would want before invoking a write operation.

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%, including the dev_only hostname wrapping and the wildcard semantics of allowed_hostnames, so the schema already does the heavy lifting. The description only echoes the file_path auto-detection behavior, adding little beyond structured data; 3 is the appropriate baseline.

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 (install the feedback widget) and the concrete mechanism (injecting the script tag into an HTML file), plus the auto-detect vs. explicit-path behavior. It also names the sibling it is superseded by (setup_extension), so an agent can place it against uninstall_widget and setup_extension without opening the schema.

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?

"Deprecated — prefer the browser extension (setup_extension)" is an explicit when-not-to-use plus a named alternative, front-loaded in the first clause. This is exactly the routing guidance an agent needs before selecting this tool.

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