ProductClank

Generate the AI-visibility report

generate_ai_visibility_report

Generate (or regenerate) the report for an AI-visibility check from everything the panel submitted: the verdict, how the models describe the product, strengths, risks with how often they came up, verbatim quotes, findings and ranked recommendations. Free. It waits for the check to end so the report covers the whole panel; pass allow_partial:true to report on what is in so far (you can regenerate later). Relay the verdict, risks and recommendations to the user and give them report_url (private: the owner and their delegates).

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "check_id": "<check_id>"
    },
    "name": "generate_ai_visibility_report"
  }
}

Input Schema

Name	Required	Description	Default
`check_id`	Yes	The check id.
`allow_partial`	No	Generate before the check has ended, from the submissions in so far.

Schema Changelog

Changes observed during successful MCP inspections.

AddedNov 8, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations it discloses cost ('Free'), the blocking/waiting behavior until the check ends, idempotent regeneration semantics, and the access scope of the returned report_url ('private: the owner and their delegates'). These are exactly the operational facts an agent needs and none are derivable from readOnlyHint/destructiveHint/openWorldHint.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The verb and resource are front-loaded, and each follow-up sentence carries distinct information (cost, waiting, partial mode, relaying instructions). The first sentence is a long comma-separated enumeration of report contents that could be tightened, but nothing is redundant.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema, the description compensates by listing what the report contains and telling the agent what to relay to the user and to hand over report_url. For a two-parameter generation tool this covers selection, invocation, timing, and post-call behavior.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented in the schema, and the description mainly restates allow_partial's meaning ('report on what is in so far'). It adds only a marginal nuance, namely that partial reports can be regenerated later, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Specific verb + resource ('Generate (or regenerate) the report for an AI-visibility check') plus an enumeration of what the report contains (verdict, model descriptions, strengths, risks with frequency, quotes, findings, ranked recommendations). This makes it clearly distinct from the sibling read tool get_ai_visibility_results and from create_ai_visibility_check.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a real usage rule: by default it waits for the check to end, and allow_partial:true is the escape hatch for reporting early, with the note that regeneration is possible later. It does not explicitly name the sibling alternatives (get_ai_visibility_results / create_ai_visibility_check) or state when not to call it, which keeps it short of a 5.

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

All ProductClank tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.