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

No annotations are provided, so the description carries the behavioral disclosure burden. It explains what the tool returns (motion, rationale, first moves, failure patterns) and makes clear this is an advisory/diagnostic interaction. It does not explicitly state there are no side effects, but the read-only analytical nature is strongly implied by the description.

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 three sentences and every sentence serves a purpose: defining the action, specifying when to use it, and giving examples. It is front-loaded with the core function and uses illustrative examples efficiently without redundancy.

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?

Despite having no output schema, the description thoroughly explains the return content: which delivery motion applies, why, first moves, and typical mistakes. Combined with the strong usage guidance and parameter framing, the description is fully sufficient for an agent to select and invoke this tool correctly.

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 input schema already describes the 'situation' parameter well, including symptoms, stack, team size, and stage. The tool description adds meaningful context by framing the input as 'messy go-to-market situation', requesting plain language, and giving real-world example prompts that help the agent understand what constitutes a valid situation.

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 tool's function: take a messy GTM situation in plain language and return the applicable LeanScale delivery motion, reasoning, first moves, and common pitfalls. It also distinguishes itself from searching by positioning this tool for problem-focused questions rather than topic research.

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?

Explicitly says to use it when someone describes a problem rather than asking about a topic, provides concrete examples, and contrasts it with search for 'what should we do about this?' This gives the agent clear decision criteria for tool selection.

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