Skip to main content
Glama

Shipfound

by co.shipfound.api
OverviewDiscussionsAdmin

Home page and signup path check

funnel_check

Whether a visitor understands the page, wants the product, and can get from the home page to signup and payment. Reads the live home page from outside and follows every button near the top: one that only scrolls the same page, a broken link, no signup within one click, a signup page with no form or sign in with button, a pricing page with no way to start or pay. Returns those misses (fail, or unsure when script decides), each with evidence, a fix and an id for meta.fixIds; funnel: the site's mapped funnels (funnels_save) with visitors at each step and leak, the move between two steps that loses the most visitors across them and what kind of move it is (mapped false until the agent maps them; then only 28 days of visitors, signups and payments); plays: what to try on that leak, best evidence first, never one that needs proof (testimonials, logos, user counts) the business may not have, nor one already shipped or skipped; judge: whether an A/B test can answer at this traffic or the change ships as a before and after on the same move; read: the page's words, the founder's list of what the product gets its customers (null until they give it once), and a script that measures the page at phone width; and walk: the checks only a browser can make (mobile-cta, after-signup, upgrade-path), for the agent to walk in the founder's Chrome without creating an account or paying. Call again with record for what the read and the walk found (copy checks: copy-understood, copy-value, copy-filler, copy-cut, copy-length, copy-missing, copy-visual; a miss about particular lines quotes them word for word, and lines not on the live page are refused), measure for the phone numbers before and after, outcomes for the founder's list, or skip for ids the founder will not fix. A shipped fix is hidden until the site is read again after it, and verify re-checks it on the live site: the buttons, and that the lines a copy fix changes are gone. Free.

Input Schema

NameRequiredDescriptionDefault
urlNoThe page visitors arrive on; default the home page
skipNoFinding ids (convert:...) or plays (play:<id>) the founder will not do: never shown again
recordNoWhat the read of the page and the walk in Chrome found, one entry per check
measureNoThe phone numbers from read.measure.script: before the changes, and after them on the preview
outcomesNoThe founder's own list of what the product gets its customers, in their words

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / skip / description
      Previous value: -"Finding ids the founder will not fix: never shown again"New value: +"Finding ids (convert:...) or plays (play:<id>) the founder will not do: never shown again"
  2. Changed9 schema fields changed
    • addedInput schema / properties / measure
      Added value: +{
+  "additionalProperties": false,
+  "description": "The phone numbers from read.measure.script: before the changes, and after them on the preview",
+  "properties": {
+    "ctaScreen": {
+      "anyOf": [
+        {
+          "maximum": 500,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "overflowPx": {
+      "maximum": 10000,
+      "minimum": 0,
+      "type": "number"
+    },
+    "screens": {
+      "maximum": 500,
+      "minimum": 0,
+      "type": "number"
+    },
+    "visualScreen": {
+      "anyOf": [
+        {
+          "maximum": 500,
+          "minimum": 1,
+          "type": "integer"
+        },
+        {
+          "type": "null"
+        }
+      ]
+    },
+    "when": {
+      "enum": [
+        "before",
+        "after"
+      ],
+      "type": "string"
+    },
+    "words": {
+      "maximum": 100000,
+      "minimum": 0,
+      "type": "integer"
+    }
+  },
+  "required": [
+    "when",
+    "screens",
+    "words",
+    "overflowPx"
+  ],
+  "type": "object"
+}
    • addedInput schema / properties / outcomes
      Added value: +{
+  "description": "The founder's own list of what the product gets its customers, in their words",
+  "items": {
+    "maxLength": 200,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • changedInput schema / properties / record / description
      Previous value: -"What the walk in Chrome saw, one entry per walk check"New value: +"What the read of the page and the walk in Chrome found, one entry per check"
    • changedInput schema / properties / record / items / properties / check / enum
      Previous value: -[
-  "mobile-cta",
-  "after-signup",
-  "upgrade-path"
-]New value: +[
+  "mobile-cta",
+  "after-signup",
+  "upgrade-path",
+  "copy-understood",
+  "copy-value",
+  "copy-filler",
+  "copy-cut",
+  "copy-length",
+  "copy-missing",
+  "copy-visual"
+]
    • changedInput schema / properties / record / items / properties / evidence / description
      Previous value: -"What you saw in the founder's Chrome: the button's words, the screen, the number of clicks"New value: +"What you saw: the button's words, the screen, the number of clicks; for a copy check, why the lines fail a first-time visitor"
    • addedInput schema / properties / record / items / properties / fix / description
      Added value: +"What to change; for copy, the new text for each line (or cut)"
    • changedInput schema / properties / record / items / properties / fix / maxLength
      Previous value: -800New value: +1200
    • addedInput schema / properties / record / items / properties / quotes
      Added value: +{
+  "description": "Copy checks: the page's own lines, word for word as the live page shows them, at least six characters each",
+  "items": {
+    "maxLength": 400,
+    "minLength": 1,
+    "type": "string"
+  },
+  "maxItems": 20,
+  "type": "array"
+}
    • changedInput schema / properties / record / maxItems
      Previous value: -10New value: +20
  3. Added

TDQS

A4.1/5.0
Behavior5/5

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

With annotations only declaring readOnlyHint=false, openWorldHint=true and destructiveHint=false, the description carries real additional burden and does: it reads the live site from outside, never creates an account or pays, refuses lines not on the live page, hides shipped fixes until re-read, and is free. It even discloses that the funnel view holds only 28 days of visitors, signups and payments once mapped, which an agent cannot infer from annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness2/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Nearly every clause carries information, but the whole definition is one sprawling pseudo-sentence joined by semicolons, so the core purpose is not cleanly front-loaded. An agent must parse a dense chain of modes and return keys to find the call contract. The content earns its place; the structure does not.

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?

This is a complex tool with five parameters, nested objects and no output schema, and the description still accounts for the return surface: misses with evidence, fix and id, funnel with mapped steps and leaks, plays, judge, read, and walk. It also names the checks the agent must perform in the browser (mobile-cta, after-signup, upgrade-path), so nothing essential to calling or interpreting it is missing.

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 already 100%, so the baseline is 3, but the description adds genuine meaning: it ties each parameter to a mode (record from the read/walk, measure from read.measure.script, outcomes = the founder's own words, skip = ids never shown again) and explains the copy-check quoting rule and the refusal of lines not on the live page. It loses a point because the parameter discussion is threaded through a run-on sentence, making it harder to map back to individual properties.

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?

The description states a concrete verb and scope: it reads the live home page from outside and follows every button near the top to check whether a visitor can get to signup and payment. The named failure modes (button that only scrolls, broken link, no signup within one click, pricing page with no way to pay) make the tool's job unmistakable. It never names the closest sibling (landing_check) or another alternative, so it stops short of a 5.

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

Usage Guidelines4/5

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

It spells out the operating modes and their triggers in a single chain: call again with record for what the read and the walk found, measure for the phone numbers before and after, outcomes for the founder's list, skip for ids the founder will not fix. It also states lifecycle rules (a shipped fix is hidden until the site is read again; verify re-checks it). It gives no explicit when-not-to-use or sibling routing, so it lands at 4 rather than 5.

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

All Shipfound 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