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

Annotations already cover the mutation/safety profile (readOnly=false, destructive=false, idempotent=false), so the bar is lower, and the description goes beyond them usefully: slug must be unique among active collections, a hard cap of 100 active collections, and that the limit surfaces as a conflict error. It does not say what happens on a slug collision specifically or what the call returns, so it is not fully transparent.

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?

One tight paragraph that front-loads the action, then constraints in a sensible order (identifiers, then nested fields, then quota). Dense but every clause carries a constraint or behavior; the semicolon-chained formatting makes it slightly harder to scan than a short list would.

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?

There is no output schema, so the description is the only place an agent could learn the return shape (does it return the new collection ID and its fields?), and it says nothing about that. Combined with the unexplained `websiteId` parameter, the definition is adequate to invoke but leaves the agent guessing about results.

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 0%, so the description carries the burden and mostly succeeds: it translates the slug pattern into prose, adds the uniqueness rule and 64-char limit, states displayName 1–200 and description 2,000, and explains the fields array (max 100, same shape as create-field body). It omits any meaning for `websiteId`, the only remaining required parameter, which is a real gap at 0% coverage.

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?

Opens with a specific verb+resource ('Creates a collection in the website's CMS') and implicitly distinguishes itself from cms_fields_create by offering inline field definition ('same shape as the create-field body'). It never names the sibling tools it competes with (cms_fields_create, cms_collections_update), so differentiation is inferable rather than explicit.

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 'optionally pass fields … in the same call' phrasing hints at the alternative of creating fields separately, and the 100-collection cap implies a guard condition. But there is no explicit when/when-not guidance, no prerequisites (e.g., website must exist or have no conflicting slug), and no named alternatives.

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