Skip to main content
Glama
Sign In
mcp-screen

mcp-screen

by ashark-ai-05
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

ask_form

Present a small form on a canvas and block until the user submits or times out, returning validated field values so agents can collect structured human input.

Instructions

Ask the human to fill in a small form on the canvas and BLOCK until they press Submit (or the timeout passes). Field types: text, textarea, number, slider (needs min/max), select (needs options), checkbox. Returns {submitted:true, values:{fieldId: value}} or {submitted:false, reason}. Values are checked against the fields (required, min/max, options) before you get them.

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": {
      "prompt": "<prompt>",
      "fields": "<fields>"
    },
    "name": "ask_form"
  }
}

Input Schema

NameRequiredDescriptionDefault
detailNo
fieldsYes
promptYesWhat you need, e.g. "Configure the load test".
submitLabelNo
timeoutSecondsNoHow long to wait, default 180, max 900.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.1

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does so well: it discloses the blocking semantics, the timeout escape hatch, the exact return shapes for both success and failure, and that values are validated (required, min/max, options) before returning. It stops short of saying what a timeout yields in `reason`, whether the call errors or returns normally, or whether the form is per-canvas or global — the remaining behavioral gaps.

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 tight sentences, front-loaded with the action and the blocking consequence, then the field vocabulary, then the return contract. The parentheticals ('needs min/max', 'or the timeout passes') are dense but each carries information an agent would otherwise have to discover.

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 blocking, human-in-the-loop tool with no annotations and no output schema, the description supplies the essentials: that it blocks, how it ends, the success and failure payloads, and the field-type constraints. It omits the 180s default/max 900 timeout detail (left to the schema) and the 20-field cap, which are minor because structured fields carry them.

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 40%, so the description must compensate, and it partly does by stating that sliders need min/max and selects need options — a real constraint not encoded in the schema. But `detail`, `submitLabel`, and field-level `help`/`placeholder`/`default` get no explanation, and the field-type list largely restates the schema enum.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description gives a specific verb and resource — 'Ask the human to fill in a small form on the canvas' — plus the defining trait that it BLOCKs until Submit. That distinguishes it behaviorally from the sibling ask_user, though it never names ask_user, so an agent must infer which prompt mechanism to pick.

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

Usage Guidelines3/5

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

Usage is implied by the field-type catalog (structured multi-field input rather than a single question), but there is no explicit 'use this when… instead of ask_user/reply_annotation' statement and no guidance on when a blocking form is inappropriate. The agent has to infer the selection rule from sibling names alone.

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

Deploy Server

Other Tools