Skip to main content
Glama
applogico

blipr-mcp

by applogico
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Send a Blipr alert

send_alert

Send a push notification to your phone to report a finished task, broken build, approval request, or blocked work, with adjustable priority.

Instructions

Send a push notification to the user's phone via Blipr. Use this to reach the human: a long task finished, a build broke, you need approval, or you're blocked and need input. Priority 1 (silent) to 5 (critical); defaults to 3.

Input Schema

NameRequiredDescriptionDefault
tagsNoTags / emoji shortcodes, e.g. ["warning", "rocket"].
clickNoURL opened when the notification is tapped.
titleNoShort title, shown bold above the message.
topicNoTopic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var.
messageYesThe alert body — what happened or what you need.
markdownNoRender the body as Markdown (bold, italics, links, code). Off by default.
priorityNo1=min/silent, 2=low, 3=default, 4=high (plays a sound, respects Focus), 5=critical (breaks Focus).

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.6.3
    • addedInput schema / properties / markdown
      Added value: +{
+  "description": "Render the body as Markdown (bold, italics, links, code). Off by default.",
+  "type": "boolean"
+}
    • changedInput schema / properties / priority / description
      Previous value: -"1=min/silent, 2=low, 3=default, 4=time-sensitive (breaks Focus), 5=critical."New value: +"1=min/silent, 2=low, 3=default, 4=high (plays a sound, respects Focus), 5=critical (breaks Focus)."
  2. Changed1 schema field changedv0.4.0
    • changedInput schema / properties / topic / description
      Previous value: -"Topic to publish to. Defaults to the BLIPR_TOPIC env var."New value: +"Topic to publish to. Pass it explicitly — each project should use its own topic. When omitted, falls back to the project's `.blipr-topic` file, then the BLIPR_TOPIC env var."
  3. First observedv0.3.1

TDQS

A3.8/5.0
Behavior3/5

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

No annotations are provided, so the description carries the full behavioral burden. It discloses the delivery channel (push to phone) and priority semantics, but says nothing about rate limits, delivery failure behavior, permissions/topic resolution consequences, or what the call returns.

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 tight sentences, with the core action first and the usage triggers immediately after. No filler or repetition of the title.

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 7-parameter notification tool with a fully documented schema and no output schema, the description covers the essential what-and-when. The remaining gap is post-send behavior (confirmation, failure modes), a minor omission given the schema richness.

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 description coverage is 100%, so the schema already documents all seven parameters, including the priority scale and topic fallback chain. The description merely restates the priority range and adds no syntax or defaulting detail beyond the schema; baseline 3 applies.

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 a specific verb and resource: 'Send a push notification to the user's phone via Blipr,' which is concrete and unambiguous. It's distinguishable from ask/check_reply by the use cases listed, but it never names or contrasts the sibling tools explicitly, leaving routing to inference.

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 enumerates when to use it: 'a long task finished, a build broke, you need approval, or you're blocked and need input.' That is strong context, but there are no exclusions or guidance on when to prefer send_critical, ask, or request_ack instead.

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

Deploy Server

Other Tools