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

Annotations already declare readOnlyHint=true, destructiveHint=false, idempotentHint=true and openWorldHint=false, so the safety profile is covered. The description adds real behavioral context beyond that: the tool returns step-by-step UI instructions and performs no side effects itself, and the agent must act via browser tools. The note about Quickbase having no official MCP server is background context rather than behavior, slightly diluting the value.

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 core instruction is front-loaded in the first two clauses, which is good, but the final sentence about Quickbase's API landscape is not needed to select or invoke this tool and costs space. The run-on structure mixing guidance, routing, and vendor trivia makes it less crisp than it could be.

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-parameter, read-only guidance tool with full annotation coverage and no output schema, the description gives enough: what it returns, that it has no side effects, and which tools to use next. What's missing is the returned content's limits (e.g., whether it covers only the caller's own role and not roles for other users), a meaningful constraint given the title says 'Change user role'.

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?

There are zero parameters, so the baseline is 4. The description correctly implies a no-argument invocation by framing the tool as a guidance generator. Nothing further is needed.

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 names a specific action and resource ('Change user role in the user's own Quickbase account'), which is clear and distinguishable from data CRUD siblings like quickbase_update_record. However, it doesn't explicitly contrast with quickbase_list_app_users, the closest sibling for user administration, so differentiation is implicit rather than stated.

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 clearly says this tool only provides step-by-step guidance and 'opens nothing by itself', then directs the agent to perform the change with cotlet_browser_* tools. That is explicit routing to the alternative mechanism. It does not state when-not-to-use (e.g., the tool only works for the user's own account, not other users), which keeps it below a 5.

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