PingRoom

Broadcast Ping

broadcast

Send a custom ping to a room the account belongs to. Rate-limited. Not available in personal rooms (use trigger_quick_action there).

Input Schema

TableJSON Schema

Name	Required	Description
`data`	No	Arbitrary structured context (max 25 keys / 8KB). Read surfaces return it after connector privacy filtering; do not put secrets in data. data.location is reserved for a shareable location, and data.url + data.button_label are reserved for a tappable link ping.
`title`	No	Optional headline. Defaults to the room name.
`message`	Yes	Ping body text (max 120 characters in private rooms, 160 in public rooms).
`ack_mode`	No	With requires_ack: any (default) resolves on the first confirmation; all waits for every original eligible recipient. Read action_state.confirmed_count and required_count for progress.
`reply_to`	No	Id of the ping this one answers (notification id or correlation id).
`is_urgent`	No	Deliver time-sensitive so the ping breaks through Focus / Do Not Disturb and reaches members who muted the room or you (a block still wins). Independent of requires_ack: urgent affects delivery only and asks nothing of the recipient.
`action_icon`	No	Optional emoji shown with the ping.
`invite_code`	Yes	Room invite code.
`requires_ack`	No	Keep this ping open until its confirmation rule is met, and show it as a lock-screen card with an Acknowledge button. Does not raise the interruption level on its own — combine with is_urgent for an ack that also breaks through Focus.
`action_number`	No	Optional quick-action slot to attribute the ping to.
`attachment_ids`	No	Ids of up to 4 uploaded attachments (see upload_attachment) to include. Uploading requires a Pro account.
`correlation_id`	No	Your own id, echoed back unchanged on read.
`ack_timeout_seconds`	No	Optional acknowledgement deadline in seconds.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	A privacy-minimized, chainable PingRoom notification result.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 16, 2026

changedInput schema / properties / is_urgent / description

Previous value: -"Deliver time-sensitive so the ping breaks through Focus / Do Not Disturb. Independent of requires_ack: urgent affects delivery only and asks nothing of the recipient."New value: +"Deliver time-sensitive so the ping breaks through Focus / Do Not Disturb and reaches members who muted the room or you (a block still wins). Independent of requires_ack: urgent affects delivery only and asks nothing of the recipient."

Changed1 schema field changedSep 11, 2026
- changedInput schema / properties / action_number / maximum
```
Previous value: -4New value: +16
```

Changed2 schema fields changedSep 10, 2026

addedInput schema / properties / ack_mode

Added value: +{
+  "description": "With requires_ack: any (default) resolves on the first confirmation; all waits for every original eligible recipient. Read action_state.confirmed_count and required_count for progress.",
+  "enum": [
+    "any",
+    "all"
+  ],
+  "type": "string"
+}

changedInput schema / properties / requires_ack / description

Previous value: -"Keep this ping open until one eligible recipient acknowledges it, and show it as a lock-screen card with an Acknowledge button. Does not raise the interruption level on its own — combine with is_urgent for an ack that also breaks through Focus."New value: +"Keep this ping open until its confirmation rule is met, and show it as a lock-screen card with an Acknowledge button. Does not raise the interruption level on its own — combine with is_urgent for an ack that also breaks through Focus."

Changed1 schema field changedSep 1, 2026

addedOutput schema / properties / result / properties / origin_agent

Added value: +{
+  "description": "Present when a connected agent originated the ping: its handle and display name.",
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already convey readOnly=false and idempotent=false, so the description is not burdened with stating the obvious. It adds concrete behavioral facts not present in annotations: rate-limiting and unavailability in personal rooms. These are useful operational warnings beyond what the schema and annotations provide.

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 short, front-loaded sentences carry the essential purpose, a critical rate-limit warning, and a routing exclusion. There is no filler, restatement, or irrelevant detail.

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 13 parameters and nested objects, the description is brief but covers the key selection constraints. The rich input schema and presence of an output schema carry most invocation details, and the description supplies the missing operational guidance: rate-limit awareness and the personal-room alternative.

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 baseline is 3. The description names no parameters and adds no extra semantics beyond the schema; however, the schema itself documents each parameter thoroughly, including nested data fields and reserved meanings. The description neither helps nor hurts here.

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 opens with a specific verb and resource: 'Send a custom ping to a room the account belongs to.' It immediately distinguishes itself from the sibling trigger_quick_action by explicitly excluding personal rooms. The purpose is unambiguous and not a tautology.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states both a precondition ('a room the account belongs to') and an explicit exclusion with a named alternative: 'Not available in personal rooms (use trigger_quick_action there).' This gives an agent clear routing guidance without opening other tool definitions.

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

All PingRoom tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?