PingRoom

Publish Live Status

live_status

DestructiveIdempotent

Start, update, or end a live progress card on the room members' lock screen (an iOS Live Activity / Android live update). Reuse the same correlation_id for every ping of one stream: the first ping starts the card and sends one alert, further "running" pings move it silently, and the first "done"/"failed" sends one completion alert and ends it. Free accounts get a small number of NEW streams per day; updates and the final ping of an open stream are never charged; a first ping that is already "done"/"failed" counts as a new stream.

Input Schema

TableJSON Schema

Name	Required	Description
`data`	No	Arbitrary structured context (max 25 keys / 8KB), returned on read surfaces after connector privacy filtering. Do not put secrets in data.
`title`	No	Card title. Defaults to the selected quick action's label.
`action`	No	Quick-action slot to attribute the stream to (supplies the icon and sound).
`invite_code`	Yes	Room invite code.
`live_status`	Yes	The live card's state. Only state is required.
`requires_ack`	No	Add an Acknowledge button; the first eligible member to tap resolves it for everyone. Does not raise the interruption level — set category "alert" for a time-sensitive start.
`correlation_id`	Yes	The stream key. Reuse it on every ping of the same stream.
`ack_timeout_seconds`	No	Optional acknowledgement deadline in seconds.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes	Purpose-built PingRoom result with credential and account fields removed.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 27, 2026

addedInput schema / properties / live_status / properties / duration_seconds

Added value: +{
+  "description": "Original countdown duration in seconds. Set on creation; preserved through updates and completion.",
+  "maximum": 4102444800,
+  "minimum": 1,
+  "type": "integer"
+}

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

TDQS

A4.3/5.0

Behavior5/5

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

Annotations only declare the safety profile (idempotent, destructive, open-world); the description goes well beyond by disclosing alert behavior (one alert on start, silent moves, one completion alert), the billing/charge model, and the fact that a first ping already marked done/failed is charged as a new stream. None of this is derivable from annotations or schema.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Front-loads the purpose, then packs lifecycle and charging rules into two dense sentences with little waste. Slightly long, but nearly every clause carries actionable information.

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 complex tool with nested objects and an output schema, the description covers the stream lifecycle and economic constraints an agent needs. It omits interaction details on secondary params (requires_ack, template/category fixed-at-creation), but those are documented in the schema.

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 8 parameters, and the description's correlation_id guidance ('reuse the same correlation_id for every ping') largely restates the schema's own text. Baseline 3 is appropriate; no additional syntax or format meaning is supplied.

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?

States a specific set of verbs (start/update/end) on a specific resource (live progress card on members' lock screen, iOS Live Activity / Android live update), and is immediately distinguishable from the read-side sibling get_live_status.

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?

Explains the lifecycle discipline for correlation_id (first ping starts, running pings move silently, done/failed ends) and gives concrete when-to-use cost rules for free accounts. It stops short of naming alternative tools (e.g. get_live_status, wait_for_ack) or stating exclusions, so it is strong context without full routing guidance.

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?