link

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

Beyond the destructiveHint=true annotation, the description discloses a non-obvious side effect: changes on a shared component alert every linked project via an update todo plus a brief note. It also sets a clear boundary ('FlowState only alerts; it does not change other apps' code'). It stops short of describing reversibility of remove or permission needs.

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 front-loaded with purpose and an example, then proceeds by action and field, so nothing is wasted. It is a single dense paragraph that runs long, which slightly hurts scannability.

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 15-parameter tool with no output schema, it covers the main add/remove/list workflows and the critical source/target/link_type semantics. It omits what list returns and a few minor flags (note, model, include_removed), leaving small gaps.

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?

With only 53% schema coverage, the description does heavy lifting: it explains source options (project, component, item_type+item_id), target options (target_project + target_component, target_type+target_id, or url) and enumerates link_type values with a GitHub/Linear url note. Some parameters (note, model, include_removed) remain unexplained.

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 states a specific verb (link) and resource (things across projects), then immediately scopes it: write for add/remove, project required. The worked example (two apps using one protocol) makes the cross-project linking use case unmistakable and distinguishes it from generic create/update siblings.

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 gives an explicit trigger: 'Use when projects share something, e.g. several apps use one protocol,' and enumerates the three actions (add/remove/list) with their flows. It lacks explicit when-not-to-use or named sibling alternatives, capping it below 5.

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