Integrates with GitHub repositories through Jules to automate code modifications, create pull requests, and manage repository maintenance tasks like dependency updates and security audits.
Enables autonomous coding tasks through the Google Jules API, allowing creation and scheduling of coding sessions, task management, plan approval workflows, and monitoring of code generation progress in connected GitHub repositories.
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., "@Jules MCP Server add error handling to the login function in my-app-backend"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
A production-ready Model Context Protocol (MCP) server for the Google Jules API, enabling autonomous coding tasks and scheduling directly from AI assistants like Claude.
⚠️ DISCLAIMER: This is an independent, open-source project and is NOT officially created, maintained, or endorsed by Google. This server is a community-driven integration with the public Jules API. Use at your own risk. For official Jules documentation, visit jules.google.
If you find this useful, please star ⭐ the repository to help others discover it!
Related MCP server: Jules MCP Server
This MCP server bridges the Google Jules coding agent with AI assistants, allowing you to:
Create coding tasks - Delegate bug fixes, refactoring, tests, and features to Jules
Schedule recurring tasks - Set up automated weekly/daily maintenance (dependency updates, security audits, etc.)
Monitor progress - Track session states and review generated plans
Approve plans - Human-in-the-loop control before code changes
Manage workflows - Send feedback and iterate on Jules's work
Since the Jules API v1alpha is stateless (no native scheduling endpoints), this server implements a local scheduling engine:
Persistent Storage: Schedules stored in ~/.jules-mcp/schedules.json
Cron Engine: Uses node-schedule for reliable task execution
Survives Restarts: Schedules are rehydrated on server startup
Autonomous Execution: Scheduled tasks run even without active IDE sessions
Node.js 18.0.0 or higher
Jules API Key - Generate at jules.google/settings
GitHub Repositories - Connect repos to Jules via the web UI first
# Clone or download this repository
cd jules-mcp
# Install dependencies
npm install
# Build TypeScript
npm run build
# Set your API key
export JULES_API_KEY="your-key-here"
# Test the server
npm startAfter building and setting JULES_API_KEY, you can validate the server end-to-end:
npm run mcp:smokeExpected output (with a valid key):
Lists 6 tools, 5 prompts, and the 4 core resources
Attempts to read a fake session ID and reports a Jules 404 (proves real API calls work)
Attempts a tool call with dummy data and reports the API error without crashing
# Install globally
npm install -g
# Now available as: jules-mcp
jules-mcpCreate a .env file or set these in your shell:
# Required
JULES_API_KEY=your_jules_api_key_here
# Optional - Security allowlist (comma-separated repo names)
# If set, only these repos can be modified
JULES_ALLOWED_REPOS=owner/repo1,owner/repo2
# Optional - Default branch
JULES_DEFAULT_BRANCH=mainAdd to your claude_desktop_config.json:
{
"mcpServers": {
"jules": {
"command": "node",
"args": ["/path/to/jules-mcp/dist/index.js"],
"env": {
"JULES_API_KEY": "your-key-here"
}
}
}
}On macOS: ~/Library/Application Support/Claude/claude_desktop_config.json
On Windows: %APPDATA%/Claude/claude_desktop_config.json
For Cursor or VS Code with MCP support:
{
"mcp.servers": {
"jules": {
"command": "jules-mcp",
"env": {
"JULES_API_KEY": "your-key-here"
}
}
}
}Once configured, your AI assistant can use Jules through natural language:
"Use Jules to add unit tests for the authentication module in my-app-backend repository"The assistant will:
Check jules://sources to find the repository
Call create_coding_task tool with appropriate prompt
Return the session ID for monitoring
"Schedule Jules to update dependencies every Monday at 9 AM in my-app-backend"The assistant will:
Call schedule_recurring_task with cron "0 9 * * 1"
Save the schedule to ~/.jules-mcp/schedules.json
Confirm the next execution time
"Check the status of Jules session abc123"The assistant will:
Call get_session_status or read jules://sessions/abc123/full
Show current state (PLANNING, IN_PROGRESS, COMPLETED, etc.)
Provide next steps based on state
"Show me Jules's plan for session abc123 and approve it"The assistant will:
Read jules://sessions/abc123/full to get the plan
Display the plan steps to you
Call manage_session with action=approve_plan after your confirmation
Resources are read-only context that the AI can access:
URI | Description |
| Connected GitHub repositories |
| Recent Jules sessions |
| Complete session details with activities |
| Active scheduled tasks |
| Execution history |
Tools are actions the AI can execute:
Creates an immediate Jules coding session.
Parameters:
prompt (required) - Natural language task instruction
source (required) - Repository (format: sources/github/owner/repo)
branch (optional) - Target branch (default: main)
auto_create_pr (optional) - Auto-create PR (default: true)
require_plan_approval (optional) - Pause for review (default: false)
title (optional) - Session title
Returns: Session ID and monitoring URL
Manage active sessions (approve plans, send feedback).
Parameters:
session_id (required)
action (required) - "approve_plan" or "send_message"
message (optional) - Required for send_message
Check session status and get next steps.
Parameters:
session_id (required)
Schedule a task to run on a cron schedule.
Parameters:
task_name (required) - Unique schedule identifier
cron_expression (required) - Standard cron format
prompt (required) - Task instruction
source (required) - Repository resource name
branch, auto_create_pr, require_plan_approval, timezone (optional)
Cron Examples:
"0 9 * * 1" - Every Monday at 9 AM
"0 2 * * *" - Every day at 2 AM
"0 0 1 * *" - First day of each month at midnight
List all active scheduled tasks with next run times.
Remove a scheduled task.
Parameters:
task_name (required)
Prompts are templates that guide best practices:
refactor_module - Guided refactoring workflow
setup_weekly_maintenance - Automated maintenance setup
audit_security - Comprehensive security audit
fix_failing_tests - Test failure resolution
update_dependencies - Dependency update with breaking change handling
Never commit your JULES_API_KEY to version control
Store in environment variables or secure secrets manager
The API key grants write access to connected repositories
Use JULES_ALLOWED_REPOS to restrict which repositories can be modified:
export JULES_ALLOWED_REPOS="myorg/safe-repo,myorg/test-repo"This prevents accidental modifications to production or sensitive repos.
For critical repositories, always set require_plan_approval: true:
"Create a task but require plan approval before any code changes"This ensures human review before Jules modifies code.
All scheduled task executions are logged to jules://schedules/history. Review this regularly to audit autonomous activities.
Set your API key:
export JULES_API_KEY="your-key-here"Check jules://sources resource to see connected repos
Ensure the GitHub app is installed on the repository
Use the exact resource name format: sources/github/owner/repo
Check that ~/.jules-mcp/schedules.json exists and is writable.
npm run typechecksrc/
types/ # TypeScript type definitions
jules-api.ts # Jules API types
schedule.ts # Schedule types
api/ # API client layer
jules-client.ts
storage/ # Persistence layer
schedule-store.ts
scheduler/ # Cron engine
cron-engine.ts
mcp/ # MCP protocol layer
resources.ts # Resources implementation
tools.ts # Tools implementation
prompts.ts # Prompt templates
index.ts # Main entry pointnpm run build # Compile TypeScript
npm run dev # Development mode with tsx
npm run typecheck # Type checking onlyThis server provides complete coverage of the Jules v1alpha API:
Endpoint | Method | MCP Mapping |
| GET | Resource: |
| GET | Included in full session resource |
| POST | Tool: |
| GET | Resource: |
| GET | Tool: |
| POST | Tool: |
| POST | Tool: |
| GET | Resource: |
Local scheduling - Cron-based task execution
Schedule persistence - Survives server restarts
Execution history - Audit trail for scheduled tasks
When Jules API adds native scheduling:
The schedule_recurring_task tool will migrate from local cron to API calls
Existing local schedules can be migrated automatically
The MCP tool interface remains unchanged for backward compatibility
Jules API Documentation: https://developers.google.com/jules/api
Jules Web Interface: https://jules.google
Model Context Protocol: https://modelcontextprotocol.io
MCP TypeScript SDK: https://github.com/modelcontextprotocol/typescript-sdk
MIT
This is an open-source implementation. Contributions welcome for:
Additional prompt templates
Enhanced error handling
Webhook support (when Jules API adds it)
Advanced scheduling features (conditional execution, dependency chains)
Creates a new Jules coding session. Returns immediately with a session ID. Monitor progress via jules://sessions/{id}/full resource.
| Name | Required | Description | Default |
|---|---|---|---|
| prompt | Yes | Natural language instruction for the coding task | |
| source | Yes | Repository resource name (sources/github/owner/repo) | |
| branch | No | Git branch to base changes on | main |
| auto_create_pr | No | Automatically create Pull Request upon completion | |
| require_plan_approval | No | Pause for manual plan review | |
| title | No | Optional session title |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that the tool 'returns immediately with a session ID' and that progress should be monitored separately, which are useful behavioral traits. However, it doesn't cover aspects like error handling, rate limits, authentication needs, or what happens if the session fails, leaving gaps for a mutation tool.
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 the core action and immediate return, followed by monitoring instructions. Every sentence earns its place by providing essential information without redundancy 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?
Given no annotations and no output schema, the description is incomplete for a mutation tool. It covers the basic purpose and monitoring aspect but lacks details on return values (beyond session ID), error cases, or side effects. This is adequate but has clear gaps in context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents all 6 parameters. The description adds no additional meaning beyond what the schema provides, such as explaining how parameters interact or providing examples. Baseline 3 is appropriate when 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 ('creates') and resource ('new Jules coding session'), distinguishing it from sibling tools like get_session_status or manage_session. It specifies the immediate return of a session ID, which helps differentiate it from tools that might wait for completion.
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 by mentioning to 'monitor progress via jules://sessions/{id}/full resource', suggesting this tool initiates a task that runs asynchronously. However, it lacks explicit guidance on when to use this versus alternatives like schedule_recurring_task or manage_session, and no prerequisites 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.
Delete a scheduled task by name
| Name | Required | Description | Default |
|---|---|---|---|
| task_name | Yes | Schedule name |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden but only states the action without behavioral details. It doesn't disclose if deletion is permanent, requires specific permissions, has side effects, or provides confirmation. This is inadequate for a destructive 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, clear sentence with zero waste. It's appropriately sized and front-loaded, efficiently conveying the core purpose without unnecessary elaboration.
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 destructive tool with no annotations and no output schema, the description is incomplete. It lacks critical context like behavioral risks, confirmation details, or error handling, leaving significant gaps for safe agent use.
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 documents the 'task_name' parameter. The description adds no additional meaning beyond implying the parameter identifies the schedule, matching the baseline for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('Delete') and resource ('a scheduled task by name'), making the purpose immediately understandable. It doesn't distinguish from sibling tools like 'list_schedules' or 'schedule_recurring_task' beyond the obvious destructive nature, so it's not a perfect 5.
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. It doesn't mention prerequisites (e.g., needing an existing schedule), exclusions, or relationships with siblings like 'list_schedules' for verification or 'schedule_recurring_task' for creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the current status and state of a Jules session
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID |
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 the tool 'Get[s] the current status and state', implying a read-only operation, but doesn't specify whether it requires authentication, has rate limits, returns real-time or cached data, or handles errors. This leaves significant behavioral gaps for a tool with no annotation coverage.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, clear sentence with zero waste—it directly states the tool's purpose without redundancy or unnecessary elaboration. It is appropriately sized and front-loaded, making it easy for an agent to parse quickly.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool has no annotations, no output schema, and a simple parameter, the description is incomplete. It lacks details on what 'status and state' entail, potential return values, error conditions, or how it differs from sibling tools. For a tool with no structured data beyond the input schema, this minimal description is insufficient.
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 the single parameter 'session_id' documented in the schema. The description adds no additional meaning about the parameter beyond what the schema provides, such as format examples or contextual usage. Baseline 3 is appropriate when 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 'Get' and the resource 'current status and state of a Jules session', which is specific and unambiguous. However, it doesn't differentiate from sibling tools like 'manage_session' which might also involve session operations, so it doesn't reach the highest score.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides no guidance on when to use this tool versus alternatives like 'manage_session' or other session-related operations. It lacks context about prerequisites, typical use cases, or exclusions, leaving the agent with minimal usage direction.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all locally-managed scheduled tasks
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden. It states the action ('List') but doesn't disclose behavioral traits such as pagination, sorting, error handling, or what 'locally-managed' entails. This is a significant gap for a tool with zero annotation coverage.
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, efficient sentence with zero waste. It's front-loaded and appropriately sized for a simple listing tool.
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 annotations and no output schema, the description is incomplete. It lacks details on return values, error conditions, or what 'locally-managed' means in context. For a tool with zero structured data, more behavioral context is needed.
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 0 parameters with 100% coverage, so no parameter information is needed. The description appropriately doesn't add param details, earning a baseline score of 4 for not overloading with unnecessary information.
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 ('List') and resource ('all locally-managed scheduled tasks'), providing a specific purpose. It doesn't explicitly differentiate from sibling tools like 'delete_schedule' or 'schedule_recurring_task', but the scope is well-defined.
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 like 'get_session_status' or 'manage_session'. The description implies usage for listing tasks but lacks explicit context or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Manage an active Jules session: approve plans or send feedback
| Name | Required | Description | Default |
|---|---|---|---|
| session_id | Yes | Session ID | |
| action | Yes | Action to perform | |
| message | No | Message (required for send_message) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full burden but offers minimal behavioral context. It mentions two actions but doesn't disclose what 'approve_plan' does (e.g., triggers execution, changes session state), what 'send_message' is for (e.g., feedback to Jules, user notification), or any side effects, permissions, or rate limits. This leaves critical gaps for a mutation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely concise with just one sentence that front-loads the core purpose. Every word earns its place, and there's no redundancy or fluff, making it efficient for quick understanding.
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 complexity (managing sessions with mutations), lack of annotations, and no output schema, the description is incomplete. It doesn't explain what happens after actions (e.g., response format, session state changes), error conditions, or how it fits into broader workflows with sibling tools, leaving the agent under-informed.
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 documents all parameters well. The description adds no additional meaning beyond implying that 'message' is tied to 'send_message', which is already clear from the schema's enum and description. This meets the baseline for high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with specific verbs ('approve plans', 'send feedback') and resource ('active Jules session'), making it immediately understandable. However, it doesn't differentiate this tool from its siblings like 'get_session_status' or explain how session management relates to other session/coding/scheduling tools.
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. It doesn't mention prerequisites (e.g., needing an active session), exclusions, or relationships with sibling tools like 'get_session_status' for checking session state or 'create_coding_task' for task creation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a Jules task to run automatically on a cron schedule. The server manages execution even when offline.
| Name | Required | Description | Default |
|---|---|---|---|
| task_name | Yes | Unique name for this schedule | |
| cron_expression | Yes | Cron expression (e.g., "0 9 * * 1" for Mondays at 9 AM) | |
| prompt | Yes | Task instruction | |
| source | Yes | Repository resource name | |
| branch | No | main | |
| auto_create_pr | No | ||
| require_plan_approval | No | ||
| timezone | No | Timezone for cron |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure. It mentions server-managed execution and offline capability, which adds some context. However, it lacks critical details such as permissions required, whether this is a mutation (implied by 'schedule'), error handling, rate limits, or what happens on schedule conflicts. For a tool with 8 parameters and no annotations, this is insufficient.
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 concise with two sentences that are front-loaded: the first states the core purpose, and the second adds behavioral context. There's no wasted text, but it could be slightly more structured by explicitly mentioning key parameters or usage scenarios.
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 complexity (8 parameters, no annotations, no output schema), the description is incomplete. It lacks details on return values, error conditions, interaction with sibling tools (e.g., how this relates to 'list_schedules'), and operational constraints. For a scheduling tool with multiple parameters, this leaves significant gaps for an AI agent.
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 63% (5 out of 8 parameters have descriptions), so the description must compensate for gaps. The description adds no specific parameter information beyond what's implied by 'cron schedule' (relating to 'cron_expression'). It doesn't explain the purpose of parameters like 'task_name', 'prompt', or 'source' in context, nor does it clarify the role of defaults like 'auto_create_pr'. Baseline 3 is appropriate as the schema does moderate 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 tool's purpose: 'Schedule a Jules task to run automatically on a cron schedule.' It specifies the verb ('schedule'), resource ('Jules task'), and key behavior ('run automatically on a cron schedule'). However, it doesn't explicitly differentiate from sibling tools like 'create_coding_task' or 'list_schedules' beyond the scheduling aspect.
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 minimal usage guidance. It mentions 'The server manages execution even when offline,' which implies reliability but doesn't specify when to use this tool versus alternatives like 'create_coding_task' for one-off tasks or 'delete_schedule' for removal. No explicit when/when-not instructions or prerequisites are provided.
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.
create_coding_taskdelete_scheduleget_session_statuslist_schedulesmanage_sessionschedule_recurring_taskScored across 6 tools
Each tool has a clearly distinct purpose with no overlap: create_coding_task initiates sessions, get_session_status monitors them, manage_session controls them, while list_schedules, schedule_recurring_task, and delete_schedule handle scheduling separately. The descriptions reinforce these boundaries, making misselection unlikely.
The tools follow a consistent verb_noun pattern with snake_case throughout, such as create_coding_task and list_schedules. However, manage_session deviates slightly by using a more generic verb compared to the others, but overall the naming is predictable and readable.
With 6 tools, the server is well-scoped for managing Jules coding sessions and scheduled tasks. Each tool earns its place by covering distinct aspects like creation, monitoring, management, and scheduling, without being overly sparse or bloated.
The tool set provides solid coverage for session lifecycle (create, status, manage) and scheduling (list, create, delete), with no dead ends. A minor gap exists in lacking a direct tool to list or delete sessions, but agents can infer status from get_session_status and deletion might be handled implicitly.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Schedule tasks for later from your AI agent: reminders, delayed webhooks, recurring jobs.
Scheduling infrastructure for AI agents across Google and Microsoft calendars.
Give your AI agents the tools to build, manage, and run automation workflows.
