Skip to main content
Glama

Postclick by PPC.io: Landing Page CRO

by io.ppc
OverviewDiscussionsAdmin

Create a public link to share

share_page

Free. Mints a public no-login link that anyone can open, including someone with no account. THIS IS THE TOOL FOR 'send me the designs' or 'I want to forward this to my client'. Never hand over a dashboard or app link for that: the recipient hits a login wall and sees nothing. Pass concept_id to share a DESIGN, which comes back as one page with every band stacked in order, so it reads as a whole design rather than a folder of separate images, and it prints to PDF from the browser if they want a file. Pass build_run_id to share a finished BUILT page. One or the other, not both. Pass audit_id to share the AUDIT itself, and section:"competitors" with it to open the link on the Competitors section rather than the whole report. export_page is the one for a user who wants the source files instead. For a build, minting a new link revokes the previous one, so reuse the link rather than calling this repeatedly. A design link is stable and safe to call again.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sectionNoWhich part of the audit the link opens. Only with audit_id. `competitors` opens on who is bidding against the page, for forwarding that one answer. Defaults to full.
audit_idNoShare an AUDIT. From audit_page or get_audit. Use this when someone wants to forward the findings themselves rather than a design or a built page.
concept_idNoShare a design. From get_concepts. This is the one to use when someone wants to show designs to a client.
build_run_idNoShare a finished built page. From build_page or get_build.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changed
    • addedInput schema / properties / audit_id
      Added value: +{
+  "description": "Share an AUDIT. From audit_page or get_audit. Use this when someone wants to forward the findings themselves rather than a design or a built page.",
+  "type": "string"
+}
    • addedInput schema / properties / section
      Added value: +{
+  "description": "Which part of the audit the link opens. Only with audit_id. `competitors` opens on who is bidding against the page, for forwarding that one answer. Defaults to full.",
+  "enum": [
+    "full",
+    "competitors"
+  ],
+  "type": "string"
+}
  2. First observed

TDQS

A4.1/5.0
Behavior1/5

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

Although the description discloses many behavioral traits, it states that minting a new build link 'revokes the previous one' while annotations declare destructiveHint=false. That is a destructive side effect contradicting the annotation, which the scoring rubric treats as an annotation contradiction.

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 description is front-loaded and mostly earns its length for a tool with several distinct sharing modes. It is slightly longer than necessary, with minor redundancy such as 'no-login' and 'including someone with no account' restating the same access condition.

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 still explains the return behavior well: a public link, one stacked design page for concept_id, a built page for build_run_id, and an audit link for audit_id. It gives enough context to call the tool correctly despite the branching parameter combinations.

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 already 100%, but the description adds meaningful semantics beyond the schema: concept_id returns a stacked design page, build_run_id shares a built page and revokes the prior link, audit_id shares the audit, and section opens the Competitors view. It also clarifies mutual exclusivity and reuse behavior.

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 gives a precise verb and resource: it 'mints a public no-login link' and explicitly distinguishes sharing a design, built page, or audit. It is immediately clear what the tool produces and how it differs from siblings like export_page.

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 states exactly when to use the tool ('send me the designs', 'forward this to my client'), when not to use it (never a dashboard or app link), and names the alternative for source files (export_page). The rules for mutually exclusive IDs and link reuse are also explicit.

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

All Postclick by PPC.io: Landing Page CRO toolsInspect
Try in Browser
Give agents eyes on the webHosted screenshot MCP. Send a URL, get a pixel-perfect image. $0.002 per grab. Works with Claude, Cursor, and Codex.grabbit.liveAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources