PingRoom

Ask Question

ask_question

Ask a person a question with 2-4 tappable options, then block on their answer (pair with wait_for_answer). Delivered as a push they can answer from the lock screen or in-app; the first valid answer wins. Rate-limited.

Input Schema

Name	Required	Description
`ttl`	No	Seconds the question stays open before it expires.
`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.checklist for a checklist.
`prompt`	Yes	The question the person reads.
`context`	No	Optional secondary line, e.g. a build number.
`options`	No	Answer options in display order. Omit for a default Approve/Deny.
`reply_to`	No	Optional routing pointer, echoed back unchanged.
`text_input`	No	Invite a typed answer (on its own, or alongside options). max_length is capped at 60.
`invite_code`	Yes	Room invite code.
`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.
`idempotency_key`	No	Stable key so a retried call cannot create a second one.

Output 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 changedOct 11, 2026

changedInput schema / properties / data / properties / checklist / description

Previous value: -"A short checklist the room can tick through, e.g. a shopping list. Ticks are kept on each viewer's device, not shared."New value: +"A short checklist the room can tick through, e.g. a shopping list. The room ticks it together: a checked item is checked for everyone, cannot be unchecked, and alerts the other recipients."

Changed2 schema fields changedOct 11, 2026

changedInput schema / properties / data / description

Previous value: -"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."New value: +"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.checklist for a checklist."

addedInput schema / properties / data / properties / checklist

Added value: +{
+  "additionalProperties": false,
+  "description": "A short checklist the room can tick through, e.g. a shopping list. Ticks are kept on each viewer's device, not shared.",
+  "properties": {
+    "items": {
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "text": {
+            "description": "One checklist item.",
+            "maxLength": 80,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "text"
+        ],
+        "type": "object"
+      },
+      "maxItems": 25,
+      "minItems": 1,
+      "type": "array"
+    }
+  },
+  "required": [
+    "items"
+  ],
+  "type": "object"
+}

First observedSep 1, 2026

TDQS

A4.4/5.0

Behavior5/5

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

The annotations already mark this as non-read-only, non-idempotent, and non-destructive, but the description adds important behavior: delivery as a lock-screen or in-app push, blocking on the answer, first valid answer winning, and being rate-limited. These are material operational traits beyond the annotations.

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?

The description is compact and front-loaded: purpose first, then workflow pairing, delivery behavior, and rate-limit note. Every clause provides useful information without repetition.

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?

Given the rich input schema, output schema, and annotations, the description covers the critical workflow and delivery behavior an agent needs. It is slightly incomplete because it does not mention required fields like invite_code or clarify room scoping, though 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 input schema already documents all 11 parameters thoroughly. The description only restates the 2-4 option constraint and does not add syntax, defaults, or format details beyond the schema, so the baseline of 3 is appropriate.

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 uses a specific verb and resource ('Ask a person a question') and immediately clarifies the shape of the interaction ('2-4 tappable options') and its blocking behavior. It also names a sibling tool ('wait_for_answer'), so an agent can distinguish this from related question/approval tools.

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?

It gives clear workflow context: ask a person, then block on their answer by pairing with wait_for_answer. It does not explicitly compare itself to alternatives like request_approval or broadcast, and it states no exclusions, so it falls short of full when/when-not 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?