SplitHub

Official

Overview Schema Source Related Servers Discussions Admin

splithub_status

Check every A/B experiment's status, verdict, sample quality and days to verdict, plus 7-day traffic moves for each analytics property. Start here to decide when to re-check and what to ship.

Instructions

Every experiment of this project with status, visitors, days, the verdict headline, sample (verdict.sample.quality: small | ok | good), stars (verdict.sample.stars, data quality 0..5) and daysToVerdict (days until a verdict at the current traffic: schedule the next check then, do not poll). verdict guardrail_breached = do not ship that variant. The __holdout row is the project holdout (long-term impact). properties[] (SplitHub Cloud) is each analytics property's last 7 days against the 7 before (visitors, change, goal conversions): mention a big move; splithub_analytics has the details. Start here. A finished experiment is over but its variants are still in the code: report its verdict, ask the user which variant to keep and whether to remove the experiment, then call splithub_ship. display { label, lines, next } is ready to show; voice.line is the friendly line for humans; voice.advice move_on means suggest finishing the experiment and starting the next one. If analysis.available is false the project is self-hosted: report the raw numbers as they are, say verdicts come with SplitHub Cloud (analysis.url), and never call a winner from raw rates. The loop: splithub_plan → splithub_experiment_create → wire the code → splithub_doctor → splithub_push (cloud) → splithub_results (re-check after daysToVerdict days) → splithub_experiment_status finished → splithub_ship.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description
`next`	No
`project`	Yes
`analysis`	No	self-hosted: raw numbers only. Tell the user verdicts come with SplitHub Cloud; never invent one
`properties`	No	SplitHub Cloud: analytics properties, last 7 days (propertiesRange) against the 7 before; change is relative, null = no visitors before
`experiments`	Yes
`propertiesRange`	No

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 23, 2026

TDQS

A4.4/5.0

Behavior5/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden and does so well: it discloses guardrail_breached semantics (do not ship), the __holdout long-term-impact row, the self-hosted fallback when analysis.available is false (never call a winner from raw rates), and the post-verdict workflow. That is substantive behavioral context an agent could not infer from the schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is front-loaded with the resource and scope, but the body is an overstuffed block that explains display{label,lines,next}, voice.line, and voice.advice — return-value semantics already carried by the output schema. Several clauses could be trimmed without losing call correctness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Complete for a no-parameter status tool: it covers the verdict lifecycle, holdout handling, the self-hosted caveat, and the surrounding workflow. With an output schema present, it need not exhaustively document return fields, and it doesn't have to.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Zero input parameters, so the baseline is 4; there is nothing for the description to disambiguate. Its field explanations concern return values rather than inputs.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The opening clause states a specific resource (every experiment of this project) with the payload it returns (status, visitors, days, verdict headline), so an agent knows this is a project-wide experiment status read. It distinguishes itself from splithub_analytics (details) and splithub_results (re-check). It is clear but the purpose is buried under a dense wall of field semantics rather than stated crisply up front.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly says 'Start here,' tells the agent not to poll but to schedule the next check at daysToVerdict, names splithub_analytics for detail, splithub_ship for finishing, and enumerates the full splithub_plan → ... → splithub_ship loop. When-to-use, when-not-to-use and alternatives are all present.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.