getwowlink — Link Preview & OG Image Checker

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

Annotations already declare readOnlyHint=true and destructiveHint=false, so the safety profile is covered. The description adds real value beyond that: no account is required, the caching behavior is surfaced through the fresh parameter's 15-minute cache note, and it discloses that the result contains a link to a visual report. Rate limits and error behavior remain undisclosed.

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?

Three tight sentences with the purpose front-loaded, followed by usage context and practical extras; nothing is padded. The closing sentence about the visual report link is slightly redundant given an output schema exists, keeping it just short of a 5.

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?

With annotations covering safety, the schema covering both parameters, and an output schema handling return values, the description only needs to supply scope and context, which it does well (platforms, tag types, pre/post-launch timing, no-account requirement). The one real gap is the absence of any hint about how this differs from check_site_previews, a directly adjacent sibling.

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 url (example.com/blog/post) and fresh (skip 15-minute cache after deploying a fix) fully documented in the schema. The description adds no parameter-level detail beyond what the schema already provides, 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?

States a specific verb and resource (scores how a page looks when shared) and enumerates the target platforms, which is far richer than the title alone. It does not, however, differentiate itself from the near-identical sibling check_site_previews, leaving the agent to guess which plural/singular variant to pick.

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?

"Useful before launch or after changing meta tags" gives a clear triggering context for invoking the tool. There is no explicit when-not guidance or named alternative (e.g. versus check_site_previews or create_previews), so the routing decision is only partially resolved.

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

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

Annotations already declare readOnly/openWorld/no-destructive, but the description adds critical operational behavior they cannot convey: the ~25 second budget, the check_id continuation mechanism, and that the tool works without an account. These are exactly the traits an agent needs to invoke and poll correctly.

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 sentences, no filler, and the scope-and-detections clause is front-loaded before the async caveat. Every clause carries operational information.

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?

An output schema exists so return values need not be described. Combined with the account-free note, the async continuation contract, and the page cap, the description gives an agent everything needed to call and re-call the tool correctly.

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 coverage is 100% and the schema defines both url and check_id, so the baseline is 3. The description goes beyond it by explaining the check_id's role in resuming an in-flight check, which clarifies the intended call pattern rather than just restating the field.

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?

States a specific verb (checks) and scope (up to 50 pages from the sitemap) plus the exact conditions it detects: no image, one shared image, or broken pages. This is enough to distinguish it from the sibling check_link_preview, which operates on a single link rather than a whole site.

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 async flow explicit: a call returns in ~25s, and an unfinished check returns a check_id that a later call resumes from. This tells the agent when a second call is needed. It stops short of explicitly naming check_link_preview as the single-page alternative, so usage is implied rather than spelled out.

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

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

Goes well beyond the annotations by disclosing the sign-in/auth prerequisite, the asynchronous state ('while the site is still being read, the result says so and a later call continues'), and the exact side-effect boundary ('nothing is published... never by this tool'). These are precisely the behavioral facts an agent cannot get from readOnlyHint=false / destructiveHint=false.

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?

Front-loaded with the core action, then the prerequisites and the async caveat. Sentences are dense but each carries new information; the parenthetical aside about the client asking for sign-in is slightly awkward but earns its place as an auth note.

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?

Covers purpose, auth, async continuation, and the no-publish guarantee, and an output schema exists so return values need not be spelled out. The one gap is that it never names the tool to call back for the still-reading case, leaving that handoff implicit.

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 coverage is 100% and the enum on page_type is fully documented ('Detected when omitted'), so the schema does the heavy lifting. The description adds no syntax, format, or example beyond what site_url and page_type already state.

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?

States a specific verb and artifact: 'Creates branded Open Graph image designs for a site,' and clarifies the output is a picker link rather than a published image. It does not name any sibling, so an agent still has to infer that wait_for_design is the continuation path from the vague phrase 'a later call continues.'

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?

Gives clear triggering context (needs a getwowlink account and a sign-in, so it is not a fire-and-forget call) and a firm boundary that this tool never publishes. It stops short of explicitly naming the alternative to use while the site is still being read, which is the main routing decision an agent faces here.

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

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

