CheckMyApp

Start a check

start_check

Destructive

Use this whenever a change has to be seen working in a browser — after a deploy, on a PR preview, behind a login: CheckMyApp uses the app as a real visitor, signs in with the app's stored test account, and reports what is broken. Start a check. With app_id: checks a saved app using its stored test logins, scenarios and limits — the usual call after a deploy (add deploy_sha and deploy_env so the verdict names the build, and notes for what just shipped). A Shopify app on several stores can be named by shopify_app and store instead of app_id. With url: a one-off check of any address; set ephemeral: true for a PR preview. To check exactly one thing, pass scenarios (ids from list_scenarios) or focus (a scenario or a symptom in words): the check walks only that, and get_review's coverage.asked_not_walked lists what it could not walk, at no cost; keep: true keeps a focus as a scenario of the app. With focus, expects says what must be seen — one sentence each — and get_review answers every one (seen, wrong, not_seen) with the step that shows it. A whole check takes about 20–40 minutes and spends the team's balance (its price is on wait_for_run / get_review when it finishes); follow it with wait_for_run or get_check_status. Refusals carry a stable code (quota_balance, quota_free, plan_limit, not_found, forbidden, invalid_input) — do not retry a quota refusal; quota_balance and quota_free carry buy_url and upgrade_url for the user.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "start_check"
  }
}

Input Schema

Name	Required	Description
`url`	No	Or: any deployed URL to check once, e.g. a PR preview
`keep`	No	With app_id and focus: keep it as a scenario in every check of the app
`team`	No	Act in another of your teams, by its name or id (whoami lists them). Omitted: the key's own team
`focus`	No	What to check, in words — a scenario or a symptom, e.g. 'Export a report: the CSV downloads'. The check walks only this
`notes`	No	What to focus on this run, e.g. 'PR #123 changed checkout'
`store`	No	With shopify_app: which store to check it on, e.g. 'my-staging-store'
`app_id`	No	Check a saved app with its stored test login, scenarios and limits. Use this OR url
`expects`	No	With focus: What must be SEEN for this to count as working, one sentence each, in words the product itself shows — e.g. ["The heading reads «Account settings».", "The page has no «Delete workspace» section."]. Start each with a capital letter. The check answers every one with a step: seen, shows otherwise, or not seen
`ephemeral`	No	With url only: a throwaway hostname (PR preview) — private, no app kept, deleted after ~7 days
`scenarios`	No	With app_id: scenario ids (from list_scenarios) — the check walks these and nothing else (up to 5)
`deploy_env`	No	Environment the deploy landed in, e.g. production
`deploy_sha`	No	Commit/build id this deploy shipped, e.g. $GITHUB_SHA — binds the verdict to it
`scope_hints`	No	With url only: hard limits for this run
`shopify_app`	No	Or: a connected Shopify app's handle (list_apps shopify_app), with store
`notify_email`	No	With url only: email for the verdict-ready notice. Omitted: a broken verdict you have not read within 15 minutes goes to the person you act for

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedNov 6, 2026

addedInput schema / properties / expects

Added value: +{
+  "description": "With focus: What must be SEEN for this to count as working, one sentence each, in words the product itself shows — e.g. [\"The heading reads «Account settings».\", \"The page has no «Delete workspace» section.\"]. Start each with a capital letter. The check answers every one with a step: seen, shows otherwise, or not seen",
+  "items": {
+    "maxLength": 200,
+    "minLength": 8,
+    "type": "string"
+  },
+  "maxItems": 12,
+  "minItems": 1,
+  "type": "array"
+}

First observedNov 5, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations by disclosing cost (spends the team's balance, price surfaced on wait_for_run/get_review), runtime of 20–40 minutes, ephemeral host deletion after ~7 days, and the refusal code set with an explicit instruction not to retry quota refusals. The buy_url/upgrade_url detail and the note that deployment metadata binds the verdict add real operational context that annotations cannot carry.

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 lead sentence is front-loaded and every sentence carries decision-relevant content, but the body is a single dense paragraph with stacked parentheticals (deploy_sha/deploy_env/notes, focus/expects/get_review) that is harder to scan than the content warrants. Nothing is truly wasted, though splitting the modal routing from the cost/refusal notes would improve parseability.

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 15-parameter, no-output-schema tool with destructive and open-world annotations, the description covers cost, duration, async follow-up, narrowing, persistence, and failure codes. An agent has everything needed to invoke it correctly and to interpret a refusal without additional tool calls.

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, and the description genuinely adds cross-parameter constraints the schema cannot express: app_id OR url, shopify_app paired with store, ephemeral and notify_email only with url, keep only with app_id+focus, expects only meaningful with focus. One discrepancy weakens it: the description says scenarios walks "up to 5" while the schema permits maxItems 20, which could mislead an agent about capacity.

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?

Opens with a concrete verb and resource plus a plain-language definition of what a check is ("uses the app as a real visitor, signs in with the app's stored test account, and reports what is broken"). It also distinguishes itself from the polling siblings by naming wait_for_run and get_check_status as follow-ups.

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?

Gives explicit routing rules across the mutually exclusive modes: app_id for saved apps (the usual post-deploy call), url for one-offs and PR previews with ephemeral, shopify_app+store for multi-store Shopify apps. It also states when to narrow with scenarios vs focus and when keep applies, so an agent can pick the right invocation without guessing.

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

All CheckMyApp tools Inspect

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.