Which integrations are available for this server?

Allows management of cron jobs for scheduling email sends through SendGrid.

How do I use CronGrid?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@CronGrid schedule an email to myself every day at 9am reminding me to take a break" 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.

CronGrid

by chaser164

Overview Schema Source Related Servers Discussions Admin

Python

Remote

CronGrid — an MCP server scheduling SendGrid Cron Jobs!

Description

This MCP server enables LLMs to POST, GET, and DELETE cron jobs that schedule email sends via SendGrid.

Related MCP server: Cronlytic MCP Server

Prerequisites

Claude Desktop (or another MCP server-compatible LLM interface of your choice) installed on your local machine
If using Smithery: Node.js (version 14 or higher) installed
If running locally: uv installed
SendGrid account with verified single sender email address
Cron-Job.Org account

Installation

Installing via Smithery

To install CronGrid automatically via Smithery (example for Claude Desktop):

npx -y @smithery/cli install @chaser164/sendgrid-cronjob-mcp --client claude

Installing Manually

Open your terminal or command line.
Run git clone https://github.com/chaser164/sendgrid-cronjob-mcp.git
Add the below to your MCP server-compatible interface of choice (e.g., ~/Library/Application Support/Claude/claude_desktop_config.json)

{
  "mcpServers": {
    "cronjob_email_mcp": {
      "command": "/path/to/uv",
      "args": [
        "--directory",
        "/path/to/sendgrid-cronjob-mcp",
        "run",
        "email-schedule-send-mcp-server.py"
      ],
      "env": {
        "SENDGRID_API_KEY": "<SendGrid API key>",
        "CRONJOB_API_KEY": "<Cron-Job.Org API key>",
        "FROM_EMAIL": "<SendGrid verified single sender email>"
        "TZ": "<timezone value>",
      }
      
    }
  }
}

NOTE: timezone environment variable values must be chosen from this list. The default timezone value is UTC.

Usage

