Skip to main content
Glama
cronty-com

Cronty MCP

Official
by cronty-com
OverviewSchemaRelated ServersScoreDiscussions
Python
Hybrid

Cronty MCP

A FastMCP server that enables AI agents to schedule notifications and reminders via Upstash QStash and NTFY.

Features

  • Instant Push Notifications - Send immediate notifications with rich formatting, actions, and attachments

  • One-off Scheduled Notifications - Schedule notifications for a specific future time using ISO 8601, date/time/timezone, or delay format

  • Recurring Cron Notifications - Create persistent schedules using standard cron syntax

Related MCP server: AgentCron

Available Tools

Tool

Description

send_push_notification

Send an immediate push notification

schedule_notification

Schedule a one-off notification for a future time

schedule_cron_notification

Schedule recurring notifications using cron syntax

list_scheduled_notifications

List all recurring cron schedules (optionally filter by topic)

pause_schedule

Temporarily pause a cron schedule

resume_schedule

Resume a paused cron schedule

delete_schedule

Permanently delete a cron schedule

Prerequisites

  • Python 3.13+

  • uv package manager

  • Docker Desktop 4.58+ (for Docker Sandboxes with microVM isolation)

  • Upstash QStash account and token

  • NTFY topic for receiving notifications (passed as notification_topic parameter to each tool)

Quickstart

1. Clone and Setup

git clone https://github.com/your-org/cronty-mcp.git
cd cronty-mcp
uv sync

2. Configure Environment

cp .env.example .env

Edit .env with your credentials:

QSTASH_TOKEN=your_qstash_token_here

# For local development without auth:
AUTH_DISABLED=true

# Or for production with auth:
# JWT_SECRET=your_secret_here  # Generate with: openssl rand -base64 48

Note: The NTFY topic is now specified per-request via the notification_topic parameter on each tool call, enabling multi-user and multi-tenant deployments.

3. Run the Server

uv run fastmcp run server.py

For development with the MCP Inspector:

uv run fastmcp dev server.py

Authentication

Cronty MCP supports bearer token authentication using JWT tokens signed with HS512.

Generating a JWT Secret

Generate a secure secret (minimum 64 characters):

# macOS/Linux
openssl rand -base64 48

# Or using Python
python -c "import secrets; print(secrets.token_urlsafe(48))"

Add the secret to your .env:

JWT_SECRET=your_generated_secret_here

Issuing Tokens

Issue tokens for users via CLI:

uv run python -m cronty token issue --email user@example.com

With custom expiration:

uv run python -m cronty token issue --email user@example.com --expires-in 30d

Supported duration formats: 30d, 12h, 1y, 365d

Disabling Authentication

For local development, disable auth by setting:

AUTH_DISABLED=true

Agent Configuration (Local Mode)

Configure your AI agent to connect to the local MCP server.

Note: These configurations run the server locally with AUTH_DISABLED=true for development.

Claude Code

Add to your project's .mcp.json:

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"]
    }
  }
}

Or use the CLI:

claude mcp add cronty-mcp -- uv run fastmcp run server.py

Claude Desktop

Add to your Claude Desktop configuration file:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"],
      "cwd": "/path/to/cronty-mcp"
    }
  }
}

Cursor

Add to your Cursor MCP configuration (.cursor/mcp.json in your project or global settings):

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"],
      "cwd": "/path/to/cronty-mcp"
    }
  }
}

VS Code

Add to your VS Code settings (.vscode/mcp.json or user settings):

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"],
      "cwd": "/path/to/cronty-mcp"
    }
  }
}

Windsurf

Add to your Windsurf MCP configuration (~/.windsurf/mcp.json or project-level):

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"],
      "cwd": "/path/to/cronty-mcp"
    }
  }
}

Codex CLI

codex mcp add cronty-mcp -- uv run fastmcp run server.py

Gemini CLI

gemini mcp add cronty-mcp -- uv run fastmcp run server.py

FastMCP Cloud Deployment

When deployed to FastMCP Cloud, you can connect to your server using bearer token authentication.

Replace your-hostname with your actual FastMCP Cloud hostname (e.g., your-app-name.fastmcp.app).

Note: Bearer token authentication is a temporary solution for clients that don't yet support OAuth 2.0 Dynamic Client Registration (DCR). OAuth with DCR support via WorkOS/Authkit is planned as the preferred authentication method.

