# Jaipilot

> Ship better Java with your coding agent.

- **Type:** MCP server
- **Install:** `agentstack add mcp-jaipilot-jaipilot`
- **Verified:** Yes — security-reviewed for prompt injection and unsafe behavior
- **Seller:** [JAIPilot](https://agentstack.voostack.com/s/jaipilot)
- **Installs:** 0
- **Category:** [Integrations](https://agentstack.voostack.com/c/integrations)
- **Latest version:** 0.1.0
- **License:** MIT
- **Upstream author:** [JAIPilot](https://github.com/JAIPilot)
- **Source:** https://github.com/JAIPilot/jaipilot
- **Website:** https://github.com/JAIPilot/jaipilot#install

## Install

```sh
agentstack add mcp-jaipilot-jaipilot
```

Requires the [AgentStack CLI](https://agentstack.voostack.com/docs/cli). Works with Claude Code, Cursor, and any MCP-compatible agent.

## About

# JAIPilot — **Ship better Java with your coding agent.**

JAIPilot helps Codex and Claude Code research maintainer intent, clean, test, review, safely upgrade
dependencies and JDKs, and optimize real Java repositories without drifting into unnecessary code
or unproved changes.

By default, your agent runs Java builds, tests, analysis, profiling, and benchmarks on a ready
remote Java machine whenever the task does not require laptop-only access or state.

JAIPilot does not replace your coding agent or add another AI. It gives your agent focused Java
workflows, remote compute, and one rule: **show evidence, not confidence.**

> **Further reading:**
> [Preventing agent drift: A guide to shipping serious code via vibe-coding](https://jaipilot.com/blog/preventing-agent-drift-serious-code-vibe-coding)
> explains the engineering principles behind JAIPilot's bounded, evidence-first workflows.

## Install and run

### Codex

```bash
codex mcp add jaipilot --url https://api.jaipilot.com/functions/v1/jaipilot/mcp
```

### Claude Code

```text
/plugin marketplace add JAIPilot/jaipilot
/plugin install jaipilot@jaipilot
```

### Example prompts

Open a Java repository and ask JAIPilot the same way you would ask a teammate. Each example shows
the skills JAIPilot selects and why that workflow helps.

#### Check whether an issue is worth picking up

**Prompt**

```text
Can you look into issue #184 and tell me whether I should work on it, or if someone is already
handling the same problem?
```

> **Skills and flow:** `jaipilot-maintainer-intent` researches the issue, related work, contribution
> rules, and code history before recommending whether to proceed, join existing work, ask, wait, or
> stop.
>
> **Why it helps:** You avoid duplicating another contributor's work or building a fix maintainers
> are unlikely to accept.

#### Get a branch ready to merge

**Prompt**

```text
I've finished the changes on this branch. Can you make sure they're ready to merge?
```

> **Skills and flow:** `jaipilot-optimize-java` coordinates bounded cleanup and improvement,
> `jaipilot-generate-tests` fills meaningful test gaps, and `jaipilot-review-diff` reviews the
> complete result. `jaipilot-fast-execution` and `jaipilot-remote-java` accelerate substantial
> verification when safe and useful.
>
> **Why it helps:** You get a smaller, reviewed change with missing tests added and the repository's
> real checks run before handoff.

#### Upgrade a framework and its dependencies

**Prompt**

```text
Can you upgrade this Spring Boot service and its outdated dependencies while keeping Java 17
support?
```

> **Skills and flow:** `jaipilot-maintainer-intent` first checks repository history, active or prior
> upgrade work, maintainer direction, and established compatibility constraints. The supported
> upgrade then uses `jaipilot-clean-java` to inventory and modernize the requested dependency and
> build paths. `jaipilot-openrewrite` is selected only when a repeated type-aware migration justifies
> it, followed by `jaipilot-generate-tests`, `jaipilot-review-diff`, `jaipilot-fast-execution`, and
> `jaipilot-remote-java` as applicable.
>
> **Why it helps:** The upgrade follows the repository's intended direction and avoids duplicating
> or conflicting with existing work. Accepted changes remain compatible, reversible, and verified
> instead of becoming a broad version bump with hidden runtime or transitive-dependency breakage.

#### Fix a failing dependency-bot update

**Prompt**

```text
Dependabot's Jackson update is failing CI. Can you figure out why and fix it?
```

> **Skills and flow:** `jaipilot-maintainer-intent` checks the bot PR, maintainer direction, related
> attempts, and the correct delivery path. The supported fix then uses `jaipilot-clean-java` or
> `jaipilot-openrewrite`, followed by `jaipilot-generate-tests` and `jaipilot-review-diff`.
> Substantial commands use `jaipilot-fast-execution` and `jaipilot-remote-java` when appropriate.
>
> **Why it helps:** The agent fixes the actual compatibility problem on the right branch instead of
> merely forcing the bot's version change through CI.

#### Add tests for a service change

**Prompt**

```text
Please add unit tests for my changes to OrderService, especially the validation and error cases.
```

> **Skills and flow:** `jaipilot-generate-tests` maps the requested classes and useful cases, creates
> and executes safely independent test-class work in parallel, and reports fresh configured coverage
> or mutation evidence. `jaipilot-fast-execution` and `jaipilot-remote-java` accelerate the test and
> verification work when applicable.
>
> **Why it helps:** You get behavior-focused tests across the complete requested scope, not hollow
> tests written only to inflate a coverage number.

#### Simplify a difficult module

**Prompt**

```text
This payments module has become hard to follow. Can you remove dead code and simplify it without
changing its behavior?
```

> **Skills and flow:** `jaipilot-clean-java` proves what can be removed or consolidated and keeps
> uncertain candidates. `jaipilot-generate-tests` covers concrete regression gaps, and
> `jaipilot-review-diff` checks the final patch. Verification routes through
> `jaipilot-fast-execution` and `jaipilot-remote-java` when useful.
>
> **Why it helps:** The module becomes easier to maintain without speculative deletion, silent API
> breakage, or a cleanup that only looks smaller.

#### Review work before opening a pull request

**Prompt**

```text
Can you review my current diff before I open a pull request?
```

> **Skills and flow:** `jaipilot-review-diff` reads the complete Java and build change, checks
> behavior, compatibility, unnecessary code, and missing proof, then runs the applicable repository
> checks via `jaipilot-fast-execution` and `jaipilot-remote-java` when appropriate.
>
> **Why it helps:** You get ranked, evidence-backed findings across the whole change rather than a
> shallow review of the most obvious file.

#### Speed up a slow endpoint

**Prompt**

```text
The /orders endpoint gets slow for large accounts. Can you find the bottleneck and improve it?
```

> **Skills and flow:** `jaipilot-optimize-java` bounds the change, `jaipilot-clean-java` profiles and
> tests measured hypotheses, `jaipilot-generate-tests` protects behavior, and
> `jaipilot-review-diff` checks the candidate. `jaipilot-fast-execution` and
> `jaipilot-remote-java` provide controlled execution and comparable measurements.
>
> **Why it helps:** The retained optimization is tied to a real bottleneck and repeatable evidence,
> not a plausible-looking micro-optimization or one noisy timing.

#### Run a slow build faster

**Prompt**

```text
Our full Gradle build takes about 20 minutes. Can you run it faster and tell me where the time goes?
```

> **Skills and flow:** `jaipilot-fast-execution` sizes safe batching and native build parallelism for
> the available resources. `jaipilot-remote-java` offloads the work when the repository does not need
> laptop-only services or state.
>
> **Why it helps:** You reduce wall time without skipping tests, weakening gates, or creating
> misleading results through unsafe concurrency.

Codex signs in through JAIPilot's OAuth consent and connects to one MCP URL. The server publishes
all eight Java skills through `skills/list`, `skills/get`, digest-verified `resources/read`, and
standard `mcp/skill` resources. Codex builds that promote remote skills can load only the selected
files and refresh them when their SHA-256 digests change. Other builds use the same server's
read-only `skill_get` fallback, which returns those exact versioned files instead of an older cloud
copy. Signing in creates no upload, workspace, or compute, and there is no Codex plugin or local
skill-copy installation. Claude Code retains its plugin path.

When remote execution is useful, your agent asks before uploading the current tracked and unignored
Git files. Approve the upload; if authentication is not already active, sign in when prompted. The
agent handles packaging, integrity checking, upload, execution, logs, and workspace deletion. You do
not create an archive, configure a VM, provide an API key, or copy files manually. `.git`, ignored
files, and remote edits are never transferred back automatically.

If packaging or upload cannot be verified, JAIPilot does not create the workspace. Your agent must
show the failing step instead of silently uploading a different source tree.

| **12.2–80.3% faster** | **61.3–62.5% faster** | **87.5–92.4% faster** | **8 → 2** SQL statements |
| --------------------- | --------------------- | --------------------- | ------------------------ |
| OTel lookup medians   | Micrometer merges     | Calcite JMH medians   | N+1 removed              |

## JAIPilot vs no JAIPilot

The original [Petclinic PR](https://github.com/skrcode/spring-framework-petclinic/pull/21) already
had a green build. JAIPilot reviewed that exact head and produced this
[companion change](https://github.com/skrcode/spring-framework-petclinic/pull/25):

| Metric                         |       Without JAIPilot | With JAIPilot | Outcome                         |
| ------------------------------ | ---------------------: | ------------: | ------------------------------- |
| Tests                          |                     75 |            85 | **+10 tests (+13.3%)**          |
| Changed-method line coverage   |              0/12 (0%) |  11/11 (100%) | **+100 percentage points**      |
| Changed-method branch coverage |               0/8 (0%) |    8/8 (100%) | **+100 percentage points**      |
| `Owner` class line coverage    |          22/53 (41.5%) | 33/51 (64.7%) | **+23.2 points with less code** |
| Production change              | Unused helper remained |   +2/-9 lines | **7 net lines removed**         |
| `Owner` methods                |                     16 |            15 | **1 unused method removed**     |
| `Owner` complexity             |                     25 |            24 | **4% lower**                    |
| Clean Maven verification       |           75/75 passed |  85/85 passed | **Both stayed green**           |

The important result is not simply “more tests.” Without JAIPilot, the build passed while the new
behavior had zero coverage and unused code remained. With JAIPilot, the same behavior stayed green,
the edge cases became executable tests, and production code became smaller.

The comparison uses the original PR head and JAIPilot's direct child commit, clean worktrees, the
same `./mvnw -q clean verify` command, and fresh JaCoCo 0.8.14 reports.

## Measured performance: Apache Calcite

On `skrcode/calcite` at exact commit
[`d3a5d8d`](https://github.com/skrcode/calcite/tree/d3a5d8d9e6713c5fd483810e1aa1f38652d2dd8d),
JAIPilot profiled Calcite's existing
`DefaultDirectedGraphBenchmark.removeAllVertices{10,50,90}Benchmark`. The 50% workload attributed
31.1% of runnable samples to `Collection.removeIf`: the implementation scanned the complete global
edge set once for every removed vertex.

The candidate changed two files (+28/-5), removed the repeated scans, and added behavior tests for
the majority-removal and self-loop paths. Lower JMH scores are better:

| Removed vertices | Baseline median (µs/op) | JAIPilot median (µs/op) | Improvement | Baseline p95 (µs/op) | JAIPilot p95 (µs/op) | Improvement |
| ---------------: | ----------------------: | ----------------------: | ----------: | -------------------: | -------------------: | ----------: |
|              10% |                  26.710 |                   2.029 |   **92.4%** |               27.142 |                2.439 |   **91.0%** |
|              50% |                  74.619 |                   9.140 |   **87.8%** |               87.245 |               14.993 |   **82.8%** |
|              90% |                  77.423 |                   9.677 |   **87.5%** |               89.514 |               10.052 |   **88.8%** |

Baseline and candidate ran on the same 4 CPU/8 GiB remote workspace with the same Temurin JDK 17,
built JMH jar, command, and workload. Each row contains 21 measured observations: seven forks with
three measured iterations per fork after warm-up. The identical focused command passed 15/15 tests
before and after the production edit. A fresh exact-SHA `:core:clean :core:check` then completed
16,644 tests with 0 failures and 155 skips, and the tested remote diff matched the local candidate
digest.

This is a controlled result for Calcite's existing graph-removal workloads, not a claim that every
Java workload becomes faster.

## Measured performance: OpenTelemetry Java

On `skrcode/opentelemetry-java` at exact commit
[`35636ae`](https://github.com/skrcode/opentelemetry-java/tree/35636aec8d3dc6706bb483bad92383fdd6012af0),
JAIPilot found that immutable attribute sets were sorted by key name during construction but still
used a full linear scan for every lookup. This matters at the default span limit of 128 attributes.

The [three-file draft change](https://github.com/skrcode/opentelemetry-java/pull/3) preserves the
small-set and first-four-entry fast path, then uses binary search for the rest. It also adds a
large-set behavior test and a repository-native JMH benchmark. Lower values are better:

| Lookup          | Baseline median (ns/op) | JAIPilot median (ns/op) | Improvement | Baseline p95 | JAIPilot p95 | Improvement |
| --------------- | ----------------------: | ----------------------: | ----------: | -----------: | ------------: | ----------: |
| First           |                   2.483 |                   2.179 |   **12.2%** |        2.637 |         2.272 |   **13.8%** |
| Middle          |                 169.124 |                  85.905 |   **49.2%** |      178.250 |        88.537 |   **50.3%** |
| Last            |                 346.195 |                  87.323 |   **74.8%** |      358.321 |        90.084 |   **74.9%** |
| Missing         |                 141.560 |                  69.552 |   **50.9%** |      150.321 |        74.261 |   **50.6%** |
| Last as `Value` |                 368.629 |                  72.684 |   **80.3%** |      387.467 |        78.087 |   **79.8%** |

Baseline and candidate ran in the same 4 CPU/8 GiB remote workspace with Temurin JDK 21, the same
JMH jar, command, warm-up, and workload. Each row has 21 observations. The new focused behavior test
passed before and after the production edit; a clean `:api:all:check` passed all 147 tasks including
Animal Sniffer, Checkstyle, Spotless, tests, and japicmp. The tested remote Git delta matched the
local candidate digest. The `Value` workload still allocates about 16 B/op; JAIPilot reports the
lookup-time win without claiming that allocation disappeared.

## Measured performance: Micrometer

On `skrcode/micrometer` at exact commit
[`22207bf`](https://github.com/skrcode/micrometer/tree/22207bf9ccc973a1b1bc3890b33645e53fb2e475),
JAIPilot found that adding or replacing one `Tag` or `KeyValue` went through temporary varargs and
iterable merge machinery even though the backing arrays were already sorted.

The [six-file draft change](https://github.com/skrcode/micrometer/pull/3) adds a bounded binary-search
merge for the single-value overloads, behavior tests, and four workloads in Micrometer's existing
JMH module:

| Replacement workload | Baseline median (ns/op) | JAIPilot median (ns/op) | Improvement | Baseline p95 | JAIPilot p95 | Improvement | Allocation |
| -------------------- | ----------------------: | ----------------------: | ----------: | -----------: | ------------: | ----------: | ---------: |
| `KeyValues.and`      |                  57.941 |                  22.449 |   **61.3%** |       63.554 |        23.487 |   **63.0%** | **136 → 104 B/op** |
| `Tags.and`           |                  58.968 |                  22.101 |   **62.5%** |       63.388 |        24.425 |   **61.5%** | **136 → 104 B/op** |

Single-value insertion reduced median allocation

…

## Source & license

This open-source MCP server is cataloged on AgentStack and links to its original source — we do not rehost the code.

- **Author:** [JAIPilot](https://github.com/JAIPilot)
- **Source:** [JAIPilot/jaipilot](https://github.com/JAIPilot/jaipilot)
- **License:** MIT
- **Homepage:** https://github.com/JAIPilot/jaipilot#install

Install and usage instructions live in the source repository linked above.

## Pricing

- **Free** — Free

## Security capabilities

Automated source analysis of v0.1.0 — what this tool can access:

- **Network access:** no
- **Filesystem access:** no
- **Shell / process execution:** no
- **Environment & secrets:** no
- **Dynamic code execution:** no

*"Yes" means the capability is present in the source — more access means more to trust, not that it is unsafe.*


## Versions

- **0.1.0** — security scan: passed — Imported from the upstream source.

## Links

- Listing page: https://agentstack.voostack.com/l/mcp-jaipilot-jaipilot
- Seller: https://agentstack.voostack.com/s/jaipilot
- Browse the marketplace: https://agentstack.voostack.com/browse

---
Listed on AgentStack — the marketplace for AI agent skills and MCP servers. Every listing is security-reviewed. Creators keep 70%.
