Ask real people: human feedback, user testing, surveys

Tell people what their answers changed

ask_people_send_outcome

Destructive

Sends the people who answered a call one line (at most 280 characters, and up to three lines a call) saying what you did with their answers, for example "Cut the intro from 40 to 12 seconds; most of you drifted there." The line is reviewed the way a call is and may be refused; if allowed, it appears on each answering person's receipt and they are notified. Costs nothing. Returns whether the line was allowed and how many people it reached. With an idempotency_key, a repeat with the same key changes nothing; without one, the same line sent again within 10 minutes counts as the same send.

Use it, with your user's agreement, once the answers have changed the work. Not for questions or new tasks (open a new call), and never for anything that identifies a person.

Example: {"call_id": "call_...", "text": "Cut the intro from 40 to 12 seconds; most of you drifted there.", "idempotency_key": "outcome-1"}

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "call_id": "<call_id>",
      "text": "<text>"
    },
    "name": "ask_people_send_outcome"
  }
}

Input Schema

Name	Required	Description
`text`	Yes	One line: what you did with the answers.
`call_id`	Yes
`idempotency_key`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 15, 2026

TDQS

A4.8/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the line is reviewed and may be refused, that on success it appears on receipts and triggers notifications, that it costs nothing, and that delivery is capped at three lines per call. The idempotency nuance (same key is a no-op; without a key, an identical line within 10 minutes counts as the same send) reconciles with idempotentHint=false and is genuinely operationally useful. The destructive/irreversibility of notifying real people is conveyed through the review-and-refusal path.

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-loaded with the core action, then exclusions, then mechanics, then the example: a sensible ordering. Slightly dense, and 'one line ... and up to three lines a call' takes a moment to parse, but almost nothing is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

A notification-sending mutation with rich annotations and an output schema; the description still supplies the decision-relevant behavior (review, refusal, recipient notification, cost, returns allowed-status and reach). Nothing an agent needs in order to call it correctly is missing, including a worked example.

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?

Schema coverage is only 33% (only text is described), so the description must carry weight and largely does: it defines the idempotency_key semantics, the 10-minute dedupe window, and the 280-character one-line limit with an example payload. call_id is only implied ('the people who answered a call'), which is the one small gap rather than an ambiguity an agent would trip on.

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?

Specific verb and resource: 'Sends the people who answered a call one line ... saying what you did with their answers.' It also carves out scope against siblings, explicitly excluding questions and new tasks ('open a new call'), so an agent can distinguish it from ask_people and ask_people_cancel without opening a schema.

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?

States the trigger condition ('once the answers have changed the work'), a prerequisite ('with your user's agreement'), and two explicit exclusions: not for questions or new tasks, and never for anything that identifies a person. That is when, when-not, and where to go instead.

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

All Ask real people: human feedback, user testing, surveys 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.