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

Annotations already declare readOnly, idempotent, non-destructive, closed-world behavior, so the safety bar is met by structured data. The description adds real behavioral content beyond that: it renders an in-chat setup path with one-tap prompts and prescribes conversational conduct, including a privacy constraint not to request credentials. It does not describe what the rendered output actually contains beyond 'prompts'.

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 activation condition, followed by what it shows and how to behave. Every sentence carries instruction, with no filler. The middle sentence ('shows a single in-chat setup path and one-tap prompts') is the weakest, since it gestures at output without describing it.

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 zero parameters and no output schema, the description is the only carrier of what the call does, and it covers trigger, rendered result, and conversational constraints. What an agent still cannot predict is the concrete payload of the setup path or how the one-tap prompts are surfaced, a minor gap for a simple onboarding tool.

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 tool takes no parameters, so there is nothing for the description to disambiguate and the baseline of 4 applies. Nothing in the definition misrepresents the empty schema.

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 concrete behavior: it shows a single in-chat setup path with one-tap prompts for connecting Bobby/Robinhood and getting personalized portfolio help. That is specific enough for an agent to know what the call produces, though the term 'Bobby setup' itself is only implicitly explained and there is no explicit contrast with the sibling stock-data tools.

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?

Triggers are explicit: a new user, a question about connecting Bobby or Robinhood, or a request for personalized portfolio help. It also gives negative guidance ('do not send the user to a multi-page guide or request credentials'), which tells the agent what not to do alongside the call. No named alternative tool is offered, which keeps it short of a 5.

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