com.boosthis/boosthis · v1.0.0-alpha.82 · ecommerce
Boosthis is healthy: it completed an MCP handshake in 2323 ms and exposes 29 tools.
Read-only performance insights for your Boosthis projects: speed, crashes, traces, and fixes.
Endpoint: https://www.boosthis.com/mcp (streamable-http)
No repository listed · Website · JSON · Add to my inventory
| Users (last 30 days) | 0 |
| Handshake | Healthy |
| Auth needed | None |
| Tool count | 29 |
| Latency | 2323 ms |
| Last checked (UTC) | 2026-10-14T18:20:49.414Z |
| Checked (UTC) | Status | Latency | Error |
|---|---|---|---|
| 2026-10-14T18:20:49.414Z | Healthy | 2323 |
boosthis_list_rules | Every Boosthis performance rule available to this runtime, as ids and titles. The index for boosthis_get_rule. |
boosthis_get_rule | 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 what would change that. `counterparts` names the same idea's rule in other languages; also_applies_here names the other pl |
boosthis_get_integration_kit | 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> (project key as bearer). runtimes: every runtime this project has in ONE call, same key; runtime picks one, see enum. T |
boosthis_get_removal_kit | 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. Order is load-bearing - forget(), where a kit has one, only reaches the server while the key is set. |
boosthis_match_rules_for_code | 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_apply settles whether it really applies. |
boosthis_check_for_update | 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 release behind, a severity (cosmetic/recommended/important/security) and a recommendation. kit_download_url serves the whole |
boosthis_session_summary | Per-screen p50/p75/p95 and worst rating, worst screens first, with p99, spike ratio and stdev spread where the server has them. account_token: any project. No credentials: a dashboard pointer. Read-only. |
boosthis_what_should_i_look_at_next | A triage ordering: the worst-rated and slowest screens first, each with a one-line reason. account_token: any project. No credentials: a dashboard pointer. Read-only. |
boosthis_snapshot | 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 names its silence, not a clean result. account_token: any project. No credentials or none uploaded: a dashboard pointer. |
boosthis_crash_risk | Crashes this project recorded, one per crash, newest first, with readable frame where a build map resolves it, part, first/last seen, state, fix, relatedRules and applied-fix outcome, plus Stability and stabilityRules. Code-derived, never the raw message. install_id + read_token: one install; accoun |
boosthis_full_stack_trace | 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 responsible for the end-to-end time, not just the longest. Relative timings, code-defined labels only. A read token sees |
boosthis_connection_status | 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 last heard from, and what that state means. It answers "is it working?" without guessing - an install that registered but |
boosthis_which_kits | Which Boosthis kits this project needs, from published file and marker names plus folder labels you choose - anything else is dropped unread, and nothing is downloaded or executed. The inventory step before boosthis_get_integration_kit, whose `runtimes` list takes them all at once; also names what i |
boosthis_verify_kit_install | 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 anything is measured yet. The verdict names each missing, modified and unexpected path. Read-only; returns no credentials. |
boosthis_maintenance_mix | 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 poor rating. A project with too few fixed issues reports null rather than a made-up ratio. Read-only; returns no credentia |
boosthis_trend | One project's last 30 days: per finished day, measurements received, typical and worst-case screen time, poor ratings, new crashes, and alerts opened and closed - plus a verdict comparing the last 7 days with the 7 before. Days that reported nothing are no_data: unknown, never zero, never healthy. T |
boosthis_vigilance | 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 yet, no history, reporting off, kit too old, part never named - unknowns, never good news, each with its way out: a rhyt |
boosthis_jobs | 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 remembered, not watched. A rhythm is declared on the project's page, or by a kit that offers expectEvery(). Each carries i |
boosthis_exposure | 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. Read-only. |
boosthis_structure | 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 waits. Name a `route` (as recorded, e.g. GET /orders/:id) for that route's neighbourhood: what ran inside it, what ran it, w |
boosthis_alerts | 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 check is Muted. The reply states how many matched, so a trimmed list is never mistaken for the whole. Read-only: it cannot m |
boosthis_promises | 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 measure it: 'watched' names the exact line it is held to, 'remembered only' is a standing instruction with nothing measu |
boosthis_remember_promise | Saves what the developer wants kept true from now on as a promise on the project, surviving later sessions and other assistants. Restating one replaces it rather than duplicating it. Boosthis says what it reads the sentence to mean; nothing counts as measured until the developer confirms it on their |
boosthis_check_claim | 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, or outside what Boosthis measures. Boosthis picks the comparison window; one named in the sentence is not used. It catc |
boosthis_release_check | 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, did anything get slower, did new problems appear, did an old one come back, did a recorded promise pass its line, did th |
boosthis_ai_changes | 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_tell, in the promise vocabulary and refused for the same named reasons. cant_tell is the ordinary answer: thin evidence, |
boosthis_platform_allowances | What this project's hosting platform allows, confirmed on its own installs. One answer per fact: the time and memory limits a run can read, a live countdown, a processor clock that moves, whether work after the reply runs, each with its source and when it was confirmed. An unconfirmed fact says so a |
boosthis_project_diary | 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 entry says whether Boosthis measured it or was told it; a told one stays a claim however old. An empty stretch means not |
boosthis_record_change | 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. This one writes. |