Skip to main content
Glama
Sign In

Onplana

by io.github.Onplana
OverviewDiscussionsAdmin

request_user_input

Ask the human PAT holder a question and wait for their answer via the get_user_input poll. Required: question (1-2000 chars). Optional: options (string[] of up to 10 choices; when set, the human must pick one), taskId (binds the prompt to a task so it appears on that task's detail panel; without one it is listed on the human's agent inbox, Questions tab), timeoutMinutes (1-120, default 30; after this the prompt flips to TIMED_OUT inline on the next get_user_input poll). Returns { requestId, status: "PENDING" }; poll get_user_input(requestId) until status changes. Fires an in-app + email notification at the PAT holder so they know to answer.

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": {
      "question": "<question>"
    },
    "name": "request_user_input"
  }
}

Input Schema

NameRequiredDescriptionDefault
taskIdNoOptional task to bind the prompt to.
optionsNoUp to 10 choice strings; human must pick one. Free-text answer when omitted.
questionYes1-2000 chars.
timeoutMinutesNoInteger 1-120. Default 30.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.9/5.0
Behavior5/5

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

Goes well beyond the annotations: it discloses the side effect of firing in-app plus email notifications, the timeout lifecycle ('flips to TIMED_OUT inline on the next get_user_input poll'), and the return payload '{ requestId, status: "PENDING" }'. This is the kind of side-effect and lifecycle detail the readOnly/destructive hints cannot convey.

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?

Extremely dense with no filler and correctly front-loaded with purpose, then requirements, then the polling loop. It reads as one long compound block rather than clearly separated sentences, which slightly hurts scanability for such a high-information payload.

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?

No output schema exists, yet the description supplies the return shape, the polling protocol, the timeout outcome, and the notification side effect — everything an agent needs to call it and then resolve the pending state.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so 3 is the baseline, but the description earns more: it explains the observable consequence of taskId (detail panel vs. inbox tab), the constraint that options forces a single choice while omission allows free text, and the timeout range with default and post-expiry behavior.

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 verb and resource ('Ask the human PAT holder a question') plus the mechanism ('wait for their answer via the get_user_input poll'), which cleanly separates it from the get_user_input sibling it depends on.

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?

Explicitly prescribes the follow-up workflow: 'poll get_user_input(requestId) until status changes', and distinguishes behavior with and without taskId (task detail panel vs. agent inbox Questions tab). An agent knows exactly when and how to call it, and what to do next.

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

All Onplana toolsInspect
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