Environment Setup

Set your bearer token as an environment variable:

export CRONTY_TOKEN="your-token-here"

Issuing Tokens for Cloud Users

Before connecting, issue a token for each user:

uv run python -m cronty token issue --email user@example.com

Users will need this token to authenticate with the cloud-deployed server.

Obsidian

In the Obsidian MCP plugin settings, add a new server:

Field

Value

Server name

Cronty

Server URL

https://your-hostname.fastmcp.app/mcp

Authentication

Bearer Token

Token

(paste token from CLI)

Claude Code

Using CLI:

claude mcp add --transport http cronty-mcp https://your-hostname.fastmcp.app/mcp \
  --header "Authorization: Bearer ${CRONTY_TOKEN}"

Or add to .mcp.json:

{
  "mcpServers": {
    "cronty-mcp": {
      "type": "http",
      "url": "https://your-hostname.fastmcp.app/mcp",
      "headers": {
        "Authorization": "Bearer ${CRONTY_TOKEN}"
      }
    }
  }
}

Claude Desktop

Claude Desktop requires the mcp-remote wrapper to add custom headers. Add to claude_desktop_config.json:

  • macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

  • Windows: %APPDATA%\Claude\claude_desktop_config.json

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "npx",
      "args": [
        "mcp-remote@latest",
        "https://your-hostname.fastmcp.app/mcp",
        "--header",
        "Authorization: Bearer YOUR_TOKEN"
      ]
    }
  }
}

Replace YOUR_TOKEN with your actual token from the CLI.

Codex CLI

Edit ~/.codex/config.toml:

[mcp_servers.cronty-mcp]
url = "https://your-hostname.fastmcp.app/mcp"
bearer_token_env_var = "CRONTY_TOKEN"

Then set the environment variable before running Codex.

Gemini CLI

Using CLI:

gemini mcp add cronty-mcp https://your-hostname.fastmcp.app/mcp \
  --transport http \
  --header "Authorization: Bearer ${CRONTY_TOKEN}"

Or edit settings.json:

{
  "mcpServers": {
    "cronty-mcp": {
      "httpUrl": "https://your-hostname.fastmcp.app/mcp",
      "headers": {
        "Authorization": "Bearer ${CRONTY_TOKEN}"
      }
    }
  }
}

Cursor

Add to .cursor/mcp.json:

{
  "mcpServers": {
    "cronty-mcp": {
      "url": "https://your-hostname.fastmcp.app/mcp",
      "headers": {
        "Authorization": "Bearer ${env:CRONTY_TOKEN}"
      }
    }
  }
}

Note: Cursor uses ${env:VAR} syntax for environment variables.

VS Code

Add to .vscode/mcp.json:

{
  "inputs": [
    {
      "type": "promptString",
      "id": "cronty-token",
      "description": "Cronty MCP Bearer Token",
      "password": true
    }
  ],
  "servers": {
    "cronty-mcp": {
      "type": "http",
      "url": "https://your-hostname.fastmcp.app/mcp",
      "headers": {
        "Authorization": "Bearer ${input:cronty-token}"
      }
    }
  }
}

VS Code will securely prompt for your token on first use.

FastMCP Python Client

import asyncio
from fastmcp import Client
from fastmcp.client.auth import BearerAuth

client = Client(
    "https://your-hostname.fastmcp.app/mcp",
    auth=BearerAuth("your-token-here")
)

async def main():
    async with client:
        await client.ping()

        tools = await client.list_tools()

        result = await client.call_tool(
            "send_push_notification",
            {"message": "Hello from Cronty!"}
        )
        print(result)

asyncio.run(main())

OpenAI SDK

import os
from openai import OpenAI

client = OpenAI()

resp = client.responses.create(
    model="gpt-4.1",
    tools=[
        {
            "type": "mcp",
            "server_label": "cronty-mcp",
            "server_url": "https://your-hostname.fastmcp.app/mcp",
            "headers": {
                "Authorization": f"Bearer {os.environ['CRONTY_TOKEN']}"
            },
            "require_approval": "never",
        },
    ],
    input="Send me a test notification",
)

OAuth Authentication (Coming Soon)

OAuth 2.0 with Dynamic Client Registration (DCR) support via WorkOS/Authkit is planned. This will enable:

  • Automatic token refresh

  • Secure authorization flows

  • No manual token management

