pageaudit

Generate site fix prompt

generate_site_fix_prompt

Generate a fix prompt for a weekly finding or a Search Console opportunity. Prepare a coding-agent prompt from an owned report. One check uses one unit; full uses three. Three units are free once. Then US$0.10 per unit, or included in an active PageAudit plan. Read prompt_allowance first. Only send credit_token after explicit spending authorization; preserve request_id for retries. Read GET /api/prompts/quota before generation; the total depends on scope and existing rights. Three lifetime free units per account or anonymous network. A check uses one; full uses three. Extra units cost US$0.10 each. Active Starter, Pro and Agency plans include prompts while valid, within 60 requests/hour. No partial free debit: a full prompt needs three free units or is charged in full. The licensed prompt is saved for this owner and organization. Reopening the same selector is free even after plan expiry. Unverified checks are excluded: missing measurements are not purchasable correction evidence. Preserve its text and license; use it only for license.domain. Reuse the UUID v4 request_id and identical body after a delivery failure. Payment uses X-Credito or the x402 challenge. Never charge without the user's authorization. Uses saved observations only; does not start a new collection. Missing evidence is not charged.

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": {
      "id": "<id>",
      "scope": "<scope>",
      "language": "<language>",
      "request_id": "<request_id>",
      "source": "<source>"
    },
    "name": "generate_site_fix_prompt"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Owned site ID.
`query`	No	Exact opportunity query; required for Search Console check.
`scope`	Yes	check or full.
`source`	Yes	weekly: a finding of a saved weekly report. search_console: a saved Search Console opportunity.
`check_id`	No	Weekly finding type, or opportunity for Search Console. Required for check; absent for full.
`language`	Yes	Language of the prompt instructions and check names: en for English, pt for Portuguese.
`report_id`	No	Required for weekly: saved report ID.
`request_id`	Yes	New UUID v4 per generation. Keep it unchanged for retries.
`guest_token`	No	Private owner token returned by guest creation. Sent in X-Guest-Token; reuse it for this owner's resources.
`credit_token`	No	Prepaid cred_… token. Requires explicit user authorization.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 5, 2026

addedInput schema / properties / guest_token / description

Added value: +"Private owner token returned by guest creation. Sent in X-Guest-Token; reuse it for this owner's resources."

Changed1 schema field changedOct 30, 2026

addedInput schema / properties / credit_token

Added value: +{
+  "description": "Prepaid cred_… token. Requires explicit user authorization.",
+  "type": "string"
+}

AddedOct 21, 2026

TDQS

A4.1/5.0

Behavior5/5

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

Annotations only declare that this is a non-read-only, non-idempotent, non-destructive call; the description goes far beyond that with pricing (US$0.10 per unit), free-unit accounting (check = 1 unit, full = 3, three lifetime free units), the 60 requests/hour plan limit, and the no-partial-debit rule. It also discloses idempotency mechanics (reuse the UUID v4 request_id and identical body after a delivery failure), licensing restrictions (use only for license.domain), persistence (prompt saved for owner and organization, reopening is free even after plan expiry), and payment paths (X-Credito or x402 challenge). That is unusually complete behavioral context for a paid mutation.

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

Conciseness3/5

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

The pricing and free-unit explanation is repeated almost verbatim, once in the opening ("One check uses one unit; full uses three. Three units are free once. Then US$0.10 per unit") and again mid-paragraph ("Three lifetime free units per account... A check uses one; full uses three. Extra units cost US$0.10 each"). Important constraints are front-loaded, but the repetition and dense billing prose dilute an otherwise well-prioritized description.

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

Completeness4/5

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

For a 10-parameter paid tool with no output schema, the description covers cost, authorization, retry semantics, licensing, and eligibility, and it implies the response carries the prompt text plus a license ("Preserve its text and license"). What it omits is an explicit statement of the return shape and the error/degraded outcomes when evidence is missing. That gap is minor given the breadth of what is documented.

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

Parameters4/5

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

Schema description coverage is 100%, so the baseline is 3 and the schema already explains id, source, scope, check_id, language, and the tokens. The description still adds operational meaning the schema does not: it must precede the call with a quota read, credit_token requires explicit user authorization, and request_id must be reused verbatim with an identical body on retry. This is meaningful guidance layered on top of well-documented fields.

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

Purpose4/5

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

The description states a specific verb and resource ("Generate a fix prompt") and scopes it to two named sources, a weekly finding or a Search Console opportunity, plus "Prepare a coding-agent prompt from an owned report." An agent can tell what it produces without opening the schema. It does not, however, distinguish itself from close siblings such as generate_domain_fix_prompt, generate_fix_prompt, or get_fix_prompt.

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 gives concrete prerequisites and ordering: read prompt_allowance first, read GET /api/prompts/quota before generation, and only send credit_token after explicit spending authorization. It also states a boundary condition ("Uses saved observations only; does not start a new collection") and that unverified checks cannot be used. It stops short of explicitly routing the agent to a sibling when the target is a domain rather than a site, so the when-not guidance is implicit.

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

All pageaudit 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.