Open Graph / Twitter card preview check

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 safety profile is covered. The description adds useful behavioral context beyond annotations: it explicitly checks remote image reachability, file size, content type, and fallback behavior, indicating the tool performs network fetches and assesses resource metadata. This goes beyond the bare annotation data without contradicting it.

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 sentence that front-loads the core action ('Validate how a page previews when shared') and then efficiently lists the specific checks. It is dense but not bloated; every listed item adds concrete information. It could be broken into two sentences for readability, but it earns a high score for no wasted words.

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 the tool's moderate complexity and lack of an output schema, the description is almost complete: it covers what is validated and the main checks. However, it does not describe the result format (e.g., pass/fail, list of issues, or a structured report), which an agent would need to know for downstream handling. With no output schema to fill this gap, the description leaves a meaningful ambiguity.

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 schema has a single 'url' parameter with no description (0% coverage), so the description must compensate. It effectively encodes the meaning of the parameter by stating the tool validates 'a page' that is to be shared, clearly implying the URL parameter is the target page. For a one-parameter tool, this is sufficient to make the parameter's role unambiguous.

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 ('Validate') and resource ('how a page previews when shared') and enumerates concrete checks (OG tags, Twitter card, image reachability, dimensions, etc.). It is clearly distinct from sibling tools like page_audit or structured_data_audit because it focuses exclusively on social/messaging/link-card preview behavior, so an agent can select it unambiguously.

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 makes the use case implicit: 'when shared' and the list of social contexts imply the tool is for preview validation. However, it does not explicitly state when to use this tool versus alternatives (e.g., page_audit, structured_data_audit), nor does it mention exclusions or prerequisites. The usage context is clear enough but not explicitly contrasted with sibling tools.

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