Clients with native OAuth DCR support (Claude Code, VS Code, Cursor) will be able to authenticate without bearer tokens once implemented.

Evaluations

Run evaluations against your MCP server using Claude to verify tool effectiveness.

Setup

Add your Anthropic API key to .env:

# In .env
ANTHROPIC_EVAL_API_KEY=your_api_key_here

Note: Requires an Anthropic API key from console.anthropic.com. Claude Max subscription does not include API access. The evaluation harness uses ANTHROPIC_EVAL_API_KEY (not ANTHROPIC_API_KEY) to avoid accidental charges when using Claude Code with a different billing setup.

Create an Evaluation File

Create an XML file with question-answer pairs (see evaluation.xml for examples):

<evaluation>
   <qa_pair>
      <question>Use the send_push_notification tool with message "test" and notification_topic "demo". Did it succeed? Answer: Yes or No.</question>
      <answer>Yes</answer>
   </qa_pair>
</evaluation>

Run Evaluations

From Project Root

uv run python plugins/fastmcp-builder/skills/fastmcp-builder/scripts/evaluation.py \
    -c "uv run fastmcp run server.py" \
    evaluation.xml

Against HTTP server:

uv run python plugins/fastmcp-builder/skills/fastmcp-builder/scripts/evaluation.py \
    -t http \
    -u https://your-hostname.fastmcp.app/mcp \
    evaluation.xml

With custom model and output:

uv run python plugins/fastmcp-builder/skills/fastmcp-builder/scripts/evaluation.py \
    -c "uv run fastmcp run server.py" \
    -m claude-sonnet-4-20250514 \
    -o report.md \
    evaluation.xml

From Scripts Directory (Alternative)

If you don't want evaluation dependencies in your project:

cd plugins/fastmcp-builder/skills/fastmcp-builder/scripts
uv sync
uv run python evaluation.py \
    -c "uv run fastmcp run server.py" \
    --cwd ../../../../.. \
    ../../../../../evaluation.xml

