browserless_link_connect

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

Annotations already flag destructiveHint=true, openWorldHint=true, and non-idempotent behavior, so the safety baseline is covered. The description adds real behavioral detail beyond that — status never returns a URL, connect mints a Stripe-owned authorization URL intended for the user, disconnect removes the connection — plus a valuable security guardrail ('Never ask the user for raw card details'). It stops short of describing persistence or error behavior.

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?

Front-loaded with the resource and purpose, then the action routing, then the guardrail. Four tight sentences, all load-bearing. There is mild redundancy in restating the connect flow twice, but the repetition reinforces the key failure mode rather than 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?

With no output schema, the description correctly fills the return-value gap by stating what status vs. connect produce, and it covers all three actions plus the sequencing rule between them. Nothing an agent needs to invoke this tool 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?

Schema coverage is 100% and the enum is documented, so the baseline is 3. The description earns above baseline by giving each enum value operational meaning that the terse schema string does not: status 'never returns a URL' and connect yields an authorization URL to hand the user.

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 a specific resource (Browserless Stripe Link wallet) and enumerates its three operations (status/connect/disconnect) with a clear verb for each. It distinguishes the actions from one another well, but never references the sibling browserless_link_checkout, so cross-tool differentiation is left to inference.

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 explicitly prescribes when to call each action and, critically, the conditional flow: 'When status is not_connected, call connect to obtain that URL — the status instruction alone has no link.' This removes the most likely agent error (stopping after status) and is exactly the when-to-use guidance the dimension asks for.

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