The Jules MCP Server enables AI assistants to delegate coding tasks to Google Jules and manage recurring automated workflows, with security and human oversight built in.
Create coding tasks (create_coding_task): Submit natural language instructions (bug fixes, refactoring, tests, features) to a GitHub repository, with options to auto-create a Pull Request and/or require plan approval before any code changes are made.
Check session status (get_session_status): Retrieve the current state of a Jules session (e.g., PLANNING, IN_PROGRESS, COMPLETED) using its session ID.
Manage active sessions (manage_session): Approve a generated plan (approve_plan) or send feedback (send_message) to guide Jules's work, implementing human-in-the-loop control.
Schedule recurring tasks (schedule_recurring_task): Set up cron-based automated workflows (e.g., weekly dependency updates, security audits) with timezone support that persist through server restarts.
List schedules (list_schedules): View all locally managed recurring scheduled tasks and their execution history.
Delete a schedule (delete_schedule): Remove a previously created recurring task by name.
Security & control: Restrict operations to a repository allowlist, store scheduled tasks with AES-256-GCM encryption, and use require_plan_approval to ensure no code changes happen without explicit human consent.
Integrations: Connect to Claude, VS Code/Cursor, and other MCP-compatible tools for natural language task delegation.
Enables management of GitHub repositories through Google Jules, allowing automated code modifications, PR creation, and scheduling of maintenance tasks for connected GitHub repositories.
Provides integration with Google Jules API for autonomous coding tasks, enabling creation and management of coding sessions, plan approval workflows, and scheduling of recurring development tasks like dependency updates and security audits in connected GitHub repositories.
Click on "Install Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Jules MCP Server schedule weekly dependency updates for my-app-backend every Monday at 9 AM"
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
Activepieces Integration - Use the included Jules piece (pieces/jules) to automate coding tasks in your Activepieces workflows
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.enc
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
npm 9.0.0 or higher
Jules API Key - Generate at jules.google/settings
GitHub Repositories - Ensure your repositories are connected to Jules and the GitHub app is installed.
# 1. Clone the repository
git clone https://github.com/savethepolarbears/jules-mcp-server.git
cd jules-mcp-server
# 2. Install dependencies
npm install
# 3. Configure environment
# Copy example env and fill in your JULES_API_KEY
cp .env.example .env
# 4. Verify the setup
npm run lint
npm run typecheck
npm run test
# 5. Build the project and run a smoke test to verify connectivity
npm run mcp:smokeAfter building and setting JULES_API_KEY, you can validate the server end-to-end:
npm run mcp:smokeExpected output (with a valid key):
Lists 11 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 - Your Jules API Key
JULES_API_KEY=your_jules_api_key_here
# Strongly Recommended - Encryption key for local schedules
# Using JULES_API_KEY as fallback means rotating your API key will make all scheduled tasks unreadable.
# Generate: node -e "console.log(require('crypto').randomBytes(32).toString('hex'))"
JULES_ENCRYPTION_KEY=your_strong_random_key_here
# Required for create_coding_task. Comma-separated list of authorized repositories.
JULES_ALLOWED_REPOS=owner/repo1,owner/repo2
# Optional - Default branch for coding tasks
JULES_DEFAULT_BRANCH=mainThis server is designed with a "security-first" approach to protect your repositories and data:
Restrictive File Permissions: Local schedule storage (~/.jules-mcp) uses 0o700 directory permissions and 0o600 file permissions, ensuring only the owner can read or write task data.
Encrypted Local State: All scheduled tasks are stored using AES-256-GCM encryption. A unique, random 16-byte salt is generated for every write operation to prevent offline attacks and ensure data integrity.
PII Leak Prevention: Raw Jules API responses are sanitized and truncated (max 500 characters) before being included in logs or exceptions, preventing accidental disclosure of proprietary code or personal information in system logs.
Generic Validation Errors: The server returns generic error messages when repository validation fails, preventing the enumeration of your private repository allowlist.
Human-in-the-Loop: Use the require_plan_approval: true flag to ensure Jules never modifies code without your explicit review and approval of the generated plan.
Add 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.enc
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
The server has migrated from plain JSON storage (schedules.json) to encrypted storage (schedules.enc).
Auto-Migration: Upon startup, if schedules.json is detected, the server automatically encrypts its contents and saves them to schedules.enc, then deletes the unencrypted file.
Backwards Compatibility: No manual action is required if you are upgrading from a version that used schedules.json.
Detailed documentation has been moved to the docs/ folder:
API Reference - Complete details on available MCP Tools, Resources, and Prompts.
Architecture - System design and the "Thick Server" pattern.
Configuration - Environment variables and setup instructions.
Examples - Example workflows and usage patterns.
Quickstart - A fast guide to getting up and running.
Activepieces Integration - Documentation for the custom Google Jules Activepieces integration.
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.
When integrating with autonomous AI agents like OpenClaw or Codex, additional safety measures are enforced:
Auto-PR Defaults: Prompt templates now encourage setting auto_create_pr: true to ensure all AI-driven changes are reviewed as Pull Requests before merging.
Mandatory Review: It is strongly recommended to set require_plan_approval: true for tasks generated by other AI systems to establish trust before allowing direct changes.
Quota-Aware Scheduling: To respect API limits and prevent unintended runaway tasks, the cron engine validates all schedules. Schedules must not run more frequently than once per hour. Daily or weekly intervals are highly recommended for automated maintenance.
Resilient Storage: Local schedules are saved using atomic file writes with corrupted-state backups to prevent the server from crashing during unexpected failures.
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.enc exists and is writable.
npm run typecheckThis project uses JSDoc for comprehensive code documentation. Every public function, method, and class is documented with clear descriptions of purpose, parameters, and return values.
To explore the architecture and API details, check the docs/ directory.
We use Vitest for unit and integration testing.
# Run all tests
npm test
# Run tests in watch mode
npm run test:watch
# Generate coverage report
npm run test:coveragesrc/
types/ # TypeScript type definitions (Jules API & local state)
api/ # Jules API client layer with retry logic
storage/ # Secure persistence layer (encrypted JSON)
scheduler/ # Cron engine for recurring task management
mcp/ # MCP protocol layer (tools, resources, prompts)
utils/ # Security, rate limiting, and string utilities
index.ts # Server entry point and MCP handler setup
pieces/ # Activepieces integration (Google Jules piece)npm 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.
Most tools have distinct purposes, but 'create_coding_task' and 'schedule_recurring_task' could be confused as both initiate tasks, though one is immediate and the other scheduled. The other tools (delete_schedule, get_session_status, list_schedules, manage_session) are clearly differentiated by their specific actions on sessions or schedules.
All tools follow a consistent verb_noun pattern with snake_case (e.g., create_coding_task, delete_schedule, get_session_status). The naming is predictable and readable across all six tools, making it easy for agents to understand their functions.
With 6 tools, the server is well-scoped for managing Jules coding sessions and scheduled tasks. Each tool serves a clear purpose (e.g., creation, deletion, listing, status checking, management), and there are no redundant or trivial tools, making the count appropriate for the domain.
The toolset covers core operations for sessions (create, get status, manage) and schedules (list, delete, schedule recurring), but there is a minor gap: no tool explicitly updates or modifies existing scheduled tasks beyond deletion. However, agents can work around this by deleting and re-creating schedules, so coverage is largely complete for the apparent domain.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Connect AI assistants to GitHub - manage repos, issues, PRs, and workflows through natural language.
Adaptive plan/build/review cycles for AI coding assistants, persisted across sessions.
Build agents to automate any background task. Works with your ChatGPT/Claude subscription.
Coordination hub for AI coding agents: message teammates, ask humans, audit every event.
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/savethepolarbears/jules-mcp-server'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
