Skip to main content
Glama

Postclick by PPC.io: Landing Page CRO

Ask a question about an audit

ask_audit
Read-onlyIdempotent

Free. Answers one question from a completed audit by returning that part of it in full: small enough to give the user whole, unlike the entire report. THIS IS THE TOOL FOR ANY FOLLOW-UP QUESTION about a page you have already audited. Never answer a question about an audited page from your own summary of it — the audit holds far more than any summary kept, and this is how to get the part that answers them. Pick the topic that matches what they asked: buyers for who is on this page, what each one is afraid of, the exact words they would object with, where they give up, and a second-by-second walkthrough of one of them reading it. the_pitch for whether the pitch itself is wrong: if the page meets the traffic where it is, which persuasion levers are missing and what each would do here, and how the offer is built. trust for whether a stranger believes it: the proof that is there, the proof that is missing, and why buyers hesitate. competitors for who else is bidding on these clicks, their live headlines and CTAs, what they do better, and the keywords and CPCs behind their pages. copy for the copy deck: the page's own lines quoted, each with the line that replaces it. leaks for the ranked problems with the evidence for each. the_page for what the page is, who it is aimed at, its own voice and palette, and how it is assembled section by section. technical for CTA placement and contrast, accessibility, and what changes on mobile. What comes back is written to be read out. Relay it: keep the names, the quotes, the numbers and the specific objections, reformat it for where you are, and do not compress a named buyer saying a specific sentence into a general remark about buyers. Needs a completed audit. Safe to call repeatedly, and calling it for two topics in a row is normal and costs nothing.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
topicYesWhich part of the audit answers the question. buyers · the_pitch · trust · competitors · copy · leaks · the_page · technical.
audit_idYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, closed-world), but the description adds non-obvious behavioral context: the call is 'Free,' costs nothing, is safe to repeat, and calling it twice in a row is normal. It also discloses the response is written to be read aloud and should be relayed verbatim. It stops short of describing latency or output format details.

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?

Purpose and routing are front-loaded in the first two sentences, and each topic clause does real selection work the enum text does not. It is nonetheless very long and dense; the topic list could be tightened without losing routing value.

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?

For a two-parameter lookup tool with no output schema, the description covers what is needed: the prerequisite, the meaning of every topic value, the shape of the return value ('written to be read out'), and how to relay it. Nothing required to call it correctly is missing.

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

Parameters5/5

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

Schema coverage is only 50% (audit_id is undocumented), but the description compensates heavily by defining what each of the eight enum values returns — e.g. 'buyers' for who is on the page and their objections, 'leaks' for ranked problems with evidence. This is meaning well beyond the schema's bare enum listing.

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?

States a specific verb and resource — 'answers one question from a completed audit by returning that part of it in full' — and explicitly contrasts the scope against the sibling that returns the whole report ('unlike the entire report'). An agent can distinguish this from get_audit and get_audit_report without opening any schema.

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?

Explicitly routes usage: 'THIS IS THE TOOL FOR ANY FOLLOW-UP QUESTION about a page you have already audited' plus a hard exclusion, 'Never answer a question about an audited page from your own summary of it.' It also states the prerequisite ('Needs a completed audit') and notes that repeated/batched calls are expected, leaving little to inference.

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