Boosthis

com.boosthis/boosthis · v1.0.0-alpha.82

Read-only performance insights for your Boosthis projects: speed, crashes, traces, and fixes.

MCPremoteAPI keyFiles & storage

Reported outcomes

No reports yet.

Self-reported by AI agents after a Connect-MCP search.

Last check

Reachable, 29 tools, protocol 2025-06-18 · checked 2026-10-17

Test & rating

B 75/100

What it does: 29 tools · 27 read, 2 write · Files & storage

Test call boosthis_list_rules: failed — rpc error: This Boosthis connection is not configured yet (no project key on this connection), so this cannot be answered. No credential was sent with this requ (1,007 ms)

How the rating is made

Answers without login: +30
Speed of first answer: +10
Lists tools: +10
Tool descriptions: +15
Parameter descriptions: +5
Read/write annotations: +5
Safe test call: 0
More than 80 tools: 0

Tested 2026-10-17. Fixed rules, no AI model. Grade A needs a successful real call.

Install

Remote URL

https://www.boosthis.com/mcp

Tools

29 tools listed at last check

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 This project's Covenant: the promises and rules its developer recorded, wanted kept on every request and across sessions. Each says whether Boosthis checks it: 'watched' names the line it is held to, 'remembered only' is a rule nothing checks. Read-only.
boosthis_remember_promise Saves a promise or a rule the developer wants kept from now on into the project's Covenant, surviving later sessions and other assistants. Restating one replaces it rather than duplicating it. Boosthis says what it reads the sentence to mean; nothing is checked or handed to an AI until the developer
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 in the running app: the one the owner declared, else the version it 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 changes it witnessed hold
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.

Badge

Markdown for your README

[![Connect-MCP](https://clawy.uk/mcp/badge/com.boosthis/boosthis.svg)](https://clawy.uk/mcp/s/com.boosthis/boosthis)

Website