Annotations already flag this as a non-read-only, destructive operation, and the description adds the specific side effect that explains that flag: it records 'agent' as the site's connection method, replacing the previously set one. It also discloses the published-design prerequisite. What is missing is any statement about whether the replacement is reversible or what happens on failure.

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?

Three short sentences with no filler, though the ordering is slightly off — the return value comes first and the side effect, arguably the most decision-relevant fact, is buried last. The quoted "agent" is a minor readability wrinkle.

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?

An output schema exists, so explaining return values is unnecessary, and the annotations cover the safety profile. The description supplies the prerequisite and the state-mutating side effect, which are the two things structured fields do not convey; only the hand-off to sibling workflow steps is absent.

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 site_url and visits documented in the schema itself, so the description is not required to carry parameter meaning. It adds no syntax, format, or default details beyond the schema, 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 states the specific resource returned: og:image and twitter:image tags for every page plus the image URL pattern. That is concrete enough to distinguish it from sibling tools like verify_install or check_site_previews, though it never names an alternative or reconciles the name 'get_install_instructions' with the tag-shaped output.

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 gives one real prerequisite ('Needs a published design'), which is genuinely useful context. However it says nothing about when this tool should be chosen over verify_install or wait_for_design, both of which sit in the same install workflow, so usage is only implied.

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

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

Annotations already declare readOnlyHint, openWorldHint and non-destructive, so the safety profile is covered. The description still adds real context: the checks run against live pages (matching openWorldHint), the specific conditions tested, and the default scope of the home page. Auth requirements and any rate/latency behavior are left unstated, and the output schema covers return values.

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 dense sentences with zero filler. The core check is front-loaded, the sequencing prerequisite follows, and the default-scope caveat closes it out — every clause carries information an agent needs.

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?

With an output schema, full annotation coverage, and 100% schema description coverage, the description only needs to supply intent, sequencing, and scope defaults — all of which it does. Nothing required to invoke this correctly is missing.

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 coverage is 100%, so the baseline is 3; the description goes slightly beyond by adding the format constraint that each path must start with '/' and reconfirms the 5-path cap and home-page default in the flow of the sentence. It adds a genuine rule not present in the schema, though most parameter meaning still comes from the 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?

States a specific verb and resource (verifies live pages) and enumerates exactly what is checked: one og:image, served by getwowlink, and whether crawlers already fetch the images. It also names the sibling get_install_instructions, so an agent can distinguish it from check_link_preview or check_site_previews without opening a schema.

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?

Gives explicit sequencing: 'Meant for after the tags from get_install_instructions are deployed.' That tells the agent when to reach for this tool rather than the install-instruction tool. It stops short of naming when-not to use it or which sibling to use instead for other verification needs.

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

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

Annotations already declare readOnlyHint=true, destructiveHint=false and a closed world, so the safety profile is covered. The description adds genuinely new behavior: the call returns in about 25 seconds (i.e. it is a bounded long-poll, not an indefinite block) and it enumerates the four observable states (generating, waiting for the person, published, failed), which tells the agent to poll rather than assume completion.

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 sentences with the blocking behavior and the return content front-loaded, and no filler. The phrase 'says what to install' is slightly loose compared with the precise state list that follows, but the overall structure is efficient.

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 one-parameter, read-only polling tool with an output schema present, the description covers what the agent needs: it blocks, it returns within ~25s, and it reports one of four states. The output schema carries the return shape, so no further return-value detail is required.

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 is a single parameter with 100% schema description coverage, and the schema already explains that generation_id comes from create_previews. The description adds no syntax, format, or provenance detail beyond that, so the baseline 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?

States a specific verb and resource ('waits until the person has picked and published a design') plus the outcome ('says what to install'), so an agent can distinguish it from create_previews and the check_* siblings. It is clear but does not explicitly name or contrast with any sibling tool.

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?

Usage is only implied: the fact that it blocks until a person acts, combined with 'then says what to install', suggests calling it after create_previews and before install. No explicit when-to-use, when-not-to-use, or named alternative (e.g. check_site_previews) is given, so the agent must infer the sequencing.

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