Glubean

Glubean is a developer-and-agent-first API verification system that turns code-authored checks into structured evidence your team can read.

Write API tests, contracts, workflows, browser checks, and load plans in TypeScript. Run them locally or in CI. Upload the run when it matters, and the webapp turns that execution into Target health, failure objects, performance trends, contract coverage, docs, and agent-readable context.


developer or agent writes in code -> run locally or CI -> upload evidence -> inspect with team

Key ideas

Skill first: install glubean/skill, then let the agent guide setup.
Verification project: Glubean is e2e, so tests usually live beside the app, not inside the unit-test setup.
SDK + runner + CLI + MCP: the SDK authors checks, the runner executes them, the CLI runs/uploads, and MCP gives agents access.
Evidence, not logs: runs keep requests, responses, assertions, traces, load metrics, and failures in a team-readable shape.
Executable contracts: a contract case is itself a runnable test, and it can also project to Specifications, OpenAPI, Explore validation, APIs overlays, and Portals.
Two agents: your IDE agent writes and runs source-aware checks; the Glubean webapp Agent explains current pages, evidence, docs, performance, and failures.

Developer and agent workflow

Start here if you own the API code, test suite, CI pipeline, release gate, or the coding agent working inside that repo.

Install the Glubean skill so your agent knows the product and SDK patterns:
```
npx skills add glubean/skill
```
Ask the agent to set up a Glubean verification project. It should inspect your repo and decide whether to create a separate project or reuse an existing one, then guide or apply the needed SDK, runner, CLI, MCP, and config changes.
Configure shared runtime context: auth, base URLs, variables, and secrets.
Write the smallest useful check:
- test() for runtime behavior
- contract.http.with() for an executable endpoint promise
- workflow() for a multi-step lifecycle
- loadScenario() for performance under concurrency
- @glubean/browser when UI evidence belongs beside API evidence
Run locally with glubean run or through MCP from your coding agent.
Upload meaningful runs to a Target so the team can inspect the evidence.

Useful next pages:

Manual installs are still documented, but they are the fallback. The intended path is skill first, then let the agent adapt setup to the project in front of it.

Glubean is end-to-end verification. In most teams, Glubean tests live in their own verification project rather than inside the app repo’s unit-test setup. That keeps real service targets, credentials, upload settings, contract projections, and CI gates separate from Vite/Jest/Vitest-style tests.

Team workflow

Start here if you do not want to write TypeScript every day, but you need to understand API behavior.

Open a Target to inspect uploaded runs, failures, latency, and regressions.
Open Specifications to read the API promises synced from code.
Use Explore to send requests, build flows, and validate responses.
Use APIs & Portals when the team needs curated docs.
Ask the Agent about the current view when the evidence is hard to parse.

Useful next pages:

The five words to learn first

Word	Plain meaning
Test	Code that checks what the API actually did in one run.
Contract	A named executable promise for an API, browser journey, or plugin protocol. It runs as a test and can also generate docs.
Workflow	A contract-aware multi-step scenario, such as create -> pay -> webhook -> refund.
Load	A repeatable pressure plan that measures latency, throughput, errors, and SLA gates under concurrency.
Browser	UI or end-to-end evidence captured beside API evidence when the user journey crosses the browser.

For the product map, read How Glubean Works. For a deeper term glossary, read Core Concepts.

Where to go after the overview

If the mental model is new, read Why Glubean and How Glubean Works before installing anything.

If you are ready to try it, go to Start Here. The default path is agent first: install the Glubean skill, let your IDE agent inspect the repo, create or reuse a verification project, and run the first small check.

If you are evaluating the webapp, start with Targets & Runs and Specifications. Those two surfaces show the core loop: executable checks run outside Cloud, then Cloud makes the evidence and API promises readable for the team.