MCP servercom.boosthis/boosthis

What happened after the changes Boosthis witnessed here - only those that passed through it: a fix it served, or a sentence it was asked to check. Each reads kept, broken or cant_t

This account's Boosthis alerts, in the dashboard's words: Open, Read, Fixed, Closed by Boosthis, Closed (who unknown), Returned or Dismissed, each saying whether its screen or chec

Holds a sentence an assistant is about to say against what the running app actually did. Exactly one of four answers: supported, not supported by the measurements, cannot tell yet,

Whether a newer Boosthis kit exists for this project, without fetching it: latest_version, update_available, comparison (behind/current/ahead/unknown), the changelog for every rele

What Boosthis knows about this account's installs (same check over plain HTTPS: GET /api/connection-status, project key as bearer): for each, the runtime, its state, when it was la

Crash classes this app recorded - uncaught errors, unhandled rejections and caught render near-misses - newest first, each with an error name, a redacted top frame, an occurrence b

What this app was OBSERVED exposing: leaks, cookie flags, dev settings left on, turned-away traffic, build age, swallowed errors. Each carries its limits; never a safety claim. Rea

One user action across the stack as a nested waterfall of spans (layer, route label, duration, start offset, rating), each under the call that caused it; criticalHop names the hop

A Boosthis kit for THIS project - no upload; the single-use address needs no key, include_files no shell. Withheld reply? Same kit at GET https://www.boosthis.com/api/kit/<runtime>

Removing Boosthis from this project: the ordered sequence, every kit file, the package entries, the config, the calls to strip, and the Boosthis entries in an AI tool's config. Ord

Full detail for one rule: title, when_to_apply, evidence, and - for a registered project - the fix_template. fix_available: false means no fix text is served here; fix_note says wh

Every scheduled job this runtime reports, each in one state: on time; late; app unheard (the app, not the job, went quiet); never reported a run; or no rhythm declared, so it is re

Every Boosthis performance rule available to this runtime, as ids and titles. The index for boosthis_get_rule.

The Maintenance Mix: of the issues a project actually fixed, how many were fixed before users felt them (flagged by a Boosthis rule, app still healthy) versus after a crash or a po

Ranks Boosthis rules against a code snippet on each rule's id tokens and when_to_apply text, up to 8 candidates. Ranked guesses from a text match, not findings: each rule's when_to

What this project's hosting platform allows, confirmed on real installs. One answer per fact: the time and memory limits a run can read, a live countdown, a processor clock that mo

This project's life in order, joined from what Boosthis already keeps: fixes served, claims checked, promises and their verdicts, history moves, and changes assistants filed. Each

The standing promises this project's developer has recorded - what they want kept as the project changes, surviving earlier sessions and assistants. Each says whether Boosthis can

File a change you made here, so the next assistant knows - Boosthis cannot see code or commits. Kept as YOUR claim, never evidence. Passwords, keys and personal details are refused

How the last release held up, from the running app after it shipped, against the version this project's own measurements reported. Six answers: did served fixes stop the problems,

Saves what the developer wants kept true from now on as a promise on the project, in their words, surviving later sessions and other assistants. Restating one replaces it rather th

Per-screen p50/p75/p95 and worst rating, worst screens first, with p99, spike ratio and stdev spread where the server has them. No read credentials: a dashboard pointer, never empt

The latest upload from one install: per-route rows, per-screen diagnosis, summary and budgets where present. `section` takes a page section (incl. coverage) or `all`; an empty one

What is structurally wrong with this app, from the actions it traced: the route to fix first, single points of failure, pairs bouncing back and forth, call bursts, unexplained wait

One project's last 30 days: for each finished day, how many measurements arrived, typical and worst-case screen time, how many were rated poor, new crashes, and alerts opened and c

Check a Boosthis kit's FILES ON DISK are byte-perfect (same check over plain HTTPS: POST https://www.boosthis.com/api/kit/<runtime>/verify) - a pass proves the files, never that an

One project's Vigilance verdict and every watch behind it, worst first: what each watches, what it says now, and its evidence. Also what it cannot watch and why - nothing declared

A triage ordering: the worst-rated and slowest screens first, each with a one-line reason. No read credentials: a dashboard pointer, never empty. Read-only. More projects: `your_pr

Which Boosthis kits this project needs, from manifest file names visible in it - nothing downloaded or executed. The inventory step before boosthis_get_integration_kit, whose `runt