nex_browser_bind_account

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

While the destructiveHint annotation indicates destructive behavior, the description itself transparently mentions 'replaces the existing binding' and 'remove it', which are destructive actions. It also discloses the rejection of running windows. It does not explicitly label itself as destructive but provides enough behavioral detail about state changes and failure conditions.

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 concise and well-structured, with each sentence delivering a distinct piece of information: core function, replacement behavior, removal method, precondition, and subsequent step. No extraneous verbiage.

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?

Given the tool's moderate complexity, the description covers essential operational context: the need for closed windows, the removal option, and the recommended follow-up action. It does not describe potential error scenarios beyond the rejection, but this is sufficient for typical usage. The absence of an output schema reduces the need for return-value explanation.

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 fully covers all parameters, and the descriptions add important semantics: windowId/windowIds are aliases and must reference closed windows, while accountIds explains the replacement effect and special values ([] or 0) for clearing. This makes each parameter's role clear and actionable.

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 core action: binding workspace catalog platform accounts to NexBrowser windows. It specifies the resource, target, and the replace behavior, leaving no ambiguity about the tool's primary purpose.

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?

Provides explicit usage instructions: how to remove bindings with an empty array, the requirement that windows must be closed first, and a pointer to the complementary tool (nex_browser_accounts) for post-opening steps. This gives clear when-to-use and when-not-to-use context.

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