Use this MCP stdio server to delegate, monitor, and interact with Google Jules cloud coding sessions from an MCP client.
List configured Jules/GitHub accounts and routing aliases (jules_list_accounts).
List connected GitHub repositories/sources, optionally by account (jules_list_sources).
Delegate autonomous coding, refactoring, bug-fixing, or documentation tasks to Jules, creating a remote Google Cloud VM session (jules_delegate_task).
Control delegation options: target files, test command, starting branch, auto-create PR, and require plan approval.
Retrieve session status, outputs, PR links, and metadata (jules_get_session).
List recent active/completed sessions (jules_list_sessions).
View chronological session activities: thoughts, plans, bash outputs, diffs, PRs (jules_list_activities).
Send follow-up guidance or feedback to an ongoing session (jules_send_message).
Approve a paused execution plan so Jules can proceed (jules_approve_plan).
Extract the latest unified git patch/diff from a session (jules_get_diff).
It does not run Jules locally, auto-merge PRs, or maintain background watchers; it requires JULES_API_KEY.
Click on "Deploy 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 List the repositories Jules can access."
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.
Delegate complex, long-running coding tasks from local agents to the cloud-based Google Jules AI agent.
📚 Documentation Suite: Architecture • Agent Directives • Contributing • Security Policy • Specification • License
Related MCP server: Jules API MCP
Status: Active
Language: Go (Golang)
Protocol: Model Context Protocol (stdio transport)
Last verified: 2026-09-11
What it does:
Exposes Google Jules v1alpha REST API as a high-performance Model Context Protocol (stdio) server.
Lists connected GitHub repositories with their resolved default branches.
Autonomously delegates tasks to Jules, creating remote sessions in Google Cloud VMs.
Provides complete lifecycle observability: status checks, activity logs with unidiff patch previews, interactive message replies, and human plan approvals.
Implements smart branch resolution (R1): resolves default branch automatically from source metadata without hardcoded fallbacks.
Compact response formatting (R3): protects LLM context windows by truncating patch previews (<=300 chars) and prompt echoes (<=200 chars).
What it does not do:
Does not run Jules locally (Jules runs inside Google Cloud VMs).
Does not automatically approve or merge Jules's Pull Requests on GitHub.
Does not maintain unmonitored background watcher loops (one-shot actions only).
go install (Recommended)go install github.com/TheNovaNodes/google-jules-mcp/cmd/google-jules-mcp@latest# 1. Clone repository
git clone https://github.com/TheNovaNodes/google-jules-mcp.git
cd google-jules-mcp
# 2. Configure environment
cp .env.example .env
# Edit .env and set your JULES_API_KEY
# 3. Build binary
make build
# or: go build -ldflags="-s -w" -o bin/google-jules-mcp ./cmd/google-jules-mcp
# 4. Run server (stdio)
./bin/google-jules-mcpJULES_API_KEY: The API key for accessing Google Jules REST API (Required).
JULES_DISABLE_RETRY: Set to 1 or true to disable exponential backoff retries (Optional, for deterministic testing).
Tool | Description | Side Effects |
| List all GitHub repositories and default branches connected to Jules | None (Read-only) |
| Delegate a long-running coding/refactoring mission to Jules | Creates remote cloud session |
| Check the current execution state and status of a Jules session | None (Read-only) |
| Retrieve comprehensive details and metadata of a Jules session | None (Read-only) |
| List execution activity events, progress steps, and code patch previews | None (Read-only) |
| Send an interactive message or instructions to a Jules session | Sends message to remote session |
| Approve a proposed execution plan for a session paused in plan approval | Releases human gate; starts execution |
| Extract the latest Git unidiff patch produced by Jules for a session | None (Read-only) |
Authentication: All upstream requests require a valid JULES_API_KEY sent via the X-Goog-Api-Key header.
Guardrails (R5): The server implements no background auto-approvers or watchers. approve_jules_plan is an explicit, one-shot action that logs a mandatory warning.
Git Safety: The server never pushes directly, merges, or touches branches outside of what the Jules API executes remotely.
Add to your Claude Desktop, Antigravity, Cursor, or OpenClaw MCP configuration:
{
"mcpServers": {
"google-jules": {
"command": "/absolute/path/to/google-jules-mcp/bin/google-jules-mcp",
"args": [],
"env": {
"JULES_API_KEY": "YOUR_JULES_API_KEY"
}
}
}
}make test
# or: go test -v -race ./...MIT
Approve the generated execution plan for a session paused in AWAITING_PLAN_APPROVAL state.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Optional account ID override. | |
| session_id | Yes | The Jules session ID to approve. |
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 the required session state, which is useful context, but it does not explain what happens after approval (e.g., the plan is executed), any permissions needed, or whether the action is reversible. This is minimal but not misleading.
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 that conveys the action and condition without any wasted words. 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?
For a simple approval action with two well-described parameters and no output schema, the description covers the essential purpose and condition. It could mention post-approval effects, but given the low complexity, it is adequately 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 description coverage is 100%, so both parameters (session_id and account_id) have descriptions. The tool description does not add any additional meaning beyond what the schema already provides, aligning with the baseline score for full 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 uses a specific verb ('Approve') and clearly identifies the resource ('generated execution plan') and the context ('session paused in AWAITING_PLAN_APPROVAL state'). It is distinct from sibling tools like jules_delegate_task or jules_send_message.
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 provides a clear usage condition: the session must be in AWAITING_PLAN_APPROVAL state. While it doesn't explicitly mention alternatives or exclusions, the state condition effectively guides when this tool should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Delegate an autonomous coding, refactoring, bug-fixing, or documentation task to Google Jules. Jules will spin up a Google Cloud VM sandbox, clone the repo, plan changes, run test commands, apply modifications, and open a Pull Request automatically. Includes prompt boosting & verification contracts.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Task description, problem statement, or engineering requirement. | |
| account_id | No | Optional account override ('thedoctormes' or 'thenovanodes'). Auto-detected from source_name if omitted. | |
| source_name | Yes | Repository identifier (e.g. 'sources/github/TheNovaNodes/zakupki-parser-export' or 'thedoctormes-hue/gxlab'). | |
| target_files | No | Optional list of primary file paths that Jules should focus on. | |
| test_command | No | Optional explicit test command for Jules to run (e.g. 'pytest tests/ -v' or 'npm test'). | |
| auto_create_pr | No | Whether Jules should automatically push commits and open a GitHub PR upon completion. | |
| starting_branch | No | Base branch to clone and build upon (default: 'main'). | main |
| require_plan_approval | No | If true, Jules will pause after generating the plan and await your approval before making changes. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden. It discloses the entire execution pipeline: spin up a VM, clone repo, plan changes, run tests, apply modifications, open PR. It also mentions 'prompt boosting & verification contracts.' However, it omits async behavior, return format, and potential failure modes, which would be valuable for an agent.
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 two sentences, front-loaded with purpose and followed by a compact workflow summary. Every clause adds information, with no fluff. The inclusion of 'prompt boosting & verification contracts' is brief but adds context.
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 covers the main process but lacks critical operational context: it does not say what the tool returns, whether it is asynchronous, or how to track progress via sibling tools like jules_list_sessions. With no output schema and 8 parameters, this is a notable gap for a complex delegation 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?
Schema coverage is 100% with clear parameter descriptions. The tool description provides a high-level workflow but does not add parameter-level details beyond the schema. For example, it mentions 'run test commands' but the schema already describes test_command in detail. 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's purpose: 'Delegate an autonomous coding, refactoring, bug-fixing, or documentation task to Google Jules.' It also details the full workflow (VM sandbox, clone, plan, test, modify, PR), distinguishing it from sibling tools like list_sources or approve_plan, which are clearly auxiliary.
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 usage context by describing what the tool does, but it does not explicitly state when to use it over siblings or mention prerequisites like using jules_list_sources to validate source_name. It provides no guidance on handling plan approval or monitoring the delegated task.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Extract the unified git patch diff from a completed or active Jules session.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Optional account ID override. | |
| session_id | Yes | The Jules session ID. |
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 works on both completed and active sessions and indicates the output type, suggesting a read-only operation. However, it does not explicitly state safety, authentication requirements, or potential edge cases (e.g., empty diff).
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 front-loads the action and object. Every word contributes, with no repetition or fluff.
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 extraction tool, the description adequately specifies the return value ('unified git patch diff') and a key constraint (session state). While no output schema exists, the description names what is returned. It could mention details like error handling or account_id behavior, but overall it is complete enough for this scale.
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 descriptions for both session_id and account_id. The tool description adds no additional meaning about parameters, so the baseline of 3 applies per the rubric.
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 ('Extract') and resource ('unified git patch diff') from a Jules session, making the tool's purpose unambiguous. It also distinguishes itself from sibling tools like jules_get_session or jules_list_activities by focusing on diffs.
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 on when to use this tool versus alternatives, or any exclusions. The description implies its use for retrieving diffs, but an agent is left without context on when to select it over other session-related tools.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Retrieve status, generated outputs, Pull Request links, and metadata for a specific Jules session.
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Optional account ID if known ('thedoctormes' or 'thenovanodes'). | |
| session_id | Yes | The unique Jules session ID (e.g. '10174540046405012210' or 'sessions/10174540046405012210'). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden. It reveals the tool is a read operation ('Retrieve') and lists output categories, but does not disclose potential side effects, authentication requirements, rate limits, or error behavior. This is basic transparency but lacks depth.
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 that front-loads the action and enumerates the primary returned data. Every word is informative and no redundant repetition occurs.
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 retrieval tool with two well-described parameters and no output schema, the description adequately explains what the tool returns. It lacks examples or notes on edge cases, but the scope is straightforward and the sibling context does not require deeper disambiguation.
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 provides 100% coverage with descriptions for both session_id and account_id. The tool description adds no additional parameter explanation beyond implying session_id identifies the specific session, so the schema carries the semantic weight.
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 'Retrieve' and the resource 'specific Jules session', enumerating what is fetched (status, outputs, PR links, metadata). It distinguishes itself from sibling list tools by focusing on a single session rather than listing multiple.
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 'for a specific Jules session' implies when to use this tool versus listing sessions, but it does not explicitly name alternatives or state when not to use it. No guidance is provided relative to siblings like jules_get_diff or jules_list_activities.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all configured Google Jules / GitHub accounts and routing aliases in the system.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. The verb 'List' implies a read-only, non-destructive operation, but the description does not explicitly state behavioral traits such as authentication requirements, side effects, or return format. This is minimally sufficient for a simple list operation.
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, coherent sentence that is entirely on point. It is front-loaded with the action and resource, with no filler or redundant information.
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, parameterless listing tool, the description provides the essential context: what is being listed. It does not detail the return structure, but this is somewhat obvious for a list operation and there is no output schema to complement. The absence of a mention of differentiation from jules_list_sources is a minor gap.
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 tool has zero parameters, which per rubric is a baseline score of 4. The description adds no parameter-specific meaning since there are none to clarify.
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 'List' with a clear resource: 'configured Google Jules / GitHub accounts and routing aliases'. This distinguishes it from sibling tools like jules_list_sources and jules_list_sessions, which target different resources.
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 provides no guidance on when to use this tool versus alternatives, such as jules_list_sources. It merely states what the tool does, leaving the agent to infer usage context without explicit exclusions or alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the chronological event timeline of a session (agent thoughts, execution plans, bash outputs, diffs, PRs).
| Name | Required | Description | Default |
|---|---|---|---|
| account_id | No | Optional account ID override. | |
| session_id | Yes | The Jules session ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It clearly states the output is a chronological timeline and lists content categories, but it does not explicitly note that the operation is read-only, mention permissions, or describe any side effects or edge-case behavior.
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, well-structured sentence that front-loads the core action and then provides a parenthetical list of content types. Every word earns its place with no redundancy.
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?
With no output schema and no annotations, the description provides a reasonable overview but omits details about the return format, pagination, or error behavior. It is adequate for a simple listing tool but not fully 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 description coverage is 100%, so the schema already describes both parameters. The description does not add extra meaning beyond implying that the timeline is for a session, which matches session_id. Thus, 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's function with a specific verb and resource: 'Get the chronological event timeline of a session'. It also enumerates the content types (agent thoughts, execution plans, bash outputs, diffs, PRs), which distinguishes it from siblings like jules_get_session or jules_get_diff.
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 the tool: when a chronological timeline of session activities is needed. However, it does not explicitly mention alternatives or situations when not to use it, so it falls short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List recent active and completed Jules sessions for an account.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Number of sessions to retrieve (default 30). | |
| account_id | No | Account ID: 'thedoctormes' or 'thenovanodes'. |
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 fails to disclose optionality of parameters, the meaning of 'recent', response format, or pagination behavior, leaving gaps in understanding the tool's behavior.
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, front-loaded sentence with a clear verb and essential details. 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 simple listing tool, the description is adequate but lacks details such as output format, pagination behavior, and whether account_id is required or scopes the list. With no output schema and no annotations, more context would be helpful.
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 clear parameter descriptions. The description adds the status filter (active and completed) not present in the schema, but does not clarify the account_id optionality or default behavior when omitted.
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 recent active and completed Jules sessions, specifying the resource and scope. It is easily distinguishable from sibling tools like jules_list_accounts 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 phrase 'for an account' implies use with account_id, and the active/completed wording suggests filtering, but no explicit guidance is given on when to prefer this over jules_get_session or other list tools. Usage context is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all GitHub repositories connected to Google Jules for a specific account or across defaults.
| Name | Required | Description | Default |
|---|---|---|---|
| page_size | No | Max number of sources to return (default 100). | |
| account_id | No | Optional account alias: 'thedoctormes' (DoctorM & Ai) or 'thenovanodes' (TheNovaNodes). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. 'List' implies a read-only operation, but it does not disclose any additional behavioral details such as permissions, return format, or whether 'across defaults' means all accounts. This is adequate but not rich.
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 extraneous words. It efficiently communicates the tool's purpose.
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 list tool with two optional parameters and no output schema, the description is sufficient. It clearly states the action and scope. The only minor gap is the ambiguous 'across defaults' phrasing, but overall it is 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 description coverage is 100%, so the schema fully documents both parameters. The description adds a slight hint about account_id ('for a specific account or across defaults') but does not provide new meaning beyond what the schema already states.
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 ('List') and resource ('GitHub repositories connected to Google Jules'), and clarifies the scope ('for a specific account or across defaults'). It clearly distinguishes from sibling tools like jules_list_accounts and jules_list_sessions.
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 it (when you need to list connected repositories) and mentions the optional account context. It does not explicitly name alternatives or exclusions, but the context is clear enough for selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Send follow-up guidance, feedback, or adjustments to an ongoing Jules session.
| Name | Required | Description | Default |
|---|---|---|---|
| message | Yes | Follow-up message, prompt adjustment, or feedback. | |
| account_id | No | Optional account ID override. | |
| session_id | Yes | The Jules session ID. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of disclosing behavior. It conveys that the tool sends a message and requires an ongoing session, but does not disclose side effects, authentication needs, or whether the message is stored/visible to the session. The verb 'send' provides basic transparency, but no deeper behavioral detail.
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 redundancy. Every word contributes to the core purpose, and it avoids unnecessary detail.
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 covers the essential action and resource, and the schema covers all parameters. However, it lacks information about return values, error conditions, or constraints beyond 'ongoing' (e.g., session must be active, message length limits). Given the tool's simplicity and good schema coverage, this is minimally viable but not 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 description coverage is 100%, with each parameter ('message', 'account_id', 'session_id') already meaningfully described. The description adds no extra parameter semantics, so a baseline of 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 a specific action ('Send') and resource ('follow-up guidance, feedback, or adjustments to an ongoing Jules session'), distinguishing it from list/get/approve/delegate siblings. However, it could more explicitly contrast with 'delegate_task' or 'approve_plan' to fully disambiguate.
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 usage for ongoing sessions but provides no explicit guidance on when to use this tool versus alternatives, no prerequisites, and no exclusion criteria. It does not mention that 'approve_plan' or 'delegate_task' should be used for other actions.
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.
v0.1.0jules_approve_planjules_delegate_taskjules_get_diffjules_get_sessionjules_list_accountsjules_list_activitiesjules_list_sessionsjules_list_sourcesjules_send_messageScored across 9 tools
Each tool targets a distinct resource or action: accounts, sources, task delegation, session retrieval, session listing, activity timelines, plan approval, messaging, and diff extraction. There is minimal overlap, and any possible confusion between get_session, list_sessions, and list_activities is resolved by their distinct purposes.
All tools follow the consistent 'jules_verb_noun' pattern with snake_case, making the naming predictable and easy to navigate. For example, list_accounts, delegate_task, get_session, and approve_plan all use the same verb-first convention.
With 9 tools, the set is well-scoped for managing Google Jules sessions, covering account/source introspection, task delegation, monitoring, and interaction. The count is within the ideal 3-15 range and each tool earns its place.
The lifecycle covers delegation, monitoring (status, activities, diffs), approval, and follow-up messaging. A minor gap is the absence of a cancel/stop session operation, but the existing surface handles the primary workflows effectively.
Nifty's MCP server — exposes tasks, projects, messages, and files as tools for AI agents.
MCP server for secureFlows: token-free URL builders and integration-linting tools for AI agents.
The Remote MCP server acts as a standardized bridge between LLM applications (like Claude, ChatGPT, and Cursor) and external services, enabling AI agents to access external tools and resources. Its primary capability is providing a centralized search tool to discover other MCP servers and their respective tools. Unlike local implementations, it runs remotely with OAuth authentication and permission controls for security.
MCP server exposing the Backtest360 engine API as tools for AI agents.
