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

Annotations already declare readOnlyHint, openWorldHint, idempotentHint, and destructiveHint false, so the safety profile is covered. The description adds meaningful behavior beyond annotations: it clarifies the kind of connection checked (OAuth MCP or API token in FreedomOS Vault), explicitly rules out founder dashboard sessions, and states that it returns the connected account plus existing Pages/Workers/zones.

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 front-loaded with the core purpose and return value, then gives routing. The routing section slightly restates the earlier 'Use before claim_cloudflare_preview' point, but every sentence otherwise adds value, and the routing block is clearly scannable.

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 a single well-documented parameter, strong annotations, and no output schema, the description is complete: it states what the tool returns, the exact connector to use when not connected, and the downstream tool to call. Nothing essential is missing for correct invocation.

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%: companyId is already fully documented as the company to act within and as required for company-scoped tools. The description does not need to add parameter detail, so the baseline of 3 applies.

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 uses a specific verb ('See whether') with a precise resource: whether the company has a standing Cloudflare deploy grant in FreedomOS Vault for Pages, Workers, and DNS. It also differentiates itself from a 'founder dashboard session' and names the sibling claim_cloudflare_preview, so an agent can distinguish it from nearby tools without opening schemas.

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 explicitly says 'Use before claim_cloudflare_preview' and gives a conditional route: if not connected, call request_connector with connector="Cloudflare", then claim_cloudflare_preview. It even excludes invoke_integration with a reason, giving clear when/when-not guidance and named alternatives.

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