Setup instructions

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false. The description adds valuable behavioral context beyond those flags: it is safe to call without credentials, it returns structured JSON, and it exposes known API limits. Nothing about the tool's observable behavior is hidden or contradicted.

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 a single dense sentence that front-loads the core purpose and then enumerates the checklist contents and usage trigger. It is longer than the minimal alternative but every clause carries distinct information about setup prerequisites, scopes, and API limits. A slight structural split into two sentences would improve readability, but no content is wasted.

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 zero parameters, rich annotations, and no output schema, the description is fully complete: it tells the agent what the tool returns, the specific setup facts the checklist covers, that no credentials are needed, and exactly when to invoke it. An agent can confidently decide to call this tool and understand what it will receive.

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 parameter baseline is 4. The description goes further by explaining the content of the returned checklist and the conditions under which the tool should be invoked, which compensates for the absence of an output schema. There is nothing more parameter semantics could add with an empty input 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 description immediately states the tool 'Returns the setup checklist for this server as structured JSON' — a specific verb, resource, and output format. It enumerates exactly what the checklist covers (Apps Script API enablement, OAuth scopes, run_function prerequisites, API limits), and its purpose is clearly distinct from all sibling tools, which operate on projects, versions, functions, or raw requests.

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 gives explicit when-to-use guidance: 'call it first when any tool fails with 403 PERMISSION_DENIED or when setting the server up.' It also notes 'Works without credentials,' which tells the agent this tool is safe to invoke in unauthenticated or failure contexts. This fully routes the agent to the correct first step.

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