Evaluation Guidelines

  • Questions must be READ-ONLY, INDEPENDENT, NON-DESTRUCTIVE, IDEMPOTENT

  • Answers must be single, verifiable values (not lists or objects)

  • Answers must be STABLE (won't change over time)

  • Create challenging questions that require multiple tool calls

See plugins/fastmcp-builder/skills/fastmcp-builder/reference/evaluation.md for the complete guide.

Development

Install Dependencies

uv sync

Run Tests

uv run pytest

Linting

uv run ruff check .
uv run ruff check . --fix
uv run ruff format .

Testing with Claude Code

Local Mode (stdio)

For local development, use stdio transport with auth disabled. Set in .env:

AUTH_DISABLED=true

The repo includes .mcp.json for local testing:

{
  "mcpServers": {
    "cronty-mcp": {
      "command": "uv",
      "args": ["run", "fastmcp", "run", "server.py"]
    }
  }
}

Then run Claude Code from this directory - it will automatically detect the MCP server.

Cloud Mode (HTTP with bearer token)

To test against FastMCP Cloud deployment:

  1. Set your token:

    export CRONTY_TOKEN="your-token-here"

  2. Update .mcp.json to use HTTP transport:

    {
  "mcpServers": {
    "cronty-mcp": {
      "type": "http",
      "url": "https://your-hostname.fastmcp.app/mcp",
      "headers": {
        "Authorization": "Bearer ${CRONTY_TOKEN}"
      }
    }
  }
}

  3. Run Claude Code with the env var set.

Claude Code with Docker Sandboxes

Run Claude Code in an isolated Docker container with all dependencies pre-installed.

Requires Docker Desktop 4.58+ with microVM-based sandboxes.

Migrating from Docker Desktop < 4.58

If upgrading from an older Docker Desktop version, remove old container-based sandboxes first:

# Remove old sandbox containers
docker rm -f $(docker ps -q -a --filter="label=docker/sandbox=true")

# Remove credential volume
docker volume rm docker-claude-sandbox-data

Build the Custom Template

docker build -t cronty-dev .

Set Environment Variables

Docker Sandboxes run via a daemon that reads environment variables from your shell config files. Add these to ~/.zshrc or ~/.bashrc:

# Required
export QSTASH_TOKEN=your_qstash_token_here
export AUTH_DISABLED=true  # For development mode

# Optional (for production/evaluations)
export JWT_SECRET=your_jwt_secret_here           # Required if AUTH_DISABLED is not set
export ANTHROPIC_EVAL_API_KEY=your_api_key_here  # Required for running evaluations

After adding, apply changes and restart Docker Desktop:

source ~/.zshrc  # or ~/.bashrc
# Then restart Docker Desktop for the daemon to pick up new variables

Run Claude Code in Sandbox

# Run with custom template
docker sandbox run --template cronty-dev --load-local-template claude .

# Continue a previous conversation
docker sandbox run --template cronty-dev --load-local-template claude . -- -c

# With a direct prompt
docker sandbox run --template cronty-dev --load-local-template claude . -- -p "Run the tests"

# Run with a named sandbox (for persistence)
docker sandbox run --name cronty --template cronty-dev --load-local-template claude .

Claude Settings in Sandbox

Global Claude settings (~/.claude/settings.json) are not available inside the sandbox due to security restrictions. To use custom settings (hooks, permissions, preferences), create a local settings file in the project:

# Create local settings file
cp ~/.claude/settings.json .claude/settings.local.json

The .claude/settings.local.json file is mounted with the project and will be used by Claude Code inside the sandbox.

Available Commands Inside Sandbox

All uv commands work inside the sandbox:

uv run pytest                    # Run tests
uv run fastmcp dev server.py     # Start dev server with MCP Inspector
uv run ruff check .              # Lint code
uv add some-package              # Add dependencies

What's Included

The Docker Sandbox template includes:

  • Claude Code with automatic credential handling

  • Python 3.13 with uv package manager

  • All project dependencies pre-installed

  • Docker CLI, GitHub CLI, Git, Node.js, Go

  • Non-root agent user with sudo privileges

Plugin Marketplace

This repository includes the fastmcp-builder skill as a Claude Code plugin, providing comprehensive guidance for building production-quality MCP servers with FastMCP.

Installation

  1. Add the marketplace:

    /plugin marketplace add cronty-com/cronty-mcp

  2. Install the plugin:

    /plugin install fastmcp-builder@cronty-plugins

Usage

Invoke the skill to get guidance on building FastMCP servers:

/fastmcp-builder

The plugin includes:

  • SKILL.md - Comprehensive 4-phase guide for building MCP servers (research, implementation, review, evaluation)

  • reference/best-practices.md - Naming conventions, response formats, security patterns

  • reference/python-guide.md - Pydantic v2 patterns, async operations, pagination

  • reference/evaluation.md - Guide for creating evaluation test suites

  • scripts/evaluation.py - Evaluation harness for testing MCP servers with Claude

For running evaluations, see the Evaluations section above.

License

MIT

Available Tools

8 tools
delete_scheduleA

Delete a scheduled notification by its ID.

Permanently removes a cron schedule. The schedule will stop firing and cannot be recovered. Use the schedule_id returned from schedule_cron_notification.

ParametersJSON Schema
NameRequiredDescriptionDefault
schedule_idYesThe schedule ID to delete. This ID is returned when creating a cron schedule.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, description fully discloses irreversible deletion ('Permanently removes', 'cannot be recovered', 'will stop firing'). Could mention permissions or error conditions, but sufficient for a simple delete.

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?

Three concise sentences with no redundancy. First sentence states action, second explains permanence, third gives parameter source. Each sentence earns its place.

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 one-parameter tool with output schema, description covers purpose, irreversibility, and parameter source. Missing details like return value or error handling, but schema and simplicity suffice.

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 covers parameter fully (100%). Description adds value by specifying that schedule_id comes from schedule_cron_notification, providing provenance information beyond 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?

Clearly states 'Delete a scheduled notification by its ID', specifying verb and resource. Distinguishes from siblings like pause_schedule (temporary) and schedule_cron_notification (creation).

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?

Explicitly says to use schedule_id from schedule_cron_notification, indicating when to use. Lacks explicit contraindications like 'do not use if you want to temporarily disable', but context is clear.

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

get_current_timeA

Get the current date and time in UTC.

Returns the current UTC timestamp in ISO 8601 format, useful for scheduling notifications or including timestamps in messages.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.5/5.0
Behavior4/5

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

Specifies output format (ISO 8601) and nature (current UTC timestamp, read-only), which is sufficient given 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.

Conciseness5/5

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

Two efficient sentences, front-loaded with purpose, followed by additional value. No wasted words.

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?

For a zero-parameter tool with an output schema (presumably containing the timestamp), the description covers behavior, format, and use cases adequately.

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; baseline 4 per guidelines. Description adds context about output format but that is not parameter-related.

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 verb+resource ('get current date and time in UTC'), distinct from sibling tools which all involve scheduling/notifications.

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?

Describes use cases ('scheduling notifications' and 'including timestamps'), but does not explicitly contrast with alternatives (though none exist).

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

list_scheduled_notificationsA

List scheduled recurring notifications.

Returns all recurring cron notification schedules. Optionally filter by a specific notification topic.

Note: One-off scheduled notifications (created with schedule_notification) are not included as they are pending messages, not recurring schedules.

ParametersJSON Schema
NameRequiredDescriptionDefault
notification_topicNoOptional: filter to show only schedules for this notification topic. If not provided, returns all scheduled notifications. Format: lowercase alphanumeric with dashes (e.g., 'my-alerts')

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.3/5.0
Behavior4/5

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

No annotations are provided, so the description carries the burden. It accurately describes the tool's behavior: returns all recurring schedules, optionally filtered by topic, and explicitly excludes one-off notifications. This adds value beyond the schema without contradictions.

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?

Three concise sentences: first states purpose, second defines scope, third clarifies exclusion. No redundancy, every sentence adds value. Well-structured and front-loaded.

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?

With one optional parameter and an output schema, the description is complete. It sufficiently explains the tool's function and filtering capability, leaving no critical gaps for an agent to understand usage.

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

Parameters3/5

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

Schema coverage is 100% with one parameter fully described. The description only restates that filtering is optional, adding minimal extra meaning. Baseline 3 is appropriate as the schema already covers details.

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 the tool lists scheduled recurring notifications, differentiating from one-off notifications. The verb 'list' and resource 'recurring cron notification schedules' are specific, and the note about exclusions distinguishes it from sibling tools like schedule_notification.

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?

The description clarifies the tool returns recurring schedules, not one-off notifications, and mentions optional filtering. It implicitly guides when to use this tool versus schedule_notification, but lacks explicit exclusion guidance for other siblings like delete_schedule or pause_schedule.

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

pause_scheduleA

Pause a scheduled notification.

Temporarily stops a cron schedule from firing. The schedule configuration is preserved and can be resumed later. Use the schedule_id returned from schedule_cron_notification.

ParametersJSON Schema
NameRequiredDescriptionDefault
schedule_idYesThe schedule ID to pause. This ID is returned when creating a cron schedule.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.1/5.0
Behavior4/5

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

No annotations provided, but description discloses temporary behavior, preservation of config, and ability to resume. Does not mention potential side effects like dropped notifications or permissions.

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?

Three concise, informative sentences. Front-loaded with purpose, then details, then source of ID. No wasted words.

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?

Given the simplicity of the tool (one param, with output schema), description covers the essential behavior. Could mention idempotency or error cases, but not critical.

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?

Only one parameter (schedule_id), fully described in schema. Description adds value by specifying where to obtain the ID (from schedule_cron_notification).

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?

States 'Pause a scheduled notification' clearly, with verb and resource. Mentions temporary stop and resumption, distinguishing from deletion. However, does not explicitly contrast with delete_schedule or other siblings.

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?

Implies usage after creating a schedule to temporarily stop it, and notes resumability. No explicit 'when not to use' or comparison with alternatives like delete_schedule.

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

resume_scheduleA

Resume a paused scheduled notification.

Reactivates a paused cron schedule. The schedule will resume firing at its next scheduled time. Use the schedule_id returned from schedule_cron_notification.

ParametersJSON Schema
NameRequiredDescriptionDefault
schedule_idYesThe schedule ID to resume. This ID is returned when creating a cron schedule.

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

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

With no annotations, the description explains that the schedule will resume firing at its next scheduled time. However, it does not disclose edge cases (e.g., invalid schedule_id, already running schedule) or potential side effects, leaving gaps in transparency.

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?

Two short, focused sentences provide the core action and key usage hint. No wordiness; 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 tool with one parameter and an output schema, the description adequately explains the function. It lacks return value details, but the output schema likely covers that.

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 coverage is 100%, and the description adds value by stating to use the schedule_id from schedule_cron_notification, which aids correct invocation beyond the schema's parameter description.

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 the verb 'Resume' and the resource 'paused scheduled notification'/'cron schedule'. It specifies using the schedule_id from schedule_cron_notification, distinguishing it from siblings like pause_schedule and delete_schedule.

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?

The description provides context for when to use the tool (resuming a paused schedule) and references the source of the schedule_id. It does not explicitly state when not to use it or compare with alternatives, but the sibling tool names imply the scope.

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

schedule_cron_notificationA

Schedule a recurring notification using cron syntax.

Creates a persistent schedule that fires according to the cron pattern. The schedule continues indefinitely until deleted via the Upstash panel.

The agent should determine the user's timezone by:

  1. Checking system/environment timezone information

  2. If unavailable, asking the user explicitly

ParametersJSON Schema
NameRequiredDescriptionDefault
cronYesStandard 5-field cron expression. Fields: minute hour day-of-month month day-of-week. Examples: '0 9 * * 1' (Mondays 9am), '30 8 * * 1-5' (weekdays 8:30am), '0 0 1 * *' (monthly)
labelNoOptional label for identifying this schedule in the Upstash dashboard logs. Only alphanumeric, hyphen, underscore, or period allowed. Examples: 'daily-standup', 'weekly_report', 'reminder.v1'
messageYesThe notification text to send
timezoneYesIANA timezone for the cron schedule. Check the user's system timezone first. If unavailable, ask the user for their timezone. Examples: Europe/Warsaw, Europe/London, America/New_York, America/Los_Angeles, Asia/Tokyo, Asia/Shanghai, Australia/Sydney, UTC
notification_topicYesThe notification topic to send to. Format: lowercase alphanumeric with dashes (e.g., 'my-alerts', 'user-123-notifications')

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries behavioral disclosure burden. It explains persistence and indefinite continuation until manual deletion, but does not cover failure modes, rate limits, or delivery confirmation.

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?

Description is front-loaded with the core purpose, followed by concise behavioral and usage details. Each sentence adds value with no redundancy.

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 main behavioral points (persistence, timezone handling) and parameter details. Lacks return value explanation, but output schema exists. Adequate for a scheduling tool with good schema coverage.

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 descriptions cover 100% of parameters, and the description adds extra value with cron examples, label format rules, and timezone examples. The timezone determination procedure is also explained, going beyond bare 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?

Name and description clearly state the tool's action: scheduling a recurring notification using cron syntax. It distinguishes from siblings like schedule_notification (likely one-time) and send_push_notification (immediate) by specifying recurring nature.

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?

Description provides explicit guidance on timezone determination (check system, then ask user) and notes that schedules persist until deleted. While it doesn't explicitly contrast with one-time scheduling, the context implies when to use this tool over alternatives.

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

schedule_notificationA

Schedule a one-off notification for a future time.

Supports three input modes (use only one):

  1. datetime: ISO 8601 format (e.g., 2025-01-15T09:00:00+01:00)

  2. date + time + timezone: Separate parameters

  3. delay: QStash delay format (e.g., 1d, 2h30m, 1d10h30m50s)

ParametersJSON Schema
NameRequiredDescriptionDefault
dateNoDate in YYYY-MM-DD format. Defaults to today if omitted.
timeNoTime in HH:MM format
delayNoQStash delay format (e.g., "1d", "2h30m", "1d10h30m")
messageYesThe notification text to send
datetimeNoISO 8601 datetime with timezone
timezoneNoIANA timezone (required with date+time). Check the user's system timezone first. If unavailable, ask the user for their timezone. Examples: Europe/Warsaw, Europe/London, America/New_York, America/Los_Angeles, Asia/Tokyo, Asia/Shanghai, Australia/Sydney, UTC
notification_topicYesThe notification topic to send to. Format: lowercase alphanumeric with dashes (e.g., 'my-alerts', 'user-123-notifications')

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

A4.2/5.0
Behavior3/5

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

No annotations provided, so description carries full burden. Details input modes and formats but does not disclose success/failure behavior, side effects, or required permissions. Adequate but could be more transparent.

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?

Concise, well-structured with bullet points. Front-loads purpose then details modes. Every sentence adds value. No wasted words.

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?

Output schema exists, so return values are documented elsewhere. Covers all 7 parameters, explains exclusive modes, and provides necessary format details. Minor gaps like max delay duration, but overall complete for the tool's complexity.

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 100%, baseline 3. Description adds significant value by grouping parameters into modes, clarifying exclusivity, and providing format examples (ISO 8601, QStash delay).

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 'Schedule a one-off notification for a future time.' Specifies verb, resource, and time constraint. Distinguishes from siblings like schedule_cron_notification (recurring) and send_push_notification (immediate).

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?

Explicitly describes three input modes and states 'use only one.' Provides format examples. Agent can infer when to use this vs. siblings (cron for recurring, send_push for immediate). Lacks explicit exclusions but clear enough.

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

send_push_notificationC

Send an immediate push notification.

Sends a push notification for instant delivery. Only a message is required; all other parameters are optional.

ParametersJSON Schema
NameRequiredDescriptionDefault
iconNoURL of custom notification icon
tagsNoList of tags/emoji shortcodes
clickNoURL to open when notification is tapped
titleNoNotification title
attachNoURL of file to attach
actionsNoAction buttons (max 3)
messageYesThe notification body text
filenameNoFilename for attachment
markdownNoEnable markdown formatting
priorityNoPriority 1-5 (1=min, 3=default, 5=urgent)
notification_topicYesThe notification topic to send to. Format: lowercase alphanumeric with dashes (e.g., 'my-alerts', 'user-123-notifications')

Output Schema

ParametersJSON Schema
NameRequiredDescription

No output parameters

TDQS

C2.7/5.0
Behavior2/5

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

No annotations are provided, so the description carries full burden. It mentions immediate delivery and that most parameters are optional (though inaccurate about required ones), but lacks details on success behavior, side effects, or idempotency.

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?

Two short, focused sentences with no wasted words, though the first sentence is slightly redundant with the title.

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

Completeness2/5

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

Given 11 parameters and an output schema, the description lacks usage context, examples, and correctly identifying required fields. It does not explain the topic format or how to use optional parameters effectively.

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

Parameters2/5

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

Schema description coverage is 100%, so baseline is 3. However, the description's claim that 'only a message is required' contradicts the schema which also requires notification_topic, thereby adding confusion rather than value.

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

Purpose4/5

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

The description clearly states the tool sends an immediate push notification, differentiating it from scheduling siblings. However, it incorrectly claims only message is required, while the schema also requires notification_topic.

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?

Only implicit guidance via 'immediate' to distinguish from scheduled tools; no explicit when-to-use or when-not-to-use advice.

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

Install Server
RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A3.8/5.0
Disambiguation5/5

Each tool has a clearly distinct purpose: scheduling (recurring vs one-off), immediate push, time retrieval, and lifecycle management (delete, pause, resume, list). There is no ambiguity between tools.

Naming Consistency5/5

All tool names follow a consistent verb_noun pattern with snake_case (e.g., delete_schedule, get_current_time, send_push_notification). The naming is predictable and easy to understand.

Tool Count5/5

8 tools cover the core functionality of a notification scheduling server. The number feels well-scoped—not too few to miss essential operations, not too many to overwhelm.

Completeness3/5

Recurring schedule management is complete (create, list, pause, resume, delete), but there is no update tool and no way to view or cancel one-off scheduled notifications. This leaves notable gaps in the lifecycle.

Maintenance

ActivityInactive
ResponsivenessSyncing

Resources

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

Related MCP Servers

  • ntfy-me-mcp

    gitmotion
    A
    license
    A
    quality
    C
    maintenance
    A streamlined MCP server that enables AI assistants to send real-time notifications to your devices through the ntfy service, allowing you to receive alerts when tasks complete or important events occur.
    2
    151
    72
    GPL 3.0

  • AgentCron

    Noriget
    A
    license
    Not graded
    quality
    D
    maintenance
    A hosted remote MCP server that lets your AI agent schedule tasks for later — reminders, delayed webhook callbacks, and recurring jobs. Read-only by design.
    8
    MIT

  • agentrem

    fraction12
    A
    license
    Not graded
    quality
    C
    maintenance
    MCP server for managing structured reminders for AI agents, with persistent storage, full-text search, and cross-session support.
    15
    1
    MIT

  • claude-cron

    frr149
    A
    license
    Not graded
    quality
    F
    maintenance
    MCP server that allows AI coding assistants to schedule deferred tasks such as reminders, shell commands, and AI prompts, executing them as an OS daemon.
    2
    MIT

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/cronty-com/cronty-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server