Ask your LLM to create, get, and delete scheduled emails
This MCP also has the ability to get the current date/time to enhance its scheduling capabilities
If a "to email" is not specified, the mcp will send an email to yourself (e.g., "remind me to dance" will send an email to the specified SendGrid sender identity's email address)

License

This project is licensed under the MIT License.

Contributions

Contributions are welcome. Feel free to open issues or submit a pull request for feature enhancements or bug fixes.

Available Tools

4 tools

create_scheduled_email_send_at_specific_timeA

This tool creates a new scheduled email cron job at a specified date(s)/time(s) in cronjob format, setting up a cron-job that calls an email-sending API. The scheduled email can either be a one-time email or a recurring email. Never make a scheduled email cron job repeating (the final argument of the function) unless the user explicitly asks for it; assume the user wants a one-time email unless they explicitly ask for a repeating email send. If the user does not provide a to_email parameter, the email will be sent to the FROM_EMAIL environment variable (email to self). So, do not provide a to_email parameter when the user requests an email to self (e.g. "send an email to myself," "remind me to do something," "create a reminder," "send me an email," etc.). Expiration is automatically set for one-time emails. For repeating emails, expiration is up to the user; it is defaulted to 0, which means the email will be sent indefinitely. Assume the user does not want the repeated send to expire unless they explicitly ask for it. Repeated emails have a [-1] as one of the time parameters, which means the email will be sent every minute, hour, day, month, or week. Non-repeated emails only have non-negative time parameters. If the user asks for an email at a relative time, you can use the get_current_datetime tool to get the current time in the user's timezone and then use that to schedule the email. ALWAYS use the default timezone value unless the user explicitly asks for a different timezone.

Args: title: Title for the email cron job subject: Email subject body: Email body content minutes: Minutes to run (0-59, or [-1] for every minute). hours: Hours to run (0-23, or [-1] for every hour). mdays: Days of month to run (1-31, or [-1] for every day). months: Months to run (1-12, or [-1] for every month). wdays: Days of week to run (0-6 where 0=Sunday, or [-1] for every day). expires_at: Date/time (in job’s time zone) after which the job expires, i.e. after which it is not scheduled anymore (format: YYYYMMDDhhmmss, 0 = does not expire) to_email: Recipient email address. Default is None, which means the email will be sent to the FROM_EMAIL environment variable (email to self). repeating: Whether the email should be sent repeatedly. Default is False, which means the email will be sent only once.

ParametersJSON Schema

Name	Required	Default
`title`	Yes
`subject`	Yes
`body`	Yes
`minutes`	Yes
`hours`	Yes
`mdays`	Yes
`months`	Yes
`wdays`	Yes
`timezone`	No	UTC
`expires_at`	No
`to_email`	No
`repeating`	No

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, so description carries full burden. Discloses cron job creation, email API call, default behaviors, and special time parameter semantics. Lacks details on failure handling or side effects, but overall good.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but well-organized: first paragraph states purpose, then bullet-like guidelines. Each sentence adds value, though slightly verbose. Could be trimmed without losing clarity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Covers many aspects (one-time vs repeating, expiration, self-email, relative time). However, does not mention what the output schema contains (though output schema exists). Adequate for a creation tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 0%, so description fully explains all 12 parameters, including default values, special values like -1 for repeating, and behavior of to_email. Adds significant meaning beyond the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states it creates a scheduled email cron job, specifies one-time vs recurring, and distinguishes from sibling tools (delete, get). Uses specific verb 'creates' and resource 'scheduled email cron job'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit usage rules: assume one-time unless asked for repeating, default to_email to self, use get_current_datetime for relative times, expiration defaults. Clearly guides when to apply each behavior.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

delete_scheduled_emailB

Delete a specific scheduled email cron job by ID.

Args: job_id: The ID of the cron job to delete

ParametersJSON Schema

Name	Required	Description	Default
`job_id`	Yes

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

B3.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must disclose behavioral traits. It mentions deletion but does not discuss side effects (e.g., irreversibility), error conditions, or permissions required.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very concise: two lines with no wasteful text. The Args section is a minor repetition but adds structure. Every sentence serves a purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple delete operation, the description covers the essential: what it does and the required parameter. The presence of an output schema (not shown) reduces the need to explain return values. However, it could mention that the action is irreversible.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, but the description adds meaning by explaining that 'job_id' is 'The ID of the cron job to delete'. This compensates well, though more detail (e.g., how to obtain the ID) would be helpful.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Description clearly states the verb 'Delete' and the resource 'scheduled email cron job' by ID. It distinguishes from sibling tools like create and get, but does not explicitly differentiate beyond the action.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, nor any prerequisites or warnings. It simply describes the action without context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_current_datetimeA

Get the current date and time in the system's local timezone or TZ environment variable. This function will give you the full context to schedule a cron job. For example, if asked to schedule an email an hour from now, you can look at the output of this function to understand when that would be in the future. This is also useful in case the user wants to know the current time for any reason, or if you require the current time for any reason.

Returns: Formatted datetime string with timezone information

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A4.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Describes return format (formatted datetime with timezone) and no side effects; adequate for a simple read tool with no annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Mostly concise and front-loaded, though the example sentences could be slightly tightened.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Fully adequate for a zero-parameter tool with output schema; siblings clarify its distinct role.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters; description adds context beyond schema, which already provides 100% coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

Clearly states it gets current date and time, and its use for scheduling cron jobs distinguishes it from sibling email scheduling tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides explicit examples like scheduling an email or user query, but does not explicitly state when not to use or alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

get_scheduled_emailsA

Get all scheduled email cron jobs for the account.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

Output Schema

ParametersJSON Schema

Name	Required	Description
`result`	Yes

TDQS

A3.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations provided, and the description lacks details on authentication, rate limits, or behavioral traits beyond listing cron jobs.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Single sentence with no wasted words, effectively conveying the tool's purpose.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With zero parameters and an output schema, the description is mostly complete; however, it could mention that it returns all scheduled emails without filtering options.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

No parameters exist, so schema coverage is 100%. The description adds no parameter info, but also does not clarify the absence of filters or pagination.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the specific verb 'Get' and resource 'scheduled email cron jobs' with scope 'for the account', clearly distinguishing it from siblings like create and delete.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool vs alternatives; however, it is implicitly the read/list operation for scheduled emails.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

4 tool updatesv0.1.0Jun 11, 2026
- First observedcreate_scheduled_email_send_at_specific_time
- First observeddelete_scheduled_email
- First observedget_current_datetime
- First observedget_scheduled_emails

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.9/5.0

Scored 2026-06-12 14:36 across 4 tools

Disambiguation5/5

Each tool has a clearly distinct purpose: creating, deleting, listing scheduled emails, and obtaining current time for scheduling. No overlap or ambiguity.

Naming Consistency3/5

Tool names are generally verb_noun but inconsistent in verb choice and length. 'create_scheduled_email_send_at_specific_time' is overly verbose compared to the concise 'delete_scheduled_email' and 'get_scheduled_emails'. 'get_current_datetime' uses singular vs plural in other getters.

Tool Count5/5

With 4 tools covering create, delete, list, and a helper for scheduling, the count is well-suited to the domain of email cron jobs without being too sparse or excessive.

Completeness4/5

The tool set covers primary CRUD operations (create, delete, list) and includes a helpful utility (get_current_datetime). Missing update/modify capability is a minor gap, but core functionality is present.

Maintenance

ActivityInactive

ResponsivenessNo issues

Resources

GitHub Repository

Need Help?

Related Servers

Related MCP Connectors

email A
dev.primitive
Email infrastructure for AI agents — send, receive, search, and reply to email over MCP.
Email Communication
302
nylas A
io.usefulapi
MCP server for Nylas — read email, calendars, events and contacts, and send email or create events.
Email Calendar Management CRM
152
jumpcloud-genaiOAuth
com.jumpcloud
An MCP server that provides an API to LLMs to manage their JumpCloud resources.
Cloud Platforms Security Developer Tools
2
Zyntra - Temp e-mails MCP A
app.zyntra.mcp
MCP server for e-mail testing: create disposable inboxes, wait for delivery, and extract e-mail content or links - all from your AI agent or test automation workflow. Get a free API key on https://app.zyntra.app/
Developer Tools Email Testing & QA Tools
2

Related MCP Servers

MCP Email Server with SendGrid
Communication App Automation
wojkos
F
license
Not graded
quality
D
maintenance
An MCP server that enables AI applications to send text, HTML, and template-based emails using SendGrid. It supports file attachments, CC/BCC recipients, and easy deployment via Python or Docker.
Updated 8 months ago (2026-01-19 11:57 UTC)
-
Cronlytic MCP Serverofficial
App Automation Monitoring Observability
Cronlytic
A
license
Not graded
quality
D
maintenance
A comprehensive Model Context Protocol (MCP) server that integrates with the Cronlytic API to provide seamless cron job management through LLM applications like Claude Desktop.
Updated a year ago (2025-06-07 17:40 UTC)
1
MIT
sendook-mcp
Email Communication
StreamlinedStartup
A
license
A
quality
D
maintenance
MCP server for Sendook - an AI email communication platform. Enables AI agents to send and receive emails, manage inboxes, threads, and webhooks programmatically.
Updated 8 months ago (2026-02-01 06:27 UTC)
16
MIT
email-mcp
Email Communication
yashjoshiatgit
A
license
Not graded
quality
D
maintenance
A production-ready MCP server that empowers AI agents to securely send emails via SMTP, supporting plain text, HTML, and attachments.
Updated 7 months ago (2026-03-04 10:29 UTC)
MIT

CronGrid — an MCP server scheduling SendGrid Cron Jobs!

Description

Prerequisites

Installation

Installing via Smithery

Installing Manually

Usage

License

Contributions

Available Tools

Output Schema

Output Schema

Output Schema

Output Schema

Tool Schema Changelog

Maintenance

Resources

Related MCP Connectors

Related MCP Servers

Cronlytic MCP Serverofficial