MCP Radar
MCP Server

Boosthis

com.boosthis/boosthis
Data & Analytics Developer Tools Public & reachable MCP 2026-07-28

What this MCP does

Provides read-only performance monitoring for applications, including speed, crashes, traces, alerts, trends, and release impact.

Capabilities

Tools

29 tools
boosthis_ai_changes
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, never that the change was fine. No score for any assistant, and none derivable. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_alerts
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 mark anything fixed, muted or dismissed, and returns no credentials.
Read only
Input schema 
{'type': 'object', 'required': ['account_token'], 'properties': {'limit': {'type': 'number', 'description': 'Rows to return (default 20, maximum 50).'}, 'search': {'type': 'string', 'description': 'Plain-text match on the alert wording, screen or check.'}, 'status': {'type': 'string', 'description': 'open | read | fixed | self_closed | closed | returned | dismissed | all. Default: open and returned.'}, 'account_token': {'type': 'string', 'description': 'Durable account token: dashboard "Connect AI once" card.'}}}
boosthis_check_claim
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 catches only a minority of wrong claims - the best measured result in this field is about one in six - and a vague claim is never caught at all. Read-only.
Read only
Input schema 
{'type': 'object', 'required': ['claim'], 'properties': {'claim': {'type': 'string', 'description': 'The sentence to check, up to 240 characters. One carrying a credential or personal details is refused.'}, 'account_token': {'type': 'string', 'description': "Optional, the developer's account token: a sentence the word match cannot place then gets a one-shot AI reading, which spends AI allowance."}}}
boosthis_check_for_update
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 kit. latest_version is authoritative only on the hosted MCP; a local stdio server answers with its own. Withheld reply? Same answer at GET https://www.boosthis.com/api/kit/<runtime>/update (project key as bearer).
Read only
Input schema 
{'type': 'object', 'properties': {'runtime': {'enum': ['rn', 'web', 'node', 'bun', 'python', 'java', 'go', 'php', 'dotnet', 'ruby', 'flutter', 'swift', 'kotlin', 'rust', 'elixir', 'edge'], 'type': 'string', 'description': "Required. Which runtime's kit to check; each kit has its own release line, so it is never guessed."}, 'repair_steps': {'type': 'boolean', 'description': 'Adds step-by-step repair text. Default false.'}, 'installed_version': {'type': 'string', 'description': 'The kit version installed here.'}}}
boosthis_connection_status
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 never measured anything reads differently from one that is quiet because the app is. Read-only; returns no credentials.
Read only
Input schema 
{'type': 'object', 'properties': {'repair_steps': {'type': 'boolean', 'description': 'Adds step-by-step repair text. Default false.'}}}
boosthis_crash_risk
Crash Risk
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 bucket and relatedRules, joined with the JS-thread Stability summary and stabilityRules. Signatures are code-derived, never the raw message: no user value is exposed. No credentials, or no crash recorded yet: a note. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_exposure
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.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_full_stack_trace
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 one install, account_token the whole chain. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {'trace_id': {'type': 'string', 'description': 'One trace by id (32 hex, from the trace page). Absent: the latest.'}, 'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_get_integration_kit
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. The reply carries file_list (path + sha256), version, kit_download_once_url; install_command adds typed commands. Writing the files is not the install: the kit is wired in, reporting switched on, and the app confirmed checked in.
Read only
Input schema 
{'type': 'object', 'properties': {'runtime': {'enum': ['rn', 'web', 'node', 'bun', 'python', 'java', 'go', 'php', 'dotnet', 'ruby', 'flutter', 'swift', 'kotlin', 'rust', 'elixir', 'edge'], 'type': 'string', 'description': 'Required. Which runtime kit to deliver. Boosthis names every runtime a project spans at https://www.boosthis.com/scan.'}, 'runtimes': {'type': 'array', 'items': {'type': 'string'}, 'description': "The normal route: every runtime this project has in one call - an address each, not a kit's files."}, 'files_page': {'type': 'number', 'description': 'Page of the by-value walk (guide parts, then files). Default 1; files_next_page names the next if any.'}, 'project_code': {'type': 'string', 'description': "The 8-character code from this description's lead, not the name two projects can share. Account token only."}, 'include_files': {'type': 'boolean', 'description': 'Send every kit file by value instead of the manifest, a page at a time. Only when no shell can be run.'}, 'install_command': {'type': 'boolean', 'description': 'Adds the typed download commands.'}}}
boosthis_get_removal_kit
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.
Read only
Input schema 
{'type': 'object', 'properties': {'runtime': {'enum': ['rn', 'web', 'node', 'bun', 'python', 'java', 'go', 'php', 'dotnet', 'ruby', 'flutter', 'swift', 'kotlin', 'rust', 'elixir', 'edge'], 'type': 'string', 'description': "Which runtime's install to remove; one per call. Naming none is refused, never defaulted."}, 'project_code': {'type': 'string', 'description': "The 8-character code from this description's lead, not the name two projects can share. Account token only."}}}
boosthis_get_rule
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 places in THIS project it applies, with a count.
Read only
Input schema 
{'type': 'object', 'required': ['id'], 'properties': {'id': {'type': 'string', 'description': "Rule id, e.g. 'split-driver-jitter'"}, 'skip': {'type': 'string', 'description': 'The `part` id of one also_applies_here entry that does not need doing. Recorded permanently: never raised again for this project.'}, 'route_label': {'type': 'string', 'description': 'The route or screen being worked on, so the places listed leave out the one already open.'}, 'skip_decided_by': {'enum': ['assistant', 'developer'], 'type': 'string', 'description': "Who decided to skip it. Use 'developer' when the person said so."}}}
boosthis_jobs
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 its rhythm, the lateness allowed and its last run. Only names and timings, never arguments or data; Boosthis never runs or schedules a job. Read-only.
Read only
Input schema 
{'type': 'object', 'required': ['install_id', 'read_token'], 'properties': {'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_list_rules
List Rules
Every Boosthis performance rule available to this runtime, as ids and titles. The index for boosthis_get_rule.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_maintenance_mix
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 credentials.
Read only
Input schema 
{'type': 'object', 'required': ['account_token'], 'properties': {'window_days': {'type': 'number', 'description': "Only count fixes first seen in the last N days (default 90; 0 or 'all' = all time)."}, 'account_token': {'type': 'string', 'description': 'Durable account token: dashboard "Connect AI once" card.'}}}
boosthis_match_rules_for_code
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.
Read only
Input schema 
{'type': 'object', 'required': ['code'], 'properties': {'code': {'type': 'string'}}}
boosthis_platform_allowances
Platform Allowances
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 moves, whether work after the reply runs, each with its source and when it was confirmed. An unconfirmed fact says so and carries no answer - never a limit, never a zero. Read from this project's own installs. A phone or browser reads as a device family with no allowance facts yet; an unrecognised host reads unknown, never production. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_project_diary
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 nothing was recorded, never that all was well. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_promises
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 measuring it. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {}}
boosthis_record_change
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.
Input schema 
{'type': 'object', 'required': ['account_token'], 'properties': {'done': {'type': 'string', 'description': 'The name from intend, now finished.'}, 'intend': {'type': 'string', 'description': 'One thing you are starting - a route as the app registers it, or a migration, a fix.'}, 'subject': {'type': 'string', 'description': 'The screen, endpoint or job it touched.'}, 'summary': {'type': 'string', 'description': 'What you changed, in one or two sentences (max 300 characters).'}, 'account_token': {'type': 'string', 'description': 'Durable account token: dashboard "Connect AI once" card.'}}}
boosthis_release_check
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 the changes Boosthis witnessed hold up. Each carries its numbers and window; a part without enough evidence says so, and when it could answer. No combined score. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {'runtime': {'type': 'string', 'description': 'Which runtime to read, e.g. node, web, rn or py. Omit: whichever reported most recently.'}, 'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}}}
boosthis_remember_promise
Remember Promise
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 than duplicating it. Boosthis says what it reads the sentence to mean; nothing counts as measured until the developer confirms it on their project page. Passwords, keys and personal details are refused, not stored. This one writes.
Idempotent
Input schema 
{'type': 'object', 'required': ['promise', 'account_token'], 'properties': {'promise': {'type': 'string', 'description': "The standing instruction, in the developer's own plain words (up to 240 characters). E.g. the list screen stays under one second."}, 'account_token': {'type': 'string', 'description': 'Durable account token: dashboard "Connect AI once" card.'}}}
boosthis_session_summary
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. No read credentials: a dashboard pointer, never empty. Read-only. More projects: `your_projects`.
Read only
Input schema 
{'type': 'object', 'properties': {'project': {'type': 'string', 'description': "Dashboard name, 'name (runtime)' or install id; needs account_token. Default: newest reporter."}, 'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_snapshot
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. No credentials or none uploaded: a dashboard pointer. Read-only. More projects: `your_projects`.
Read only
Input schema 
{'type': 'object', 'properties': {'project': {'type': 'string', 'description': "Dashboard name, 'name (runtime)' or install id; needs account_token. Default: newest reporter."}, 'section': {'type': 'string'}, 'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_structure
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, which flows include it, is it a single point of failure. Each finding reads measured (real call links) or inferred (timing alone). `view`:"map" instead lists the parts observed running, their states and the calls between them, worst first. Every answer states how many traced actions it read, over what window; too few says so, never a clean bill of health. Read-only.
Read only
Input schema 
{'type': 'object', 'properties': {'view': {'type': 'string'}, 'route': {'type': 'string'}}}
boosthis_trend
Trend
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 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. Too few measurements gives not-enough-data, not a guess. Read-only; returns no credentials.
Read only
Input schema 
{'type': 'object', 'required': ['install_id', 'read_token'], 'properties': {'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_verify_kit_install
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 the exact missing, modified and unexpected paths, each with expected sha256. Read-only; returns no credentials.
Read only
Input schema 
{'type': 'object', 'required': ['files'], 'properties': {'files': {'type': 'array', 'items': {'type': 'object', 'required': ['path', 'sha256'], 'properties': {'path': {'type': 'string'}, 'sha256': {'type': 'string'}}}, 'description': 'Each written kit file, sha256 lowercase-hex of its exact contents.'}, 'runtime': {'enum': ['rn', 'web', 'node', 'bun', 'python', 'java', 'go', 'php', 'dotnet', 'ruby', 'flutter', 'swift', 'kotlin', 'rust', 'elixir', 'edge'], 'type': 'string', 'description': "Which runtime's kit to verify against. Required, never guessed."}, 'repair_steps': {'type': 'boolean', 'description': 'Adds step-by-step repair text. Default false.'}, 'installed_version': {'type': 'string', 'description': 'The kit version installed here.'}}}
boosthis_vigilance
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 rhythm is declared by expectEvery() or on the project's page, never from here. No score. Read-only, no credentials, never counted as an AI read.
Read only
Input schema 
{'type': 'object', 'required': ['install_id', 'read_token'], 'properties': {'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_what_should_i_look_at_next
What Should I Look At Next
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_projects`.
Read only
Input schema 
{'type': 'object', 'properties': {'limit': {'type': 'integer', 'default': 5, 'maximum': 50, 'minimum': 1}, 'project': {'type': 'string', 'description': "Dashboard name, 'name (runtime)' or install id; needs account_token. Default: newest reporter."}, 'install_id': {'type': 'string', 'description': 'Install id (Connect AI card).'}, 'read_token': {'type': 'string', 'description': 'Read-only token, same card.'}}}
boosthis_which_kits
Which Kits
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 `runtimes` list takes them all at once. Names the kit each file implies, what is already registered under this key, and the files whose contents decide one. With no arguments: the signal table.
Read only
Input schema 
{'type': 'object', 'properties': {'files': {'type': 'array', 'items': {'type': 'object', 'required': ['path'], 'properties': {'path': {'type': 'string'}, 'dependencies': {'type': 'array', 'items': {'type': 'string'}}}}, 'description': 'Manifest files visible in the project: path (project-relative, e.g. apps/api/package.json) and dependencies (names read out of it, where contents decide the kit - empty means none found, omitted means not read).'}}}
History

Recent tool changes

Changed
boosthis_alerts
Oct. 1, 2026, 2:52 a.m.
Changed
boosthis_record_change
Sept. 29, 2026, 3:01 a.m.
Changed
boosthis_verify_kit_install
Sept. 29, 2026, 3:01 a.m.
Changed
boosthis_which_kits
Sept. 29, 2026, 3:01 a.m.
Changed
boosthis_get_rule
Sept. 29, 2026, 3:01 a.m.
Changed
boosthis_which_kits
Sept. 25, 2026, 3:01 a.m.
Changed
boosthis_snapshot
Sept. 25, 2026, 3:01 a.m.
Changed
boosthis_get_integration_kit
Sept. 25, 2026, 3:01 a.m.
Changed
boosthis_jobs
Sept. 19, 2026, 2:50 a.m.
Changed
boosthis_vigilance
Sept. 19, 2026, 2:50 a.m.
Added
boosthis_record_change
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_project_diary
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_platform_allowances
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_ai_changes
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_release_check
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_check_claim
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_remember_promise
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_promises
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_alerts
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_structure
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_exposure
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_jobs
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_vigilance
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_trend
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_maintenance_mix
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_verify_kit_install
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_which_kits
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_connection_status
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_full_stack_trace
Sept. 17, 2026, 12:34 p.m.
Added
boosthis_crash_risk
Sept. 17, 2026, 12:34 p.m.
Discover

Similar MCP servers

Thousand API

com.thousand-api/thousand-api

Provides deterministic data conversion, validation, JSON transformation, statistical calculations, date and schedule utilities, i…

HubVibe: Pay-per-Call Tools for AI Agents: Web Search, Email Verify, KYC, Stocks, Crypto, News, Data

io.github.Its-fortunatefolly/hubvibe

Offers paid utilities for web audits, HTTP fetching and extraction, BigQuery analysis, LLM processing, code execution, blockchain…

Blixtworks

com.blixtworks.www/tools

Offers pay-per-call utilities for text, image processing and analysis, data conversion, validation, web inspection, cryptography,…

Qiniso

io.github.qinisolabs/qiniso

Provides deterministic formatting, parsing, holiday and tax lookups, address handling, and checksum or structure validation for i…

Scalix Cloud

world.scalix/cloud

Provides managed databases, SQL tools, container builds, persistent Linux machines, domains, scheduled functions, storage, and pr…

RationalBloks

io.github.rationalbloks/rationalbloks-mcp

Creates, deploys, manages, and searches schema-based REST API projects and Neo4j knowledge graphs across staging and production e…

RationalBloks

com.rationalbloks/mcp

Creates, deploys, manages, and queries REST API and Neo4j graph projects from JSON schemas, including graph data modeling, versio…

Wakatime

io.github.pipeworx-io/wakatime

Provides WakaTime coding-activity data, including durations, projects, commits, goals, heartbeats, editor usage, leaders, and use…