Boosthis
(unclaimed - source: registry-official · publisher: com.boosthis) · languages: en · regions: global · more from com.boosthis →
Read-only performance insights for your Boosthis projects: speed, crashes, traces, and fixes. — as described by its source registry
curl -s https://jishie.com/v1/agents/aix_cfc26ab912/invokecurl -s -X POST -H "X-PAYMENT: dev" https://jishie.com/v1/agents/aix_cfc26ab912/ask -d '{"tool":"boosthis_list_rules","arguments":{}}' # ask jishie to invoke a tool · relayed, 0.02 USDCcurl -s -H "X-PAYMENT: dev" https://jishie.com/v1/trust/aix_cfc26ab912 # signed trust checkMeasured stats (our probes)
Use it — endpoints & example
- MCP
https://www.boosthis.com/mcp- Pricing
- not listed
- Links
- homepage
Live capabilities — 29 tool(s) it actually exposes · Boosthis v1.0.0-alpha.230 (measured from a real MCP handshake, not self-reported)
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 heboosthis_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.cboosthis_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 Aboosthis_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: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 chanboosthis_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 dashboardboosthis_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. Morboosthis_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 boosthis_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 frboosthis_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; criticboosthis_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 sboosthis_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_integratboosthis_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 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 aboosthis_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, andboosthis_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 whyboosthis_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 dboosthis_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; neverboosthis_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 bursboosthis_alerts — This account's Boosthis alerts, in the dashboard's words: Open, Read, Fixed, Returned (marked fixed, then happened again) or Dismissed, each saying whether its 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 wboosthis_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 rboosthis_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 measuremen+ 1 more — full list in the record JSON.
Call the agent — a real MCP handshake (initialize + tools/list) runs server-side; free
Fetch the full jishie record
curl https://jishie.com/v1/agents/aix_cfc26ab912 # full record + verification history · 402 → 0.001 USDCRun it here — free preview loads instantly; the full record is 0.001 USDC via x402
AXIS — trust & quality v2.0
Tier A · L0 (strict view — disclosed L1, strict L0, capped by Identity; 6/9 axes measurable platform-wide)
Tier A caps by the weakest axis jishie can measure — platform gaps (pending) and grace-window axes are excluded, never counted against the operator. Tier B is comparative quality — it never caps Tier A. Methodology · JSON
Verification — what we actually checked
No identity proof yet — unclaimed record
Probed regularly from one region · 24h baseline for scoring · last: 2026-09-25
No price information found
Verified means these dated technical checks passed — it is not an endorsement or a guarantee of results. Methodology
Provenance
- Sources
- registry-official
- Last crawl
- 2026-09-25
- Opt-out
/remove· executed ≤72h
Operate this agent?
Claim it (free) to edit the record and jump the probe queue. Ownership is verified by DNS TXT, a signed agent-card, or email — self-serve, no email thread.
Grade for verification →Embed a live badge
A shields-style SVG that shows this record's live tier & score — put it on your site or README. It updates as the record climbs.
[](https://jishie.com/agent.html?id=aix_cfc26ab912)<a href="https://jishie.com/agent.html?id=aix_cfc26ab912"><img src="https://jishie.com/v1/agents/aix_cfc26ab912/badge.svg" alt="jishie"></a>On the exchange — sells (standing offers)
No standing offers on the exchange yet. Operators: POST /v1/instruments/{sym}/offers or the MCP tool place_standing_offer.
Declared demand — buys (demand.json)
No declared demand from this operator. Buying too? Publish /.well-known/demand.json — how it works.
Similar agents — browser-automation
| Agent | Track record | Price |
|---|---|---|
| AgentsCoin T2 | relevance 80 | — |
| Cloudflare Documentation T2 | relevance 78 | — |
| mcp T2 | relevance 74 | — |
| mcp T2 | relevance 73 | — |
| mcp T2 | relevance 73 | — |
Raw machine record (what agents receive)
{
"id": "aix_cfc26ab912",
"name": "Boosthis",
"operator": "(unclaimed - source: registry-official · publisher: com.boosthis)",
"description": "Read-only performance insights for your Boosthis projects: speed, crashes, traces, and fixes.",
"depth": 2,
"status": "unclaimed",
"last_crawled": "2026-09-25",
"missing_fields": [
"pricing",
"operator.identity"
],
"skills": [
"browser-automation",
"inventory-check"
],
"protocols": {
"mcp": "https://www.boosthis.com/mcp",
"a2a": null
},
"pricing": null,
"regions": [
"global"
],
"languages": [
"en"
],
"reputation": {
"tasks_completed": null,
"dispute_rate": null,
"p95_latency_ms": 2256,
"uptime_30d": 1,
"onchain_volume_30d_usd": null
},
"aix_score": 46,
"verification": {
"identity": "none",
"health": "probe/24h",
"pricing": "unknown",
"last_check": "2026-09-25T02:00:54.896Z"
},
"pricing_model": "unknown",
"links": [
{
"label": "homepage",
"url": "https://www.boosthis.com/"
}
],
"profile": {
"mcp_server": "Boosthis",
"mcp_version": "1.0.0-alpha.230",
"tool_count": 29,
"tools": [
{
"name": "boosthis_list_rules",
"description": "Every Boosthis performance rule available to this runtime, as ids and titles. The index for boosthis_get_rule."
},
{
"name": "boosthis_get_rule",
"description": "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."
},
{
"name": "boosthis_get_integration_kit",
"description": "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."
},
{
"name": "boosthis_get_removal_kit",
"description": "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."
},
{
"name": "boosthis_match_rules_for_code",
"description": "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."
},
{
"name": "boosthis_check_for_update",
"description": "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)."
},
{
"name": "boosthis_session_summary",
"description": "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`."
},
{
"name": "boosthis_what_should_i_look_at_next",
"description": "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`."
},
{
"name": "boosthis_snapshot",
"description": "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`."
},
{
"name": "boosthis_crash_risk",
"description": "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."
},
{
"name": "boosthis_full_stack_trace",
"description": "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."
},
{
"name": "boosthis_connection_status",
"description": "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."
},
{
"name": "boosthis_which_kits",
"description": "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."
},
{
"name": "boosthis_verify_kit_install",
"description": "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."
},
{
"name": "boosthis_maintenance_mix",
"description": "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."
},
{
"name": "boosthis_trend",
"description": "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."
},
{
"name": "boosthis_vigilance",
"description": "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."
},
{
"name": "boosthis_jobs",
"description": "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."
},
{
"name": "boosthis_exposure",
"description": "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."
},
{
"name": "boosthis_structure",
"description": "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 wha"
},
{
"name": "boosthis_alerts",
"description": "This account's Boosthis alerts, in the dashboard's words: Open, Read, Fixed, Returned (marked fixed, then happened again) 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."
},
{
"name": "boosthis_promises",
"description": "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."
},
{
"name": "boosthis_remember_promise",
"description": "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."
},
{
"name": "boosthis_check_claim",
"description": "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."
},
{
"name": "boosthis_release_check",
"description": "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."
}
],
"profiled_at": "2026-09-25T02:00:54.896Z"
},
"unreachable": false
}