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

The description discloses the return behavior (read-back, real example, optional questions), the meaning of answer_required, and explicitly notes that no data extraction occurs. This goes well beyond the sparse annotations, which only declare readOnlyHint false, openWorldHint false, idempotentHint false, and destructiveHint false; the description supplies the substantive behavioral context the annotations lack.

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 front-loaded with the core purpose and each subsequent sentence earns its place by explaining the return state, sibling-routing, and the design/save/run separation. The use of formatted answer_required values keeps the lifecycle information scannable without unnecessary prose.

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 to lean on, the description successfully explains the return value, the two answer_required states, and the next steps with sibling tools. It also clarifies what the tool does not do (extract data) and how the design phase relates to saving and execution, making the tool complete for agent selection and invocation.

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 description coverage is 100%, so the baseline is 3 because the schema already documents both parameters well. The description adds context like 'from the user's own words' and 'real example from their data,' but these mostly echo or lightly reinforce the schema's existing parameter descriptions rather than introduce new parameter meaning.

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 ('Designs'), a clear resource ('a goal'), and the input source ('the user's own words'), while also explaining what the goal captures ('what Mitosis should pull out of their data, and how the things in it connect'). It distinguishes creation from saving and running via the sibling tool references, so an agent can tell cortex_create_goal apart from cortex_accept_goal and cortex_answer_goal.

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?

The description explicitly separates designing, saving, and running into distinct operations and states that 'Nothing is extracted from any data here,' which is a clear when-not. It also routes the agent to cortex_answer_goal when answer_required is true and to cortex_accept_goal when answer_required is false, giving concrete alternatives for the relevant states.

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