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

The description discloses the key side effect (sending a 6-digit code to the email) and frames it as a first step (not the final creation). It also references the follow-up action needed to complete signup. While the annotations already indicate a non-read-only operation (readOnlyHint=false), the description adds meaningful context about the email-based verification flow and the 10-minute TTL shown in the schema. It does not contradict any annotations.

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 concise sentences, front-loaded with 'Step 1 of agentic signup' to set immediate context. Every sentence adds value: what it does, the next step, and when to use it. No redundant filler or repetition of schema property names.

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 is part of a two-step signup flow, the description covers both the current action and the next step, making the complete context clear. An output schema exists, so return values are handled. The description also names the sibling verify tool, preventing confusion among the large sibling list. For a moderately complex tool (5 params, workflow context), this is fully complete.

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 provides 100% coverage with descriptions for all five parameters, including format details (email, ISO country code, enum for industry, IANA timezone, max lengths). The description adds no significant new parameter-level meaning beyond what the schema already documents. Baseline 3 is appropriate since the schema carries the semantic load.

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 role as 'Step 1 of agentic signup' and its action: 'Sends a 6-digit verification code to the email.' It explicitly distinguishes this from the sibling verification step, register_organisation_verify, and ties it to a specific user goal: creating a new FavCRM workspace. This goes beyond a vague verb+resource and provides strong differentiation.

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 says when to use it ('Use this when a user wants to create a new FavCRM workspace from inside an MCP client') and gives the next step: 'After the user reads the code, call register_organisation_verify with it to finish and receive an API key.' This names the alternative tool and provides a clear workflow, satisfying the when/when-not criteria.

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