Provides tools for interacting with Google Jules coding sessions through the Jules REST API, including listing connected repositories and sessions, starting sessions, checking status and activity, sending follow-up instructions, approving plans, and retrieving outputs and pull-request links.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@jules-mcp Start a Jules coding session on acme/app to fix the login race condition, requiring plan approval."
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A small Model Context Protocol (MCP) bridge that lets Codex interact with Google Jules through the official Jules REST API.
Expose Jules as a set of MCP tools so Codex can:
discover Jules-connected GitHub repositories
start Jules coding sessions
inspect session state and activity
send follow-up instructions or answer Jules questions
approve plans explicitly
retrieve completed outputs and pull-request links
The Jules API is currently v1alpha, so this project keeps all Jules-specific HTTP details behind a small client layer.
Related MCP server: Jules MCP Server
JULES_API_KEY is read from the environment and must never be committed.
New sessions require plan approval by default.
Automatic PR creation is opt-in per session.
Python 3.10+
uv or another Python package manager
A Jules API key from Jules settings
At least one GitHub repository connected to Jules
Codex with MCP client support
git clone https://github.com/jbolt25/jules-mcp.git
cd jules-mcp
uv syncSet the Jules API key.
PowerShell:
$env:JULES_API_KEY="your-key-here"bash/zsh:
export JULES_API_KEY="your-key-here"Run the server directly:
uv run jules-mcpThe default transport is stdio, which is what Codex expects for a local MCP server.
Add a server entry to ~/.codex/config.toml and replace the working directory with the local clone path:
[mcp_servers.jules]
command = "uv"
args = ["run", "jules-mcp"]
cwd = "C:\\path\\to\\jules-mcp"
env_vars = ["JULES_API_KEY"]Then restart Codex and verify the Jules MCP tools are visible.
The initial server exposes:
jules_list_sources
jules_list_sessions
jules_start
jules_status
jules_activity
jules_send
jules_approve_plan
jules_result
Example intent from Codex:
Start a Jules session on
owner/repofrommainto fix the BACnet scanner race condition. Require plan approval and do not auto-create a PR.
When Jules reaches a state that requires feedback, Codex can read the activity stream, present the question to the user, and send the response back through jules_send.
uv sync --extra dev
uv run mcp dev src/jules_mcp/server.pyUser
|
v
Codex
|
| MCP / stdio
v
jules-mcp
|
| HTTPS + x-goog-api-key
v
Jules REST API
|
v
Jules coding sessionRead Jules session activities, including plans, messages, and progress.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the disclosure burden. It does state the operation is a read and enumerates the types of content returned, which is useful. However, it does not explain pagination behavior around page_size, ordering, or how missing/invalid sessions are handled; the output schema presumably covers the return shape.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single focused sentence that front-loads the core purpose and then adds relevant content categories without filler. Every phrase earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The presence of an output schema reduces the need to describe return values, and the tool is a relatively simple read operation. Still, usage guidance and parameter semantics are thin, so the description is minimally adequate rather than complete for confident invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not mention session_id or page_size at all. The phrase 'session activities' only faintly implies session_id, while page_size semantics remain entirely unexplained. This is a meaningful gap because there are no structured parameter descriptions to fall back on.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Read') and a concrete resource ('Jules session activities'), and lists the content categories: plans, messages, and progress. This clearly differentiates it from siblings like jules_list_sessions, jules_status, and jules_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies that the tool is for reading a session's activity feed, but it gives no explicit guidance on when to choose this over siblings like jules_result or jules_status. There are no exclusions or alternative routing cues.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicitly approve a pending Jules plan.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states that a plan is approved but does not explain side effects, reversibility, required permissions, or whether repeated approval is safe. For a state-changing action, this is a notable transparency gap.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is eight words and gets straight to the point. There is no filler or redundant information; every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Although an output schema exists, the description lacks essential workflow context: when a plan becomes pending, what approval unlocks, and how this relates to sibling tools like jules_start or jules_status. The definition is minimally viable but leaves important behavioral and sequencing questions unanswered.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has one parameter, session_id, with zero description coverage, and the description does not mention it at all. The parameter name is somewhat self-explanatory, but the description fails to clarify what session_id refers to or how it relates to the pending plan.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('approve') and resource ('pending Jules plan'), making the action unmistakable. It clearly distinguishes this tool from its siblings like jules_start or jules_send, none of which perform approval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is given about when approval is appropriate, what makes a plan eligible for approval, or what happens if the plan is not pending. There are no exclusions or alternatives mentioned, so the agent must infer usage entirely from the one-line description.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent Jules sessions.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It implies a read-only listing but does not state ordering, recency window, pagination behavior, or any side effects. This is minimal disclosure.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence with no filler words. It is front-loaded and appropriately sized for a simple listing tool, though it could include more detail without becoming bloated.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and an output schema, which covers return values. However, the description lacks usage guidance and behavioral details, making it adequate but not fully complete for an agent with no other context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0% and the description does not mention page_size at all. The parameter name and default value are somewhat self-explanatory, but the description adds no semantic meaning and fails to compensate for the low schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states a specific action ('List') and resource ('sessions'), and adds the scoping qualifier 'recent.' It is enough to distinguish it from sibling tools like jules_list_sources, though it does not explain what a session is.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives, prerequisites, or contexts where this tool should or should not be used. The description simply states what it does without any usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List repositories connected to the authenticated Jules account.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It discloses that this is a listing operation tied to an authenticated account, implying read-only behavior. However, it does not mention pagination, result limits, or any other behavioral characteristics beyond the basic list action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single clear sentence with no filler or redundant phrasing. The core action and target resource are front-loaded, making it easy to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple, read-only listing tool with one optional parameter and an output schema available, the description is mostly sufficient. The main gap is the lack of usage guidance and pagination context, but the basic invocation intent is clear.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage and the only parameter, page_size, is not explained in the description at all. While the parameter name and default value are somewhat self-explanatory, the description adds no meaning beyond the schema and fails to compensate for the lack of parameter documentation.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb ('List') and resource ('repositories connected to the authenticated Jules account'), making the tool's function immediately clear. It also differentiates from the sibling jules_list_sessions by specifying repositories rather than sessions, so an agent can distinguish them without opening schemas.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
No guidance is provided about when to use this tool versus alternatives like jules_list_sessions or jules_activity. The description only states what the tool does, leaving the agent to infer the appropriate context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve the full session object, including outputs when completed.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the behavioral burden. It discloses that this is a retrieval operation and that outputs are only included after completion, but it does not explain behavior for incomplete sessions, such as whether it returns a partial object, errors, or waits for completion.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence with no filler. It front-loads the core action and includes the most important condition ('when completed') efficiently.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple, has one required parameter, and an output schema exists, so the description does not need to detail return structure. However, it omits guidance on how an agent should handle or detect an incomplete session, and it does not reference how to obtain a valid session_id from sibling tools like jules_start or jules_status.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, and the description does not explain session_id's format, origin, or relationship to the returned session object. The parameter is simple and self-descriptive, but the description adds little semantic value beyond what the schema already shows.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific action and resource: 'Retrieve the full session object, including outputs when completed.' It is clear that this tool returns session data and outputs, which helps distinguish it from status-only or listing tools, though it does not explicitly name a sibling for differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'when completed' implies the tool should be called after a session finishes, but there is no explicit guidance on when to use this tool versus jules_status, jules_activity, or jules_list_sessions. No alternatives or exclusions are stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send feedback, an answer, or additional instructions to an active Jules session.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | ||
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden for behavioral disclosure. It only states that a message is sent to an active session, without explaining whether the session must be waiting for input, whether sending mutates session state, or what happens if the session is inactive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler or repetition. Every phrase contributes meaning: the action, the content, and the target.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The core semantics for a simple two-parameter send tool are covered, and an output schema exists, so return-value documentation is not the description's job. However, the description leaves behavioral edge cases unexplained, such as session liveness requirements and the relationship to jules_approve_plan.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It loosely maps 'active Jules session' to session_id and 'feedback, an answer, or additional instructions' to message, but it does not explain how to obtain a valid session_id or message formatting expectations. The parameter names are self-evident, so this is adequate but not rich.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('Send') with a clear target ('active Jules session') and enumerates the kinds of content ('feedback, an answer, or additional instructions'). This makes it easy to distinguish from sibling tools like jules_start, jules_status, or jules_result.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The phrase 'to an active Jules session' implies this should be used only after a session is running, which gives some contextual guidance. However, it does not explicitly say when not to use it or route to alternatives such as jules_approve_plan for plan approvals.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Start a Jules coding session. Plan approval defaults to required.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| branch | No | ||
| prompt | Yes | ||
| source | No | ||
| auto_create_pr | No | ||
| require_plan_approval | No |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It only states that plan approval defaults to required, which is already visible in the schema default; it does not disclose side effects such as whether a branch is checked out, whether a background process starts, or what permissions are needed.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely compact and front-loaded, with the core action stated immediately. The second sentence adds a useful behavioral note, though it is somewhat redundant with the schema. It earns a high score for efficiency, though it sacrifices completeness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a tool with six parameters, one required, and no annotations, the description is too sparse to support correct invocation. An agent cannot determine what to put in 'prompt', how 'source' or 'branch' should be used, or what side effects starting a session will have. The output schema helps with return values but does not compensate for the missing input guidance.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 0% schema description coverage, the description needed to explain the six parameters, especially the required 'prompt'. It only mentions the plan approval default, which duplicates the schema's default value. The meaning of 'branch', 'source', 'title', and 'auto_create_pr' remains completely unexplained.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description states a specific verb and resource: 'Start a Jules coding session.' This clearly distinguishes the tool from all siblings, which are list/status/send/approve/result operations rather than session creation. The additional note about plan approval does not confuse the core purpose.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
There is no explicit guidance on when to use this tool versus its siblings, nor any exclusions or prerequisites. The only implied usage is 'when you need to start a session,' but no alternatives are mentioned, and there is no discussion of when not to use it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current state and metadata for a Jules session.
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes |
| Name | Required | Description |
|---|---|---|
No output parameters | ||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must carry the full burden of behavioral disclosure, and it only states that the tool returns state and metadata. It does not mention what happens for invalid sessions, access requirements, whether the session must be active, or any rate/blocking behavior, so the agent has no information beyond the basic 'get' action.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single sentence that immediately states the verb and object with no filler or redundant words. It is appropriately sized for a tool with one required parameter and fully earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple and has an output schema, so the description does not need to elaborate on the return format. However, it is incomplete because it leaves unanswered how the session_id should be obtained and does not delineate how 'state and metadata' differs from the output of jules_activity or jules_result, which an agent would need to select and invoke correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description was expected to compensate for the session_id parameter, but it does not mention the parameter at all. The name 'session_id' is self-explanatory, but the description does not clarify its format or where to obtain it (e.g., from jules_start or jules_list_sessions), adding no meaning beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'get' and identifies the resource as a Jules session's current state and metadata, which is enough to distinguish it from tools like jules_list_sessions or jules_result. However, it does not explicitly contrast it with jules_activity, which might also involve state-related information, so it misses the top score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description is purely functional and offers no guidance about when to prefer this tool over siblings like jules_activity or jules_result, nor when it should not be used. All seven sibling tools are named in context, but the description never references them, leaving the selection decision entirely to the agent.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.
v0.1.0jules_activityjules_approve_planjules_list_sessionsjules_list_sourcesjules_resultjules_sendjules_startjules_statusMost tools target distinct actions, but jules_status, jules_activity, and jules_result all retrieve session information and could be confused by an agent. Descriptions clarify granularity, but the boundaries between current state, activities, and full result are not obvious.
All tools share a consistent jules_ prefix and use clear, action-oriented names. Some are verb_noun forms like list_sources and approve_plan, while others are single nouns like status and result, creating minor inconsistency but the pattern remains readable.
With 8 tools, the server is well-scoped for managing Jules coding sessions. Each tool serves a distinct purpose in the workflow without unnecessary bloat.
The core lifecycle is covered: list sources, start a session, approve plans, send feedback, and retrieve results. Minor gaps exist such as no explicit cancel/reject tool, but send feedback likely covers redirection or rejection.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
A paid remote MCP for OpenAI Codex agent coordination MCP, built to return verdicts, receipts, usage
The Cortex MCP server provides read-only access to real-time engineering context from the Cortex developer portal, allowing AI coding assistants to answer natural language questions about your organization's catalog (microservices, libraries, domains, teams, infrastructure), scorecards (engineering standards and best practices), initiatives (goals and deadlines), and Engineering Intelligence metrics. It includes tools for querying documentation, tracking personal entities, and accessing AI-assisted insights across the entire Cortex ecosystem.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Persistent memory and cross-session learning for AI coding assistants (hosted remote MCP).
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/jbolt25/jules-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
