The full upstream README, mirrored here for reference. Install config, tool schemas, adoption signals, and an original overview live on the Google Jules MCP Server listing page.
If you're searching for a way to drive Google's Jules coding agent from Claude, Cursor, VS Code Copilot, or any other MCP client, this is that bridge. google-jules-mcp-server is an unofficial Model Context Protocol server that exposes the full Jules API (v1alpha) as 13 tools, so your assistant can create sessions, poll status, approve plans, and fetch the resulting pull request without you leaving the chat.
Developers running Jules across many repositories at once use it to let their AI assistant manage the whole async workflow: kick off a task, check on it later, and hand back a PR link when it's done, instead of switching to the Jules web app to babysit progress. Every response is validated at runtime through Zod schemas, so a drifted Jules API response fails loudly rather than silently breaking downstream code.
Model Context Protocol (MCP) server for Google's Jules AI coding agent — unofficial. Lets AI assistants like Claude create and manage asynchronous coding tasks through the Jules API v1alpha.
Jules is Google's AI coding agent that executes development tasks in isolated cloud VMs — generating code, fixing bugs, writing tests, updating dependencies, and refactoring across files. This server exposes the full Jules API surface as 13 MCP tools, covering repository sources, session lifecycle, and activity logs.
Tasks run asynchronously and typically complete in 5–60 minutes depending on complexity.
The server is organized by Jules resource domain rather than as one flat file:
Each resource module owns its own Zod schemas, a typed API client, and its MCP tool registrations. Zod schemas are the single source of truth: TypeScript types are inferred from them (z.infer), and every Jules API response is validated at runtime through core/http-client.ts — so a drifted API response fails loudly as a JulesResponseValidationError instead of silently producing undefineds downstream.
core/http-client.ts also centralizes retry-with-backoff (bounded, honors Retry-After) and a typed error hierarchy (JulesAuthError, JulesNotFoundError, JulesRateLimitError, JulesServerError, JulesClientError, JulesNetworkError, JulesResponseValidationError) so callers can distinguish failure modes programmatically rather than pattern-matching error strings.
The package is published on npm as google-jules-mcp-server. Most MCP clients can run it directly via npx — no separate install step needed, skip to step 2.
If you'd rather install it once instead of letting your client invoke npx on every launch:
This puts a google-jules-mcp binary on your PATH.
Building from source (for contributors, or to run unreleased changes):
Get a key from https://jules.google.com/settings#api. Set it directly in your MCP client's server config (see below) — that's the only place it needs to live for normal use.
If you're building from source and want to run npm run test:smoke or use .env for local scripts:
Claude Desktop — edit the config file (~/Library/Application Support/Claude/claude_desktop_config.json on macOS, %APPDATA%\Claude\claude_desktop_config.json on Windows):
Claude Code:
GitHub Copilot CLI:
Or edit ~/.copilot/mcp-config.json directly:
VS Code (Copilot Chat agent mode) — via terminal:
Or add to .vscode/mcp.json (workspace) or via MCP: Open User Configuration (user-level):
Cursor — add to ~/.cursor/mcp.json (global) or .cursor/mcp.json (project-only):
OpenAI Codex CLI:
Or edit ~/.codex/config.toml directly:
If you installed globally instead, replace "command": "npx", "args": ["-y", "google-jules-mcp-server"] with "command": "google-jules-mcp", "args": [] (and any npx -y google-jules-mcp-server in a CLI command above with just google-jules-mcp).
If you're running from a local clone instead, use "command": "node", "args": ["/absolute/path/to/google-jules-mcp-server/build/index.js"] (an absolute path to build/index.js).
Behind a corporate proxy — to support enterprise/corporate proxy setups without requiring any server-side config, the server automatically picks up proxy settings from the environment. The underlying EnvHttpProxyAgent (from undici) honours the standard HTTPS_PROXY, https_proxy, HTTP_PROXY, http_proxy, and NO_PROXY variables. What catches people out is that your MCP client spawns the server as a child process, so a variable exported in ~/.zshrc never reaches a GUI-launched app. Set it in the same env block as your API key:
Proxied requests are broken in 0.2.3 and earlier, where every call fails on a gzipped response the client never decoded. If you hit that, upgrade rather than reconfigure.
Restart your client after editing its config.
Ask your assistant: "List my Jules repositories." You should see the jules server connected with 16 tools available.
| Tool | Purpose |
|---|---|
jules_list_sources | List GitHub repositories connected to Jules |
jules_get_source | Get details (branches, visibility) for one connected repository |
jules_create_session | Start a new asynchronous coding task |
jules_list_sessions | List sessions and their states |
jules_list_stuck_sessions | List sessions awaiting plan approval or user feedback, following pagination automatically |
jules_get_status | Check a session's status and recent activity |
jules_send_message | Send a follow-up instruction to a running session |
jules_approve_plan | Approve a session's execution plan (when requirePlanApproval was set) |
jules_get_session_output | Retrieve the final output (PR details) of a completed session |
jules_delete_session | Permanently delete a session |
jules_archive_session | Archive a session without deleting it |
jules_unarchive_session | Restore an archived session |
jules_wait_for_session | Wait/poll for a session to reach a terminal state |
jules_execute_and_wait | Create a session and wait for it to complete in one call |
jules_list_activities | Get a session's detailed activity log |
jules_get_activity | Get a single activity by ID |
Everything these tools return lands in your assistant's context window, and an autonomous coding session can produce very long agent messages, progress descriptions and plans of hundreds of steps. The server therefore caps what it hands back, and says so in-band whenever it cuts something, so the assistant can decide whether to go and fetch the rest.
| Tool | Cap |
|---|---|
jules_get_status | 100 characters per activity in the recent-activity digest |
jules_list_activities | ~800 characters per entry, ~10,000 characters per page |
jules_get_activity | 8,000 characters |
A capped entry in jules_list_activities names the sessionId and activityId needed to re-request it through jules_get_activity, which renders the same activity under the much larger single-activity budget — ten times the room, though not unlimited. The 8,000-character cap is the end of the line: there is no continuation token or offset for a single activity, so a jules_get_activity response that reports omitted characters says so explicitly rather than pointing anywhere else. Re-requesting it returns the same truncation.
If whole entries had to be dropped to stay inside the page budget, the response ends with Showing 12 of 40 activities; the fix there is a smaller limit, not the page token, since the token resumes after the entire requested page and would skip the entries you didn't see.
Pagination itself is unaffected by any of this. jules_list_sources, jules_list_sessions and jules_list_activities all accept pageSize (or limit) and pageToken, and echo the API's nextPageToken back when more results exist.
jules_get_status.jules_list_activities.COMPLETED, via jules_get_session_output.Your assistant handles this polling loop automatically when asked to monitor a task.
If you don't want your LLM client burning tokens polling for stuck sessions (e.g. AWAITING_PLAN_APPROVAL or AWAITING_USER_FEEDBACK), you can run the standalone session watcher. It runs independently of any MCP client and posts a JSON payload to a webhook when a session gets stuck.
Required environment variables:
JULES_API_KEY: Your Jules API key.JULES_WATCH_WEBHOOK_URL: The URL to POST the JSON payload to.Optional environment variables:
JULES_WATCH_INTERVAL_SECONDS: The polling interval in seconds (default: 60).The payload structure:
Running the watcher:
Via npx:
Via local clone:
The watcher can also be run directly from a built checkout:
Example PM2 configuration (ecosystem.config.js):
Example systemd service (/etc/systemd/system/jules-watcher.service):
Example Docker one-liner:
Jules enforces task quotas based on subscription tier (Free: 15 daily / 3 concurrent; Google AI Pro: ~75 daily / 15 concurrent; Google AI Ultra: ~300 daily / 60 concurrent). Tasks count against quota even if they fail, on a rolling 24-hour window.
See CONTRIBUTING.md for the full setup and PR checklist, and CODE_OF_CONDUCT.md for community standards.
Unit tests use MSW to intercept HTTP at the network layer rather than mocking the client module directly — this means core/http-client.ts's own logic (auth headers, retry/backoff, error mapping, Retry-After parsing) is exercised by tests, not just the handlers built on top of it. Fixtures in tests/fixtures/ encode real, previously-verified Jules API response shapes as MSW mock bodies; because the real client parses them through the Zod schemas at test time, a schema/fixture mismatch fails the test suite immediately.
tests/smoke/live-api.smoke.test.ts is an opt-in, read-only smoke test against the real Jules API (jules_list_sources only, to avoid spending task quota). It's excluded from npm test and CI, and only runs via:
schemas.ts (Zod schema + inferred type).client.ts.format.ts and the handler + registerTool call to tools.ts.build/index.js exists (npm run build), and restart the client completely.env block.Unexpected token '', "..." is not valid JSON: you're behind a proxy on 0.2.3 or earlier, where gzipped responses reached the parser still compressed. Upgrade to the latest release.Network error connecting to Jules API: fetch failed, or calls that hang: if your network requires a proxy, the server isn't seeing it. Exporting it in your shell isn't enough — your client spawns the server as a child process, so HTTPS_PROXY belongs in that server's env block. See Behind a corporate proxy.Found a vulnerability? See SECURITY.md for how to report it privately.
https://jules.googleapis.com/v1alphaX-Goog-Api-Key headerMIT
See GitHub Releases — every published version gets an auto-generated release with notes grouped by change type.