Skip to main content
Glama
qq418716640

BotBell MCP Server

by qq418716640

English | 中文

BotBell MCP Server

MCP Badge Glama

Let AI assistants send push notifications to your iPhone / Mac.

What it does

After setup, your AI assistant (Claude, Cursor, etc.) can:

  • Send you notifications — task results, alerts, reminders push to your phone

  • Read your replies — you reply in the BotBell app, AI reads it and continues

  • Manage your bots — list, create bots (PAT mode only)

Related MCP server: MCP-Pushover Bridge

Authentication Modes

BotBell MCP Server supports two token types, auto-detected by prefix:

Token Type

Prefix

Scope

Best For

Bot Token

bt_

Single bot only

Simple setup, one bot

Personal Access Token (PAT)

pak_

All your bots

Multi-bot, full control

Bot Token: Get it from the BotBell app when you create a bot. One token = one bot.

PAT: Create one at BotBell app > Settings > API Keys. One token controls all your bots.

Quick Start

1. Install BotBell app

Download from the App Store, create a Bot, and get your token.

2. Install MCP Server

npm install -g @botbell/mcp-server

3. Configure Claude Desktop

Edit ~/Library/Application Support/Claude/claude_desktop_config.json:

Option A: PAT mode (recommended)

{
  "mcpServers": {
    "botbell": {
      "command": "botbell-mcp",
      "env": {
        "BOTBELL_TOKEN": "pak_your_pat_here"
      }
    }
  }
}

Option B: Bot Token mode

{
  "mcpServers": {
    "botbell": {
      "command": "botbell-mcp",
      "env": {
        "BOTBELL_TOKEN": "bt_your_token_here"
      }
    }
  }
}

4. Use it

Tell Claude:

  • "Send a notification to my phone saying the build is done"

  • "Analyze this log file and push the summary to my phone"

  • "Check if I have any replies in BotBell"

  • "List my bots" (PAT mode)

  • "Create a new bot called Deploy Alerts" (PAT mode)

Tools

PAT Mode (pak_ token)

botbell_list_bots

List all your bots. Use this to find the bot_id before sending.

botbell_create_bot

Create a new bot.

Parameter

Required

Description

name

Yes

Bot name (max 50 chars)

description

No

Bot description

botbell_send

Send a push notification via a specific bot.

Parameter

Required

Description

bot_id

Yes

Bot ID (use botbell_list_bots to find)

message

Yes

Message content (max 4096 chars)

title

No

Notification title

url

No

URL to attach (tappable)

image_url

No

Image URL to attach

actions

No

Quick reply buttons (max 5), see Actions

botbell_get_replies

Check for user replies to a specific bot.

Parameter

Required

Description

bot_id

Yes

Bot ID to check

limit

No

Max replies to fetch (default 20)

Bot Token Mode (bt_ token)

botbell_send

Send a push notification.

Parameter

Required

Description

message

Yes

Message content (max 4096 chars)

title

No

Notification title

url

No

URL to attach (tappable)

image_url

No

Image URL to attach

actions

No

Quick reply buttons (max 5), see Actions

botbell_get_replies

Fetch user replies from the BotBell app.

Parameter

Required

Description

limit

No

Max replies to fetch (default 20)

Extra Tokens

If you need to send notifications to bots from multiple accounts, you can configure additional Bot Tokens via the BOTBELL_EXTRA_TOKENS environment variable.

Format: alias1:bt_token1,alias2:bt_token2

{
  "mcpServers": {
    "botbell": {
      "command": "botbell-mcp",
      "env": {
        "BOTBELL_TOKEN": "pak_your_pat_here",
        "BOTBELL_EXTRA_TOKENS": "team-ops:bt_abc123,home:bt_xyz789"
      }
    }
  }
}

When extra tokens are configured:

  • The alias parameter becomes available on botbell_send and botbell_get_replies

  • Use alias to route messages through a specific extra token

  • In PAT mode, botbell_list_bots shows extra bots alongside your own

  • Without alias, the primary token (BOTBELL_TOKEN) is used as default

For Cursor / Other MCP Clients

Add to your MCP config:

{
  "botbell": {
    "command": "botbell-mcp",
    "env": {
      "BOTBELL_TOKEN": "pak_your_pat_here"
    }
  }
}

Actions

Add interactive buttons to your notifications. Users can tap to reply without typing.

{
  "message": "Deploy v2.3 to production?",
  "actions": [
    { "key": "approve", "label": "Yes" },
    { "key": "reject", "label": "No" },
    { "key": "custom", "label": "Other...", "type": "input", "placeholder": "Enter reason" }
  ]
}

Field

Required

Description

key

Yes

Identifier returned when user taps (max 64 chars)

label

Yes

Button text shown to user (max 64 chars)

type

No

"button" (default) or "input" (opens text field)

placeholder

