Skip to main content
Glama

Audit a landing page for conversions

audit_landing_page
Read-only

Loads a public landing page in a real browser (desktop and mobile), and returns a conversion score from 0 to 100, seven sub-scores (clarity, value proposition, CTA, trust, design, mobile, SEO basics), the top 3 issues with concrete fixes, what already works, a short AI-readiness score, and fix_prompt: a Markdown prompt that hands the fixes to a coding agent such as Claude Code or Cursor. Use it when someone wants feedback on why a homepage, landing page or pricing page does not convert, wants a second opinion before a launch, or wants to compare their page with a competitor's. Do not use it for pages behind a login, for non-HTML files, or for general SEO keyword research. It takes 30 to 90 seconds; if it returns status "running", call get_audit_result with the audit_id. The free result is complete on its own. The full report (every other issue ranked by the points it costs, the 36-check list, 3 headline and 3 CTA rewrites, 5 quick wins, mobile review, full AI-readiness fixes) costs $5 USD one-time, paid by a human at report_url. Set language to "pt" for a report in Brazilian Portuguese. A URL audited through the API in the last 24 hours (in the same language) returns that same result. Limit: 5 new audits per hour per client, 20 with an API key. With an API key that has credits (Authorization: Bearer header; 10 full reports for $29, see https://pagecritic.app/developers), the result includes the full report.

Input Schema

NameRequiredDescriptionDefault
urlYesFull URL of the public web page, e.g. https://example.com or https://example.com/pricing.
languageNoLanguage of the report: "en" (English, default), "pt" (Brazilian Portuguese), "es" (Latin American Spanish). Headline and CTA rewrites stay in the page's own language. Prices stay in USD.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • changedInput schema / properties / language / description
      Previous value: -"Language of the report: \"en\" (English, default), \"pt\" (Brazilian Portuguese). Headline and CTA rewrites stay in the page's own language. Prices stay in USD."New value: +"Language of the report: \"en\" (English, default), \"pt\" (Brazilian Portuguese), \"es\" (Latin American Spanish). Headline and CTA rewrites stay in the page's own language. Prices stay in USD."
    • changedInput schema / properties / language / enum
      Previous value: -[
      -  "en",
      -  "pt"
      -]New value: +[
      +  "en",
      +  "pt",
      +  "es"
      +]
  2. Changed1 schema field changed
    • changedInput schema / properties / language / description
      Previous value: -"Language of the report: \"en\" (English, default) or \"pt\" (Brazilian Portuguese). Headline and CTA rewrites stay in the page's own language. Prices stay in USD."New value: +"Language of the report: \"en\" (English, default), \"pt\" (Brazilian Portuguese). Headline and CTA rewrites stay in the page's own language. Prices stay in USD."
  3. Changed1 schema field changed
    • addedInput schema / properties / language
      Added value: +{
      +  "description": "Language of the report: \"en\" (English, default) or \"pt\" (Brazilian Portuguese). Headline and CTA rewrites stay in the page's own language. Prices stay in USD.",
      +  "enum": [
      +    "en",
      +    "pt"
      +  ],
      +  "type": "string"
      +}
  4. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only say readOnlyHint and openWorldHint; the description adds substantial context beyond that: 30–90 second runtime, async behavior with status "running", free vs paid report boundaries, human payment at report_url, 24-hour same-language caching, rate limits, and API-key credit behavior. Nothing contradicts the read-only annotation.

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?

It is front-loaded with what the tool does and returns, then adds operational details. The pricing and API-key sentences are long, but they serve important behavioral transparency rather than repeating schema or annotation data.

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?

There is no output schema, but the description fully explains the return shape, async flow, rate limits, paid-report behavior, caching, and language effects. An agent has enough information to select and invoke the tool correctly without guessing.

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 coverage is 100%, so the schema already explains both url and language. The description still adds useful semantics: language affects the report and cached results, "pt" yields Brazilian Portuguese, and a recently audited URL in the same language returns the same result.

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?

The description states a specific verb and resource (loads a public landing page in a real browser) and enumerates the exact outputs: conversion score, seven sub-scores, top issues, fixes, and fix_prompt. It also directly routes async results to get_audit_result, so an agent can distinguish this tool's role from at least that sibling without opening schemas.

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

Usage Guidelines5/5

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

It explicitly names when to use it: pages not converting, pre-launch second opinions, competitor comparison. It also names exclusions (login-protected pages, non-HTML files, general SEO keyword research) and tells the agent to call get_audit_result when status is running.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources