Pingfyr lets you manage scheduled reminders, delivering notifications across multiple channels automatically.
Create Reminders — Schedule a new reminder with a title, body, fire time (ISO 8601), and delivery channel. Supports one-time or recurring schedules (daily, weekly, monthly, or custom cron expressions) with IANA timezone support and optional metadata.
List Reminders — Retrieve all reminders with optional filtering by status (pending, processing, delivered, failed, cancelled) and pagination via limit and offset.
Update Reminders — Modify any pending reminder's title, body, fire time, channel, recipients, repeat schedule, or timezone.
Cancel Reminders — Prevent a pending reminder from being delivered.
Supported delivery channels:
Email — One or more addresses (Starter+ plan required)
Webhook — HTTP POST to any URL
Slack — Via Incoming Webhook URL
Discord — Via Webhook URL
Telegram — Via a bot using bot:<bot_id>:<chat_id> format
OpenClaw — POST to an OpenClaw endpoint
Google Calendar — Create events on a connected account (Starter+ plan required)
Allows scheduling and delivering reminder notifications to Discord channels using webhooks.
Enables the creation of events on a connected Google Calendar as a form of scheduled reminder.
Supports scheduling and delivering reminder notifications to Slack channels via incoming webhooks.
Allows for the delivery of scheduled reminders and notifications to Telegram chats through a registered bot.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Pingfyr Remind me on Slack to check the server status in 2 hours"
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.
Connect your AI assistant to Pingfyr via MCP. Manage reminders through natural conversation.
One API call. Seven channels. Your reminders fire automatically — no external cron, no polling, no babysitting.
Available as a local npm package or as a hosted server at mcp.pingfyr.com — no local install required.
npm install -g @pingfyr/mcpOr run directly with npx:
npx @pingfyr/mcpRelated MCP server: Telegram Reminder MCP
Run the MCP server as a local process. Requires Node.js 18+.
Add to your MCP client config (Claude Code, Cursor, Windsurf, etc.):
{
"mcpServers": {
"pingfyr": {
"command": "pingfyr-mcp",
"env": {
"PINGFYR_API_KEY": "rm_your_api_key"
}
}
}
}Sign up at pingfyr.com to get your API key.
No install required. Connect directly to mcp.pingfyr.com using HTTP transport. Your API key is sent as a Bearer token per request.
{
"mcpServers": {
"pingfyr": {
"type": "http",
"url": "https://mcp.pingfyr.com",
"headers": {
"Authorization": "Bearer rm_your_api_key"
}
}
}
}HTTP transport is supported by Claude Code and Cursor. Claude Desktop requires the local (stdio) option above.
Tool | Description |
| Schedule a new reminder via email, webhook, Slack, Discord, Telegram, OpenClaw, or Google Calendar |
| List all reminders with optional filtering by status, limit, and offset |
| Update a pending reminder (title, body, fire_at, channel, recipients, repeat, timezone) |
| Cancel a pending reminder |
create_reminder ParametersParameter | Required | Type | Description |
| Yes | string | Title of the reminder (max 200 chars) |
| Yes | string | When to fire (ISO 8601 datetime, must be in the future) |
| Yes | enum |
|
| Yes | string[] | Delivery addresses (see Channels table for format per channel) |
| No | string | Body/description of the reminder (max 2000 chars) |
| No | enum |
|
| No | string | Cron expression (required when |
| No | string | IANA timezone for recurring reminders (default: UTC) |
| No | object | Arbitrary key-value metadata to attach to the reminder |
list_reminders ParametersParameter | Required | Type | Description |
| No | enum |
|
| No | number | Max results (default: 50, max: 100) |
| No | number | Pagination offset (default: 0) |
update_reminder ParametersParameter | Required | Type | Description |
| Yes | string | UUID of the reminder to update |
| No | string | New title |
| No | string | New body |
| No | string | New fire time (ISO 8601) |
| No | enum | New channel |
| No | string[] | Updated delivery addresses |
| No | enum | New repeat schedule (null to remove) |
| No | string | New timezone |
{
"title": "Project deadline reminder",
"fire_at": "2026-12-15T08:00:00Z",
"channel": "email",
"recipients": ["alice@example.com", "bob@example.com"]
}{
"title": "Weekly team sync reminder",
"fire_at": "2026-12-01T09:00:00Z",
"channel": "slack",
"recipients": ["https://hooks.slack.com/services/T.../B.../xxx"],
"repeat": "weekly",
"timezone": "America/New_York"
}{
"title": "Deploy notification",
"fire_at": "2026-12-01T17:00:00Z",
"channel": "discord",
"recipients": ["https://discord.com/api/webhooks/xxx/yyy"]
}{
"title": "Daily standup",
"fire_at": "2026-12-01T09:00:00Z",
"channel": "telegram",
"recipients": ["bot:your-bot-uuid:your-chat-id"],
"repeat": "daily",
"timezone": "Europe/Berlin"
}Find your bot_id in Settings → Telegram Bots on the Pingfyr dashboard.
{
"title": "Agent task complete",
"fire_at": "2026-12-01T10:00:00Z",
"channel": "openclaw",
"recipients": ["https://openclaw.example.com/webhook"]
}Creates a Google Calendar event on the user's connected Google account. Connect your account at Settings → Google Calendar in the Pingfyr dashboard.
{
"title": "Team sync",
"fire_at": "2026-12-01T09:00:00Z",
"channel": "google_calendar",
"recipients": ["google"]
}{
"title": "Check for new orders",
"fire_at": "2026-12-01T10:00:00Z",
"channel": "webhook",
"recipients": ["https://your-agent.example.com/webhook"],
"repeat": "daily"
}{
"title": "Weekday morning check",
"fire_at": "2026-12-01T09:00:00Z",
"channel": "webhook",
"recipients": ["https://your-agent.example.com/webhook"],
"repeat": "custom",
"cron_expression": "0 9 * * MON-FRI",
"timezone": "America/New_York"
}Channel |
| Description |
| Email addresses | Deliver to one or more email inboxes (Starter+ plan required) |
| HTTP/HTTPS URL | POST request to wake up agents |
| Slack Incoming Webhook URL | Post message to a Slack channel |
| Discord Webhook URL | Post message to a Discord channel |
|
| Send message via Telegram bot (register bot in Settings → Telegram Bots) |
| OpenClaw URL | POST request to an OpenClaw endpoint |
|
| Create a Google Calendar event on your connected account (Starter+ plan required) |
Plan | Price | Reminders/month | Recipients/month |
Free | $0 | 50 | 100 |
Starter | $59/mo | 10,000 | 20,000 |
Pro | $269/mo | 50,000 | 100,000 |
Enterprise | Contact | Unlimited | Unlimited |
Free plan includes Webhook, Slack, Discord, Telegram, and OpenClaw channels. Email and Google Calendar require a paid plan (Starter+).
Variable | Required | Description |
| Yes | Your Pingfyr API key |
| No | API base URL (default: |
MIT
Cancel a pending reminder so it will not be delivered
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | UUID of the reminder to cancel |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden. It states the core effect (prevents delivery) but omits details like reversibility, side effects, error handling (e.g., if already delivered), or permissions needed. Adequate but not comprehensive.
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 9 words. Every word adds value; no redundancy. Perfectly concise for a simple action.
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 simplicity (1 param, no output schema, no annotations), the description covers the essential action and outcome. It could mention what happens on success/failure, but it's nearly complete for a straightforward cancel operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% (1 parameter described as 'UUID of the reminder to cancel'). The description adds no extra meaning beyond the schema. Baseline 3 is appropriate.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action ('cancel') and the resource ('pending reminder'), with a specific outcome ('will not be delivered'). This effectively distinguishes it from sibling tools like create_reminder, list_reminders, and update_reminder.
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 (e.g., update_reminder). It does not mention prerequisites, conditions (e.g., reminder must be pending), or when cancellation is inappropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Schedule a new reminder to be delivered via email, webhook, Slack, Discord, Telegram, OpenClaw, or Google Calendar
| Name | Required | Description | Default |
|---|---|---|---|
| title | Yes | Title of the reminder (max 200 chars) | |
| fire_at | Yes | When to fire the reminder (ISO 8601 datetime, must be in the future) | |
| body | No | Optional body/description of the reminder (max 2000 chars) | |
| channel | Yes | Delivery channel: "email", "webhook", "slack", "discord", "telegram", "openclaw", or "google_calendar" | |
| recipients | Yes | Required. Delivery addresses: email addresses for email channel, URLs for webhook/slack/discord/openclaw, bot:<bot_id>:<chat_id> format for telegram (find bot_id in Settings → Telegram Bots). | |
| repeat | No | Recurring schedule | |
| cron_expression | No | Cron expression (required when repeat is "custom") | |
| timezone | No | IANA timezone for recurring reminders (default: UTC) | |
| metadata | No | Arbitrary metadata to attach to the reminder |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description should disclose behavioral traits. It only states what it does but not side effects (e.g., whether it's idempotent, what happens on duplicate, if it returns an ID) or requirements like authentication or rate limits.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the action and resource. It is efficient but lacks structure (e.g., bullet points or summary of parameters).
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 9 parameters, 4 required, and no output schema or annotations, the description is incomplete. It does not explain what happens after scheduling (e.g., return value, confirmation), nor constraints like fire_at must be in the future (though schema mentions it). The schema descriptions cover parameters, but overall behavior is lacking.
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 detailed descriptions for each parameter. The tool description adds no additional meaning beyond the schema, so it meets the baseline but does not exceed it.
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 'Schedule' and the resource 'a new reminder', and lists the delivery channels (email, webhook, Slack, etc.). This distinguishes it from sibling tools (cancel, list, update) which are different actions.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for creating a new reminder, and sibling tools are distinct operations, so there's no ambiguity. However, no explicit guidance on when not to use or alternatives is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List all reminders for the authenticated user with optional filtering
| Name | Required | Description | Default |
|---|---|---|---|
| status | No | Filter by status | |
| limit | No | Max results (default 50, max 100) | |
| offset | No | Pagination offset (default 0) |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided. Description only states 'list', implying read-only, but does not disclose any behavioral details like potential delays, permissions, or limitations beyond what is obvious.
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?
Single sentence with no wasted words. Front-loaded with verb and resource. Efficiently conveys purpose and scope.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool, description covers purpose and filtering. Pagination details are in schema but could be hinted in description. Overall adequate given schema completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, so baseline is 3. Description adds no extra meaning beyond the schema, simply referencing 'optional filtering' which matches the status parameter.
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?
Description clearly states verb 'List', resource 'reminders', scope 'for the authenticated user', and optional filtering, distinguishing it from sibling tools like cancel_reminder and create_reminder.
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?
Usage context is clear: list reminders for the authenticated user. No explicit when-not or alternatives mentioned, but siblings have distinct actions, so implicit differentiation is adequate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Update a pending reminder (title, fire time, etc.)
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | UUID of the reminder to update | |
| title | No | New title | |
| body | No | New body | |
| fire_at | No | New fire time (ISO 8601) | |
| channel | No | New channel: "email", "webhook", "slack", "discord", "telegram", "openclaw", or "google_calendar" | |
| recipients | No | Updated delivery addresses | |
| repeat | No | New repeat schedule (null to remove) | |
| cron_expression | No | Cron expression (required when setting repeat to "custom") | |
| timezone | No | New timezone |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry full behavior disclosure. It indicates mutation ('update') but does not disclose constraints like whether updates are allowed after a reminder fires, error behaviors, or idempotency. Significant gaps remain.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single concise sentence that front-loads the core action. It is efficient but could be slightly more informative without becoming verbose.
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 tool with 9 parameters and no output schema or annotations, the description is minimal. It does not explain return values, error states, or constraints beyond 'pending'. Inadequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has 100% coverage with descriptions for all parameters. The description only mentions a few fields ('title, fire time, etc.'), adding little beyond the schema. Baseline 3 is appropriate as 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 action (update) and the object (pending reminder), and mentions typical fields. However, it doesn't differentiate from siblings like create_reminder or cancel_reminder, though the name is self-explanatory.
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 it is used for updating pending reminders but does not provide explicit when-to-use or when-not-to-use guidance. It mentions 'pending' which gives some context, but lacks alternatives or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.0cancel_remindercreate_reminderlist_remindersupdate_reminderScored across 4 tools
Each tool targets a unique action on reminders: create, list, update, and cancel. Descriptions are clear and distinct, with no overlap.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., cancel_reminder, create_reminder), making them predictable and easy to understand.
With only 4 tools, the set is well-scoped for a reminder service covering essential operations: create, read (list), update, and delete (cancel). No extraneous tools.
The tools cover CRUD-like operations for reminders, but a dedicated 'get_reminder' for a single reminder's details is missing, though list_reminders may suffice. Otherwise, the surface feels complete for the domain.
Schedule tasks for later from your AI agent: reminders, delayed webhooks, recurring jobs.
Let your AI agent notify you by email, Slack, Discord, or webhook. One tool: send_notification.
Calendar API for AI agents: events, availability, Google/Microsoft setup, scheduling, and iCal.
Persistent memory and knowledge management for AI agents with semantic search and 50+ tools.
