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., "@Google Jules MCP Server Create a new coding session to fix the authentication bug in login.js"
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.
An MCP (Model Context Protocol) server that provides access to the Google Jules API - Google's AI-powered coding agent for automating software development tasks.
This MCP server exposes all Jules API capabilities:
jules_list_sources - List all connected GitHub repositories
jules_get_source - Get details of a specific source
jules_list_sessions - List all coding sessions
jules_get_session - Get session details including state and outputs
jules_create_session - Create a new coding task for Jules
jules_approve_plan - Approve a plan in a session requiring approval
jules_send_message - Send a message to Jules within a session
jules_list_activities - List all activities within a session
jules_get_activity - Get details of a specific activity
Related MCP server: Jules MCP Server
npx google-jules-mcpnpm install -g google-jules-mcp
google-jules-mcpSet your Google Jules API key:
export GOOGLE_JULES_API_KEY=your_api_key_hereAdd to your MCP client configuration (e.g., Claude Desktop):
{
"mcpServers": {
"google-jules": {
"command": "npx",
"args": ["google-jules-mcp"],
"env": {
"GOOGLE_JULES_API_KEY": "your_api_key_here"
}
}
}
}Use jules_list_sources to see all connected GitHub repositories.Use jules_create_session with:
- prompt: "Fix the authentication bug in login.js"
- source: "sources/github/myorg/myrepo"
- startingBranch: "main"
- automationMode: "AUTO_CREATE_PR"Use jules_list_activities with the sessionId to see what Jules is doing.Use jules_send_message to ask Jules questions or provide feedback during a session.To get your Jules API key:
Go to Jules Settings
Create a new API key
Keep it secure - don't share or commit it to public repositories
Node.js 18.0.0 or higher
A Google Jules API key
GitHub repositories connected to Jules (via the Jules web app)
MIT
Approve a plan in a session that requires plan approval. This allows Jules to proceed with executing the plan.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The ID of the session containing the plan to approve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must disclose behavioral traits. It indicates this is a write/mutation operation but lacks details on side effects, required permissions, idempotency, or what happens if the plan is already approved. Minimal behavioral 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?
Two sentences, no extraneous words. Every sentence adds value: the first states the action, the second explains the consequence. Highly efficient.
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?
Despite the tool's simplicity (1 param, no output schema), the description omits important context such as error conditions, whether the action is reversible, or any confirmation behavior. With no annotations to supplement, the description falls short of complete 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?
Schema coverage is 100% with a clear parameter description for sessionId. The tool description adds no additional meaning beyond the schema. Baseline of 3 is appropriate since the schema does the heavy lifting.
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 the verb ('Approve') and the resource ('a plan in a session'), making the tool's core function unambiguous. However, it does not explicitly distinguish it from sibling tools, though the sibling list does not contain other approval tools, so differentiation is implicit.
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 when to use ('a session that requires plan approval') and the effect ('allows Jules to proceed'), but does not state when not to use or provide explicit alternatives. Since no other sibling tool performs approval, usage context is clear but not comprehensive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Create a new Jules session to start a coding task. Jules will work on the task autonomously, optionally creating a PR when done.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | The prompt describing what task Jules should perform (e.g., 'Fix the bug in auth.js', 'Add dark mode support') | |
| source | Yes | The source name to work on (e.g., 'sources/github/owner/repo') | |
| startingBranch | Yes | The branch to start from (e.g., 'main') | |
| title | No | Optional title for the session. If not provided, system will generate one. | |
| automationMode | No | Automation mode. Use 'AUTO_CREATE_PR' to automatically create a PR when done. | |
| requirePlanApproval | No | If true, plans will require explicit approval before Jules starts working. Default is auto-approve. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description carries the burden. It discloses autonomous operation and optional PR creation but does not mention side effects, authorization needs, or behavior on existing sessions. The description is adequate but not fully transparent.
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?
Two sentences, front-loaded with purpose. Every sentence is meaningful. Could be slightly more concise, but no wasted words.
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 creation tool with 6 parameters and no output schema, the description is brief. It covers basic functionality but lacks details about session lifecycle, error conditions, or how to monitor progress. Adequate for a simple tool but incomplete for complex usage.
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 100%, so baseline is 3. The description adds minimal extra meaning beyond the schema—only hinting at the automationMode connection to PR creation. No additional semantic value.
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 the verb 'Create' and the resource 'Jules session', and specifies the action's purpose ('to start a coding task'). It distinguishes from sibling tools like jules_get_session, jules_list_sessions, etc., which are for retrieval or listing.
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 mentions using the tool to start a coding task but provides no explicit guidance on when to use it versus alternatives (e.g., when to use jules_get_session instead). There is no mention of prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific activity within a session, including artifacts like code changes, bash outputs, or media.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The ID of the session containing the activity | |
| activityId | Yes | The ID of the activity to retrieve |
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 mentions artifact types but lacks details on auth requirements, rate limits, or whether the operation is read-only. The description is insufficient for understanding behavioral traits beyond the basic purpose.
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?
A single, well-structured sentence front-loads the purpose with no unnecessary words. Every word contributes to understanding the tool's function.
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 has 2 required parameters, no output schema, and no annotations. The description explains what the tool does but does not describe the return value structure or any side effects, leaving gaps for an agent relying solely on this information.
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 coverage is 100% with descriptions for both parameters. The description adds context about the session relationship and artifact types but does not provide additional syntax, format, or constraints beyond what the schema already offers.
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 the verb 'Get', the resource 'details of a specific activity', and scopes it within a session. It also mentions specific artifact types, distinguishing it from sibling tools like jules_list_activities and jules_get_session.
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 does not explicitly state when to use this tool versus alternatives. While the purpose implies its use for fetching a single activity's details, no direct guidance or exclusion criteria are provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific session including its state, source context, outputs, and any pull requests created.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The ID of the session to retrieve |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool retrieves session details including state, source context, outputs, and pull requests, which implies a read-only operation. However, it does not specify behavior on error (e.g., if session does not exist) or any authentication requirements, but for a simple get operation this is mostly sufficient.
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 of 15 words that immediately conveys the purpose and key return contents. Every word earns its place with no redundancy or filler.
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?
Given the tool's simplicity (one required parameter, no output schema), the description provides a good overview of what the tool returns. It does not detail error responses or pagination, but for a straightforward retrieval tool it is largely complete.
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 coverage is 100%, and the schema already describes sessionId as 'The ID of the session to retrieve'. The tool description adds no extra meaning beyond what the schema provides, so it meets the baseline but does not exceed it.
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 the verb 'Get details' and the resource 'specific session', and enumerates what is included (state, source context, outputs, pull requests). This distinguishes it from sibling tools like jules_list_sessions (which likely returns summaries) and jules_get_activity (which focuses on activity details).
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 use when you need detailed information about a single session, but it does not explicitly contrast with sibling tools or provide conditions for when not to use it. No alternatives or exclusions are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get details of a specific source by its name. Returns source information including GitHub repo owner, name, branches, and privacy status.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | The full resource name of the source (e.g., 'sources/github/owner/repo') |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries burden. It describes the tool as a read operation and lists returned fields, but does not explicitly state read-only nature, error handling, or any potential side effects.
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?
Two concise sentences with no unnecessary information; front-loaded with what the tool does and what it returns.
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 tool with one required parameter and no output schema, description provides clear purpose, example parameter, and expected output fields, though could expand on return value structure.
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 has 100% coverage for the single parameter; description adds an example format ('sources/github/owner/repo') that adds value beyond schema description.
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?
Description clearly states verb ('Get details') and resource ('specific source by its name'), and specifies returned fields (GitHub repo owner, name, branches, privacy status), distinguishing it from sibling tool jules_list_sources which lists all sources.
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?
Implied usage: when you have the source name and need details. No explicit when-not or alternatives, but sibling tools provide context for listing versus details.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all activities within a session. Activities include plan generation, progress updates, messages, and completion status.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The ID of the session to list activities for | |
| pageSize | No | Maximum number of activities to return (optional) | |
| pageToken | No | Token for pagination to get the next page of results (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description must cover behavioral traits but only mentions what activities include. It does not disclose whether the operation is read-only, requires specific permissions, or any side effects. This is insufficient for a tool with no annotation safety net.
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 that conveys the core purpose and examples. It is front-loaded and efficient, though could benefit from brief structured guidelines.
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 description is adequate for a simple list tool, but without an output schema, it could explain more about the return format (e.g., ordering, pagination details). The examples help but completeness is moderate.
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 coverage is 100%, so parameters are fully documented in the schema. The description adds no additional context beyond the schema, such as defaults, formatting, or relationships. Baseline 3 is appropriate.
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 the tool lists activities within a session and provides examples like plan generation and messages. It distinguishes from jules_get_activity by focusing on listing all activities rather than retrieving one, but does not explicitly differentiate from other siblings.
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 on when to use this tool versus alternatives such as jules_get_activity or jules_list_sessions. The examples imply content but do not specify prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all sessions. Sessions are continuous units of work within a specific context. Returns session details including state, outputs, and pull requests.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of sessions to return (optional) | |
| pageToken | No | Token for pagination to get the next page of results (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Mentions return fields (state, outputs, pull requests) but lacks disclosure on read-only nature, authentication, or side effects.
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?
Two sentences, front-loaded with purpose, no redundant words. Efficient and clear.
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?
Given no output schema and simple optional params, description adequately covers purpose, returns, and definition. Could mention pagination behavior but schema covers it.
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 coverage is 100%, and description does not add extra meaning beyond the schema definitions for pageSize and pageToken. Baseline score of 3 applies.
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?
Clearly states 'List all sessions' with a definition of what sessions are, distinguishing it from siblings like jules_create_session and jules_get_session.
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?
Description implies usage for listing sessions but provides no explicit guidance on when to use this tool vs alternatives or 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.
List all available sources (GitHub repositories) connected to Jules. Returns a list of sources with their names and GitHub repo details.
| Name | Required | Description | Default |
|---|---|---|---|
| pageSize | No | Maximum number of sources to return (optional) | |
| pageToken | No | Token for pagination to get the next page of results (optional) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Minimal behavioral info beyond schema. No annotations; description only states it returns a list with names and repo details, but no mention of pagination behavior, rate limits, or read-only nature.
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?
Two concise sentences, front-loaded with purpose, no wasted words.
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?
No output schema, but description mentions return details (names and GitHub repo details). Could be more explicit about pagination structure, but sufficient for a list tool with optional parameters.
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 coverage is 100% with descriptions. Description adds no extra meaning for parameters; baseline score applies.
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?
Clearly states it lists all available sources (GitHub repositories) connected to Jules. Distinguishes from sibling tools like jules_get_source (single source) and jules_list_activities (different resource).
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 explicit guidance on when to use versus alternatives. Implicit from sibling names, but lacks direction such as prerequisites or when not to use.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send a message to Jules within an active session. Use this to provide feedback, ask questions, or request changes.
| Name | Required | Description | Default |
|---|---|---|---|
| sessionId | Yes | The ID of the session to send the message to | |
| prompt | Yes | The message to send to Jules |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description bears full responsibility for disclosing behavior. It states that sending a message occurs within an active session but does not mention any side effects, delivery guarantees, rate limits, or required permissions. A score of 3 is appropriate as the description is minimally adequate but lacks important behavioral context.
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 exceptionally concise, using only two sentences. It front-loads the core action and immediately follows with typical use cases. Every word adds value, with no redundancy or filler.
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?
Given the tool's simplicity, the description covers the essential context: it requires an active session and lists common purposes. The parameter semantics are fully covered by the schema. While it omits discussion of return values (no output schema) and behavioral details, the overall completeness is adequate for a straightforward messaging tool.
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 input schema has 100% coverage with clear descriptions for both parameters (sessionId, prompt). The tool description adds no additional meaning beyond what the schema provides, so it meets the baseline of 3 without enhancement.
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 the action ('send a message'), the target entity ('Jules'), and the context ('within an active session'). It also lists specific use cases (feedback, questions, requests). This distinguishes it from sibling tools which handle plans, sessions, and activities.
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 explicitly states when to use the tool ('to provide feedback, ask questions, or request changes'), providing clear context. However, it does not mention when not to use it or suggest alternatives, though sibling tools are sufficiently distinct to avoid confusion.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Each tool has a distinct purpose: session operations, activity tracking, source management, and messaging. There is no overlap, and descriptions clearly differentiate them.
All tools follow a consistent 'jules_verb_noun' pattern in snake_case, making it easy to predict and understand the tool's function from its name.
With 9 tools, the server is well-scoped for its domain. The number is within the ideal range and each tool serves a clear role without redundancy.
The tool set covers session lifecycle, activity details, and source management. Minor gaps like delete operations exist but do not hinder core workflows.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Provides tools for searching Google Workspace documentation and much more.
Access the GitHub API, enabling file operations, repository management, search functionality, and…
SEO & marketing toolkit for AI agents: GA4, Search Console, AdSense, GTM, PageSpeed, Trends.
Google NotebookLM via natural language: create notebooks, add sources (PDF, URL, YouTube) and ask gr
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/Godzilla675/google-jules-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
