Skip to main content
Glama
Sign In

LandingBoost

by app.landingboost
OverviewDiscussionsAdmin

Scan a website

scan_site

Start a LandingBoost scan of a public website: phone and desktop screenshots of up to 3 pages (homepage first; call suggest_pages to choose them, or homepage and pricing are picked automatically; the pricing page is always scanned when the site has one), measured mobile, copy and search checks, and new wording for the problems found. Returns a scan_id at once; the scan takes about 2 minutes. Poll get_scan, then call get_actions. Counts toward the scan limit: use it for a new site or after big changes (a new page or layout). After a single fix, call recheck_page instead (free).

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": {
      "url": "<url>"
    },
    "name": "scan_site"
  }
}

Input Schema

NameRequiredDescriptionDefault
urlYesHomepage URL, for example https://example.com
pagesNoOptional public pages on the same site (pricing, features, onboarding). Up to 3 pages in total, homepage included. The pricing page is always added; past the plan's page limit it replaces the last other page.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / pages / description
      Previous value: -"Optional public pages on the same site (pricing, features, onboarding). Up to 3 pages in total, homepage included."New value: +"Optional public pages on the same site (pricing, features, onboarding). Up to 3 pages in total, homepage included. The pricing page is always added; past the plan's page limit it replaces the last other page."
  2. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=false and openWorldHint=true, so the mutating, external-facing nature is known; the description goes further by disclosing that it counts toward a scan limit, returns a scan_id immediately, and takes about 2 minutes. It also prescribes the async follow-up sequence (poll get_scan, then get_actions), which is real behavioral context. The only gap is that it doesn't say what happens if the scan fails or whether a failed scan still consumes quota.

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?

A single dense paragraph that front-loads what gets scanned, then the return/latency contract, then the cost/alternative rule — a sensible order for an agent. It is slightly long and repeats the pricing-page rule that the schema already states, but no sentence is filler.

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, yet the description supplies the return contract (immediate scan_id, ~2 minute duration) and the full follow-up workflow via get_scan and get_actions. Combined with the cost model and page-selection defaults, an agent has everything needed to invoke and then drive this tool to completion.

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 baseline is 3; the description adds selection behavior beyond the schema by stating the homepage is scanned first, that suggest_pages can choose the others, and that homepage and pricing are auto-picked when none are supplied. That auto-default behavior is genuinely useful decision information not spelled out in the schema's parameter text.

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 ('Start a LandingBoost scan of a public website') and immediately enumerates the scope of the artifact produced: phone/desktop screenshots of up to 3 pages, mobile measurement, copy and search checks, and suggested wording. It is clearly distinguishable from sibling recheck_page (single fix) and suggest_pages (page selection), which are named.

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?

Explicit when-to-use: a new site or after big changes such as a new page or layout. Explicit when-not: after a single fix, use recheck_page instead, and it even notes that path is free. It also routes page selection to suggest_pages versus automatic homepage+pricing defaults.

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

All LandingBoost toolsInspect
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.

Resources