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

Annotations already indicate readOnlyHint=false and openWorldHint=true, so the description doesn't need to restate that this is a mutating, world-changing action. The description adds valuable behavioral context: it explains that CortexPlus sends an authentication key by email, that the tool can either create or begin sign-in, and that the agent must collect the key and call connect. This goes beyond the annotations and helps the agent understand the side effects and next step.

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 compact and front-loaded: it states the purpose first, then the required user interaction, then the follow-up step. Every sentence earns its place, and the critical instruction not to guess the email is included 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?

Given the tool's complexity (a multi-step signup flow with a follow-up connect call), the description is complete. It covers what the tool does, what the agent must ask the user, what happens next, and the constraint against inventing data. The output schema exists, so return values don't need to be described. The only minor gap is not explaining what happens if the user already has an account, but the description already covers 'begin signing in to an existing one'.

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 schema already documents all three parameters. The description adds meaning by explaining the workflow around the email parameter (ask the user, never guess) and the name parameter (use if not already known). It doesn't add detail about the client parameter, but the schema already covers that, so the description's added value is sufficient.

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 ('Create a CortexPlus account, or begin signing in to an existing one') and resource ('CortexPlus account'), and clearly distinguishes its purpose from siblings like connect by explaining the signup flow. It also ties the tool to the conversation's use of CortexPlus as long-term memory, which makes its role unambiguous.

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 gives explicit when-to-use guidance: ask the user for email and name, call this tool, then ask for the authentication key and call connect. It also tells the agent what not to do ('Never guess or invent the email address'). This is strong usage guidance that routes the agent through the correct sequence and to the sibling tool connect.

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