Skip to main content
Glama
Sign In

Launchfiles

by app.launchfiles
OverviewDiscussionsAdmin

launchfiles_standalone_design_ux_radar_free

Public free Design UX Radar preview for one URL. Scores come from fixed rules; a small language model writes the next-step text. Paid tier is not open to the public yet. Does not edit or publish the site. Rate-limited. Optional partner leave-behind fields add structured zones on this JSON response only (not public /cro chrome). client_ref is echoed so the caller can file the pair in their own DB; Launchfiles does not list runs by client. hide_lf_chrome is honored only for an authenticated lf_agent_ key; otherwise the response sets hide_lf_chrome false and wl_entitlement needs_auth. logo_url is an https URL shape check only (no fetch); a bad shape returns LOGO_URL_INVALID and no leave-behind.

Input Schema

NameRequiredDescriptionDefault
urlYesPublic https URL to analyze (preview mode only).
roleNo
deviceNo
localeNo
logo_urlNoAbsolute https URL. Shape is checked; this path does not fetch the image. Invalid shape returns LOGO_URL_INVALID.
brand_nameNoPartner display name. Empty keeps Launchfiles labels. Do not invent a name.
client_refNoOpaque client tag echoed next to run_id. Distro files this pair in Distro's DB. Launchfiles does not isolate or list clients from this echo.
partner_idNoOptional. Must match the partner_id claim on the lf_agent_ key. A mismatch or an anonymous claim returns UNAUTHORIZED_PARTNER or NEEDS_AUTH. Omit to use the key's claim. Partner keys also consume the daily runs quota.
notify_emailNoOptional. If you want a link back to this report later, send an email. Not required.
primary_colorNoOptional #RGB or #RRGGBB header accent. Invalid values are ignored.
hide_lf_chromeNoWhen true, Launchfiles wordmark and powered-by are removed only if the caller authenticated with lf_agent_ (including a partner-scoped key). Otherwise hide_lf_chrome is false and wl_entitlement is needs_auth.
idempotency_keyNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so well: it discloses rate limiting, that it does not edit or publish the site, auth-gated chrome behavior (hide_lf_chrome honored only for lf_agent_ keys, otherwise needs_auth), partner quota consumption, and the LOGO_URL_INVALID error path.

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?

Front-loaded purpose followed by tightly packed behavioral caveats with essentially no filler. It is dense and lacks visual structure (no bullets), which slightly hurts scannability, but every sentence carries information.

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 12-param, no-annotation, no-output-schema tool, the description covers the high-risk behaviors (auth, errors, quota, non-mutation) and response shaping. Minor gaps remain on role/device/locale/idempotency_key semantics, but the critical invocation risks are addressed.

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?

At 67% schema coverage across 12 params, the description adds real meaning beyond the schema for the ambiguous fields: client_ref is echoed and not used for listing, logo_url is shape-checked only with no fetch, partner_id must match the key claim, and hide_lf_chrome's auth condition is spelled out.

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?

Opens with a specific verb+resource and scope: 'Public free Design UX Radar preview for one URL,' and clarifies the scoring mechanism. The 'Design UX Radar' naming distinguishes it from the sibling search-repair and deployment-trust radars, though it never explicitly contrasts them.

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

Usage Guidelines3/5

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

Usage is implied ('preview mode only', 'Paid tier is not open to the public yet', 'Rate-limited') but there is no explicit routing guidance to alternatives like page_draft_paid or the other free radars. An agent must infer when to pick this over siblings.

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

All Launchfiles toolsInspect
Try in Browser
Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources