MCP server for self-hosted Gotify. Exposes a unified gotify action router and a gotify_help companion tool for sending notifications and managing Gotify messages, applications, clients, and account metadata.

Two MCP tools are exposed:

The server supports HTTP (default) and stdio transports. HTTP transport requires bearer authentication via GOTIFY_MCP_TOKEN.

• gotify_mcp/server.py: FastMCP server, action router, and BearerAuth middleware
• gotify_mcp/services/gotify.py: Async HTTP client for the Gotify REST API
• skills/gotify/SKILL.md: Client-facing skill documentation
• docs/gotify-api.json: Bundled upstream Gotify API reference
• .claude-plugin/plugin.json, .codex-plugin/plugin.json, gemini-extension.json: Client manifests
• docker-compose.yml, Dockerfile, entrypoint.sh: Container deployment
• scripts/: Smoke tests and contract checks

Single entry point for all Gotify operations. Select the operation with the action parameter.

gotify(action="send_message", app_token="AbCdEf", message="Build finished", priority=5)

Returns the full action reference as Markdown. Call this to discover available actions.

gotify_help()

Send a push notification. Requires an app_token — this is the per-application token, not the client token.

Response fields:

Example:

gotify(action="send_message",
       app_token="AbCdEf",
       title="Deployment done",
       message="## Summary\n- All steps complete\n- Ready for review",
       priority=7,
       extras={"client::display": {"contentType": "text/markdown"}})

List messages with pagination and optional filtering.

Response fields:

Note: Gotify uses cursor-style pagination internally. The offset parameter maps to the since query parameter (a message ID), not a row count.

Example:

gotify(action="list_messages", limit=20, sort_order="desc")
gotify(action="list_messages", app_id=3, query="error", limit=10)

Delete a single message by ID. Destructive — requires confirm=True.

Example:

gotify(action="delete_message", message_id=42, confirm=True)

Delete all messages across all applications. Destructive — requires confirm=True.

Example:

gotify(action="delete_all_messages", confirm=True)

List all applications registered on the Gotify server.

Response fields:

Each application object contains:

Example:

gotify(action="list_applications")
gotify(action="list_applications", query="homelab")

Create a new Gotify application.

Returns the created application object.

Example:

gotify(action="create_application",
       name="homelab-alerts",
       description="Claude Code homelab notifications",
       default_priority=5)

Update an existing application. Provide at least one of name, description, or default_priority.

Returns the updated application object.

Example:

gotify(action="update_application", app_id=3, name="homelab-alerts-v2", default_priority=7)

Delete an application and all its messages. Destructive — requires confirm=True.

Example:

gotify(action="delete_application", app_id=3, confirm=True)

List all registered Gotify clients. Requires GOTIFY_CLIENT_TOKEN.

Response has the same pagination shape as list_applications. Each client object contains id, token, and name.

Example:

gotify(action="list_clients")

Create a new Gotify client. Returns the client object including its token.

Example:

gotify(action="create_client", name="my-phone")

Delete a Gotify client. Destructive — requires confirm=True.

Example:

gotify(action="delete_client", client_id=5, confirm=True)

Check the Gotify server health status. No additional parameters.

Returns a JSON object with health fields from the upstream Gotify /health endpoint. Note: this MCP tool call requires bearer authentication. The raw HTTP /health endpoint on the MCP server is unauthenticated.

Example:

gotify(action="health")

Get the Gotify server version. No additional parameters. No authentication required on the upstream call.

Example:

gotify(action="version")

Get the current authenticated user's account information. Requires GOTIFY_CLIENT_TOKEN.

No additional parameters. Returns the user object with id, name, and admin fields.

Example:

gotify(action="current_user")

Gotify uses two separate token types. Using the wrong type will produce a 401 error.

The MCP server reads GOTIFY_CLIENT_TOKEN from the environment and uses it automatically for management actions. You never pass it explicitly to the tool.

The app_token for send_message is always passed explicitly per call — it is not read from the server environment.

The priority field is an integer from 0 to 10. Gotify clients interpret priority ranges as follows:

If priority is omitted from send_message, the application's defaultPriority is used. If the application has no default, Gotify falls back to 0.

The extras field in send_message is a free-form dict passed to the Gotify API. The most common use is enabling Markdown rendering:

extras={"client::display": {"contentType": "text/markdown"}}

Other known namespaces from the upstream Gotify extras specification:

Any key/value pairs are accepted — the server passes them through as-is.

Four actions are gated behind a confirmation check:

• delete_message
• delete_all_messages
• delete_application
• delete_client

Without confirm=True, the server returns:

{"error": "Destructive operation. Pass confirm=True to proceed."}

To bypass the gate server-wide, set either environment variable:

ALLOW_DESTRUCTIVE=true   # skip confirm check
ALLOW_YOLO=true          # identical effect

These env vars are intended for automated environments where interactive confirmation is not possible.

List actions (list_messages, list_applications, list_clients) share a common pagination interface:

All list responses include total, limit, offset, and has_more alongside the items array.

All errors return a JSON object with these fields:

Common errors:

Responses are truncated at 512 KB. Truncated responses include ... [truncated] at the end.

Install as a Claude Code plugin. You will be prompted for:

• Gotify Server URL — base URL of your Gotify instance
• Gotify App Token — for sending messages (from Gotify UI: Settings > Apps)
• Gotify Client Token — for management operations (from Gotify UI: Settings > Clients)

The plugin uses stdio transport with ${userConfig.*} interpolation — no .env file needed.

cp .env.example .env
chmod 600 .env
# Edit .env with your credentials
docker compose up -d

uv sync --dev
uv run gotify-mcp-server

Two deployment paths are supported:

See docs/CONFIG.md for the full environment variable reference.

When running inside Docker, localhost and 127.0.0.1 in GOTIFY_URL are automatically rewritten to host.docker.internal so the container can reach a host-side Gotify server.

gotify(action="send_message",
       app_token="AbCdEf",
       title="Build finished",
       message="All tests passed.",
       priority=5)

gotify(action="send_message",
       app_token="AbCdEf",
       title="Deploy complete",
       message="## Status\n- All steps done\n- Ready for review",
       priority=7,
       extras={"client::display": {"contentType": "text/markdown"}})

# First page
gotify(action="list_messages", limit=25, offset=0)

# Next page (use the ID of the last message as offset)
gotify(action="list_messages", limit=25, offset=99)

gotify(action="list_messages", query="error", limit=20)

gotify(action="list_messages", app_id=3, limit=50)

# List all applications
gotify(action="list_applications")

# Create
gotify(action="create_application",
       name="homelab-alerts",
       description="Automated notifications",
       default_priority=5)

# Update
gotify(action="update_application", app_id=3, default_priority=7)

# Delete (destructive)
gotify(action="delete_application", app_id=3, confirm=True)

# List all clients
gotify(action="list_clients")

# Create
gotify(action="create_client", name="my-phone")

# Delete (destructive)
gotify(action="delete_client", client_id=5, confirm=True)

gotify(action="health")
gotify(action="version")
gotify(action="current_user")

When MCP tools are unavailable, use direct HTTP calls. App tokens go to /message, client tokens go to management endpoints.

# Send a notification
curl -s -X POST "$GOTIFY_URL/message" \
  -H "X-Gotify-Key: $GOTIFY_APP_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"title":"Done","message":"All steps complete","priority":7}'

# List messages
curl -s "$GOTIFY_URL/message" \
  -H "X-Gotify-Key: $GOTIFY_CLIENT_TOKEN"

# List applications
curl -s "$GOTIFY_URL/application" \
  -H "X-Gotify-Key: $GOTIFY_CLIENT_TOKEN"

# Health (no auth)
curl -s "$GOTIFY_URL/health"

just setup

This copies .env.example to .env (if not already present) and installs all dependencies.

just dev          # Run the server locally (uv run python -m gotify_mcp.server)
just lint         # Run ruff check
just fmt          # Run ruff format
just typecheck    # Run ty check
just test         # Run pytest
just build        # Build Docker image
just up           # Start via docker compose
just down         # Stop docker compose
just restart      # Restart docker compose
just logs         # Follow docker compose logs
just health       # curl http://localhost:9158/health
just test-live    # Run live integration tests (requires running server)
just gen-token    # Generate a random bearer token
just clean        # Remove build artifacts

Run before committing:

just lint
just typecheck
just test

Live verification (requires a running server and Gotify instance):

just test-live

The MCP server exposes an unauthenticated HTTP health endpoint:

GET http://localhost:9158/health

This proxies through to the Gotify server's /health and returns:

{"status": "ok", "gotify": {...}}

Or on failure:

{"status": "error", "reason": "..."}

The server writes rotating logs to logs/gotify_mcp.log (max 5 MB, 3 backups). Log level is controlled by GOTIFY_LOG_LEVEL.

MIT