Skip to main content
Glama
kiriminow

kirimi-mcp

by kiriminow
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

broadcast_message

Send a single message to up to 1000 recipients instantly. Delivery is throttled with a 30-second delay between messages, running in the background while the call returns immediately.

Instructions

Send the same message to many recipients. Max 1000 numbers per call. The server enforces a minimum 30 second delay between sends, so this returns immediately while delivery continues in the background.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
delayNoSeconds between messages. Server clamps to 30-3600. Default 30.
labelYesName for this broadcast, for your own tracking (max 100 chars)
messageNoMessage text to broadcast. Required unless media_url is given.
numbersYesRecipient numbers. Phone number in international format without + (e.g. 6281234567890)
delay_maxNoUpper bound when using a random delay range
delay_minNoLower bound when using a random delay range
device_idNoDevice ID (e.g. D-XXXXX). Optional if the KIRIMI_DEVICE_ID environment variable is set.
media_urlNoPublic URL of media to attach to every message

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.1.0
    • changedInput schema / properties / delay / description
      Previous value: -"Fixed delay in seconds between sends (default 30, min 30)"New value: +"Seconds between messages. Server clamps to 30-3600. Default 30."
    • changedInput schema / properties / delay_max / description
      Previous value: -"Maximum delay in seconds for random delay range"New value: +"Upper bound when using a random delay range"
    • changedInput schema / properties / delay_min / description
      Previous value: -"Minimum delay in seconds for random delay range"New value: +"Lower bound when using a random delay range"
    • addedInput schema / properties / device_id
      Added value: +{
+  "description": "Device ID (e.g. D-XXXXX). Optional if the KIRIMI_DEVICE_ID environment variable is set.",
+  "type": "string"
+}
    • changedInput schema / properties / label / description
      Previous value: -"Broadcast label/name (max 100 chars)"New value: +"Name for this broadcast, for your own tracking (max 100 chars)"
    • changedInput schema / properties / media_url / description
      Previous value: -"Optional media URL to attach to every message"New value: +"Public URL of media to attach to every message"
    • changedInput schema / properties / message / description
      Previous value: -"Text message to broadcast"New value: +"Message text to broadcast. Required unless media_url is given."
    • changedInput schema / properties / numbers / description
      Previous value: -"Array of recipient phone numbers"New value: +"Recipient numbers. Phone number in international format without + (e.g. 6281234567890)"
  2. First observedv1.0.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations provided, the description carries the full behavioral burden and uses it well: it discloses that the operation returns immediately, that the server enforces a minimum 30-second delay between sends, and that delivery continues asynchronously in the background. This is valuable transparency for a side-effecting tool, though it does not cover all possible failure or return behaviors.

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 tight sentences deliver purpose, a key constraint, and the critical asynchronous behavior with no filler. The primary verb and resource are front-loaded, and every sentence adds information an agent needs before calling the tool.

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 tool with 8 parameters, all schema-documented, and no annotations or output schema, the description covers the most operationally important facts: bulk scope, count limit, and async delivery behavior. It does not describe return values or what happens on partial failures, but it gives an agent enough context to invoke the tool correctly.

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?

The input schema already documents all 8 parameters with 100% coverage, so the baseline is 3. The description adds meaningful parameter-related semantics beyond the schema by specifying the maximum recipient count (1000) and the server-enforced minimum delay floor (30 seconds), which directly inform how `numbers` and `delay` should be used.

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 states a clear verb and resource: 'Send the same message to many recipients.' The phrase 'many recipients' immediately distinguishes it from sibling tools like send_message and send_message_fast, which target a single message flow. The max-1000 qualifier further sharpens the scope.

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 makes the intended use case clear: bulk messaging to many recipients, with a hard cap of 1000 numbers per call. It does not explicitly name alternatives like send_message for single-recipient sends, but the context strongly implies when this tool is appropriate. It does not include exclusion conditions, so it stops short of a 5.

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