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

Annotations already declare readOnlyHint=true, idempotentHint=true and destructiveHint=false, so the description's 'Read only' adds nothing and the safety profile is fully covered elsewhere. It does add one useful behavioral fact not in the annotations: credentials are applied server-side, so the caller needn't supply auth. That single addition, plus the platform default, justifies a middling score rather than a low one.

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 content is front-loaded (platform list first) and the whole definition is three short sentences with no padding. The trailing 'Read only' is redundant with readOnlyHint and 'Uses the saved credentials server side' is slightly circuitous, but nothing is verbose or buried.

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 only two parameters, full schema coverage and read-only annotations, most of what an agent needs is present, and no output schema exists so return-shape explanation is not strictly required. However, for a 'get options' tool the shape of the response (list of option objects? ID/label pairs?) is the single most important thing an agent must anticipate, and the description only indirectly gestures at it via field names. Adequate but with a visible gap.

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, but the description goes beyond the schema by mapping each platform enum value to the specific downstream ID field it yields (categoryId, memberId, framerCollectionId, fields) — information the schema does not contain. This materially helps the agent decide which options to request. It says nothing about the 'site' parameter, but that is fully documented in the schema.

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 title plus description make clear this returns platform-specific selectable options (Shopify blogs, Wix members, Framer collections, Webflow fields) from the connected CMS. It names the concrete resource categories rather than restating the tool name, so an agent can distinguish it from generic getters like get_settings or list_page_templates. It never states the return verb explicitly ('returns a list of...'), which keeps it out of the 5 band.

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?

It tells the agent the downstream purpose of each option set — 'to pick categoryId', 'memberId', 'framerCollectionId', 'fields' — and names the follow-up action 'Save the choice with update_settings'. That is genuine when-to-use context plus a routing hint. It lacks explicit exclusions or a statement of when not to call it, so it falls short of a 5.

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