No

Placeholder for input field (max 128 chars)

When the user taps an action, botbell_get_replies returns the action key along with the message content:

[2026-01-15T10:30:00.000Z] [action:approve] Yes

Lightweight Alternatives

If MCP is more than you need:

  • SDKs — Call the REST API directly from your code:

    • Python: pip install botbell (PyPI · GitHub)

    • JavaScript: npm install @botbell/sdk (npm · GitHub)

  • Agent Skill — One command to install, zero dependencies, works with 30+ AI tools: BotBell Agent Skill

Available Tools

2 tools
botbell_get_repliesA

Check if the user has replied to your messages in the BotBell app. Messages are consumed on fetch (won't be returned again).

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMax number of replies to fetch (default 20, max 100)

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description must disclose behaviors. It explicitly states that messages are consumed on fetch (won't be returned again), a critical behavioral trait. No other traits are discussed, but this is a key disclosure.

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 concise sentences, front-loaded with purpose. No unnecessary words or redundant information.

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

Completeness3/5

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

The description explains the tool's purpose and a key behavior, but given no output schema, it does not describe what is returned. For a simple one-parameter tool, it is partially complete but missing output details.

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?

The input schema covers the 'limit' parameter with 100% coverage. The description adds no additional meaning beyond what the schema provides, so baseline 3 is appropriate.

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 'Check' and the resource 'replied messages' in the BotBell app, distinguishing it from the sibling tool botbell_send which is for sending messages.

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 implies when to use (to check for replies) but does not explicitly contrast with botbell_send or state when not to use. The context is clear but lacks exclusions.

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

botbell_sendA

Send a push notification to the user's iPhone/Mac via BotBell. You can include action buttons for quick replies. Use type 'input' to let the user type a custom response.

ParametersJSON Schema
NameRequiredDescriptionDefault
messageYesMessage content (required, max 4096 chars)
titleNoMessage title (optional)
urlNoURL to attach (optional)
image_urlNoImage URL to attach (optional)
summaryNoCustom summary for long messages (optional, max 512 chars)
formatNoMessage format: 'text' (default) or 'markdown' for Markdown rendering
actions_descriptionNoDescription text shown above action buttons (optional, max 256 chars)
actionsNoQuick reply buttons (max 5). Use type 'input' for free-text option.
reply_modeNoControls how the recipient can reply: 'open' (default, free text + actions), 'actions_only' (only action buttons, no free text), 'none' (pure notification, no reply)

TDQS

A3.7/5.0
Behavior2/5

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

No annotations are provided, and the description does not disclose any behavioral traits such as success/failure behavior, authorization requirements, rate limits, or side effects. This is a significant gap for a notification tool.

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 sentences, front-loaded with purpose, no unnecessary words. Every sentence adds value.

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

Completeness3/5

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

Covers the main functionality and a key feature (actions with input), but lacks information about return values, error handling, prerequisites, and integration with sibling tool. Adequate for basic use but not complete.

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 parameter descriptions. The description adds minimal extra value by highlighting the 'input' type for actions, but mostly repeats schema information. Baseline 3 is appropriate.

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 'Send' and the resource 'push notification to the user's iPhone/Mac via BotBell'. It also distinguishes from the sibling tool 'botbell_get_replies' by focusing on sending, not retrieving.

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 when to use action buttons and input type, but does not explicitly compare to sibling tool or state prerequisites/exclusions. Provides clear context for using actions.

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

TDQS

A4/5.0
Disambiguation5/5

The two tools have entirely distinct purposes: one sends notifications, the other checks for replies. There is no overlap or ambiguity.

Naming Consistency5/5

Both tools follow a consistent botbell_ prefix and verb_noun pattern (get_replies, send), making them easy to distinguish and predict.

Tool Count4/5

With only two tools, the server is minimal but covers the core send/reply cycle for a notification service. Slightly below average count but still reasonable.

Completeness4/5

The tools cover the essential operations for a push notification service: sending and retrieving replies. Minor gaps like history or subscription management are present but not critical for basic functionality.

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

  • A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to send push notifications through the kweenkl service. Allows users to receive contextual notifications from their AI when tasks are complete or important events occur.
    1
    17
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to send push notifications to mobile devices via Pushover, allowing users to receive instant alerts for task completions, errors, reminders, and custom messages through their AI conversations.
    1
    20
    2
    MIT
  • A
    license
    Not graded
    quality
    D
    maintenance
    Enables AI assistants to send native macOS notifications for task completion alerts and reminders. Supports interactive features like custom system sounds, action buttons, and user replies directly from the notification center.
    201
    MIT
  • A
    license
    B
    quality
    D
    maintenance
    Enables AI assistants to send desktop notifications on macOS with rich formatting, urgency levels, and sound options.
    1
    26
    1
    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/qq418716640/botbell-mcp'

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