jules-mcp

by jbolt25

Overview Schema Source Related Servers Score Discussions

Python

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v0.1.0
Disambiguation3/5
Most 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.
Naming Consistency4/5
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.
Tool Count5/5
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.
Completeness4/5
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.
Average 3.2/5 across 8 of 8 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 10 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
Add a LICENSE file by following GitHub's guide. Once GitHub recognizes the license, the system will automatically detect it within a few hours.
If the license does not appear after some time, you can manually trigger a new scan using the MCP server admin interface.
MCP servers without a LICENSE cannot be installed.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior2/5
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.
Conciseness4/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness4/5
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.
Completeness2/5
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.
Parameters1/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness2/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose4/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines2/5
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.
Behavior2/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.
Behavior3/5
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.
Conciseness5/5
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.
Completeness3/5
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.
Parameters2/5
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.
Purpose5/5
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.
Usage Guidelines3/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

jules-mcp MCP server — quality and maintenance score on Glama

Copy to your README.md:

[![jules-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jbolt25/jules-mcp/badges/card.svg)](https://glama.ai/mcp/servers/jbolt25/jules-mcp)

Score Badge

Copy to your README.md:

[![jules-mcp MCP server — quality and maintenance score on Glama](https://glama.ai/mcp/servers/jbolt25/jules-mcp/badges/score.svg)](https://glama.ai/mcp/servers/jbolt25/jules-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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