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

Annotations already declare readOnly, idempotent, non-destructive and closed-world behavior, so the safety profile is fully covered. The description adds the return payload shape (sheet numbers plus catalogReady, mappingVersion, roles, extras, mappingErrors) and a scoping caveat (no organization id), which is useful but modest beyond 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?

Two sentences, front-loaded with the resource and its scope, with the scoping caveat at the end. The parenthetical field list is dense but earns its place by telling the agent what comes back.

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?

For a zero-arg read tool with no output schema, the description supplies the return payload and the scope constraint, which is nearly everything an agent needs. Only an explicit contrast with list_sheets is missing.

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 tool takes zero parameters, so the baseline is 4. The description's note that it 'does not accept an organization id' correctly reinforces the empty schema and prevents an agent from inventing an argument.

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?

States a specific verb (list) and a precisely scoped resource (sheet numbers enabled as product catalog sheets), which separates it from the general list_sheets and from mutators like enable_catalog_sheet. It does not name sibling tools explicitly, so differentiation is by qualifier rather than by routing.

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?

Usage is implied by the 'enabled as product catalog sheets' qualifier, so an agent can infer it's the catalog-scoped listing. However, there is no explicit when-to-use guidance, no mention of list_sheets as the alternative for non-catalog sheets, and no exclusions beyond the org-id note.

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