Verify ownership

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

Annotations already provide idempotentHint=true and destructiveHint=false, and the description adds meaningful context beyond them: the tool only checks and places nothing, and failures are usually transient propagation delays rather than invalid input. The DNS/CDN propagation explanation gives an agent a concrete retry model that annotations alone cannot convey. No contradiction with 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 tight paragraphs: the first states the action and the prerequisite, the second explains failure semantics and the expected retry response. Every sentence earns its place — no filler or repetition of schema content. The most decision-relevant fact (this call only checks) is front-loaded.

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 2-parameter tool with annotations covering idempotency and destructiveness, plus an output schema, the description is nearly complete. It covers the prerequisite workflow, the failure mode, and the retry guidance an agent needs to act correctly. The only minor omission is explicit guidance on what distinguishes verification from unverification or site setup, though the core call path is fully specified.

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%, with both method and site_url already documented including defaults, examples, and the trailing-slash requirement. The description references the token placement workflow that contextualizes the method parameter but adds no parameter-level detail beyond the schema. Baseline 3 is appropriate since the schema carries the parameter documentation burden.

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 states a specific verb and result: "Tells Google to check for the verification token and, if it finds it, records this credential as an owner." This clearly distinguishes verify_site from sibling get_verification_token by explicitly noting "this call only checks, it does not place anything." The scope (verification versus token retrieval, site addition, or unverification) is unambiguous.

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 workflow guidance: "Run get_verification_token first and place the token" — establishing the prerequisite and ordering relative to a specific sibling. It also tells the agent how to interpret failures and that retrying is the normal response. It does not explicitly state when NOT to use this tool vs alternatives like add_site or unverify_site, but the usage context is well-defined.

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