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

Annotations already flag destructiveHint=true, idempotentHint=false and openWorldHint=true; the description adds that it makes live calls to external AI providers and silently skips unconfigured ones. It does not explain what the destructive flag means in practice (overwriting/adding check records), that re-running creates new checks, or any cost/latency implications of hitting many providers.

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-loads the action and outcome in the first sentence, then packs the parameter mapping into one dense but readable sentence, ending with the return value. No filler.

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, default scope, parameter naming and a brief return summary despite no output schema and 34 parameters. Gaps remain around the destructive/non-idempotent behavior and what 'the checks and the summary' actually contains, which matter for a mutating, open-world call.

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?

With 34 parameters at 0% schema description coverage, the description earns real credit by decoding the naming convention: website via seliee_website_id or seliee_website_uuid, prompts via the two prompt-id/uuid lists, and per-provider credentials via <provider>_account_id/_uuid. It stops short of stating that all parameters are optional, defaults (null = all prompts), or the precedence when both id and uuid are supplied.

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+object: query AI providers with the site's prompts and record whether the site is mentioned. That is distinguishable from read-only siblings like get_visibility_summary or list_visibility_prompts, though the bracketed "[publish, queued]" prefix is opaque and neither clarified nor tied to the semantics.

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 useful operating context (defaults to all prompts, max 10, providers without an account id are skipped), which implies this is the batch execution step. But it never names an alternative or a when-not-to-use condition, e.g. versus get_visibility_summary for reading prior results.

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