pageaudit

Generate domain fix prompt

generate_domain_fix_prompt

Generate a fix prompt from saved domain observations. 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_domain_fix_prompt"
  }
}

Input Schema

Name	Required	Description
`id`	Yes	Owned tab in the active organization ID.
`scope`	Yes	check or full.
`source`	Yes	domain: the saved registration, certificate, DNS and email observations of the tab.
`check_id`	No	registration, certificate, dns or email. Required for check; absent for full.
`language`	Yes	Language of the prompt instructions and check names: en for English, pt for Portuguese.
`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

A3.9/5.0

Behavior5/5

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

The description adds substantial behavior beyond the annotations: free-unit accounting, per-unit pricing, plan inclusion, hourly rate limits, license persistence, retry behavior with request_id, and the rule that missing evidence is not charged. These details materially help an agent avoid incorrect billing or retry behavior.

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

Conciseness2/5

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

The purpose is front-loaded, but the description is long and repetitive: free-unit and pricing rules are stated multiple times, and quota, payment, and retry guidance are interleaved. Several sentences could be consolidated without losing meaning.

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 complex billing-sensitive tool with no output schema, the description covers prerequisites, authorization, scope-dependent pricing, licensing, retries, and exclusion of unverified evidence. The response shape is only implied by references to the prompt text and license, but the operational context is otherwise strong.

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 description coverage is 100%, so the schema already explains all eight parameters. The description adds useful cost semantics for scope (check uses one unit, full uses three) and clarifies source as saved domain observations, but adds little beyond the schema for id, check_id, guest_token, or credit_token.

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 from saved domain observations, prepared from an owned report. It is clear what the tool produces, but it does not explicitly distinguish itself from adjacent siblings such as get_fix_prompt or generate_site_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 clear prerequisites: read prompt_allowance first, read the quota endpoint before generation, and obtain explicit spending authorization before sending credit_token. It also clarifies that the tool uses saved observations and does not start a new collection, though it does not explicitly route users between sibling prompt tools.

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.