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

Annotations already declare write, non-destructive, closed-world, so the description is not carrying the safety burden. It does add genuinely non-obvious behavior: the test is free, the bet and lines are mutable only until the first message ships and locked thereafter, and a result that lands between the lines is 'too close to call' and grows by a third. It stops short of saying what the tool returns (presumably the sizing and thresholds) or confirming it only creates rather than mutating an existing plan.

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?

It is reasonably short and front-loads the purpose, but it is written in dense house jargon ('sized by Shipfound', 'the lines a result must cross', 'the users routine') packed into long parenthetical sentences, which makes it slower to parse than its length warrants. No sentence is pure padding, but the structure could be broken into clearer clauses.

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 four-parameter planning tool with a nested outcome object, no output schema, and annotations that cover safety, this is close to sufficient: it defines the concept, maps all three required parameters, explains the goal-vs-event sourcing for outcome, and covers the mutation window and cost. The remaining gap is that it never states what calling it produces.

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 already 100%, so the baseline would be a 3, but the description earns more by tying rate/who/outcome to X/Y/Z and by explaining where outcome values come from: a tracked site goal whose name comes from goals_list, or a server-sent product event tied to the users routine. That sourcing guidance is absent from the schema and directly affects how an agent fills the nested outcome object.

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 verb and artifact ('Plan a Bullseye Test') and defines the resulting object precisely as a bet of the form 'At least X% of Y will Z', plus the sizing and pass/fail lines computed for it. It doesn't distinguish itself from closely named siblings like bullseye_add, bullseye_change, bullseye_batch, or bullseye_read, so an agent must infer that this is the create/plan entry point.

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?

There is no explicit when-to-use guidance and no named alternative; the description never says to call bullseye_plan before bullseye_add/bullseye_mark or instead of bullseye_change. The only routing signal is implicit in the lifecycle note that a planned test 'changes until its first message goes out', which hints at the plan-then-lock workflow without stating it.

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