Skip to main content
Glama

Ask user

ask_user

Presents a specific question and options to the user and waits for a reply. The response can include the user's selection and a selection token for an account-bound choice.

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>",
      "project_id": "<project_id>"
    },
    "name": "ask_user"
  }
}

Input Schema

NameRequiredDescriptionDefault
questionYes
project_idYesExplicit project identifier for this request. The connection's navigation pointer does not select the target.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / project_id / description
      Previous value: -"Required immutable scope for this call. Copy the id from list_projects/open_project/project_state; the active-project pointer is never used to guess."New value: +"Explicit project identifier for this request. The connection's navigation pointer does not select the target."
  2. First observed

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=false, idempotentHint=false and destructiveHint=false, so the agent knows this is a mutating, non-repeatable interaction. The description adds real behavioral context beyond that – it blocks and waits for a reply, and the reply may carry a selection token – but it says nothing about timeouts, what happens if the user does not answer, or whether the call consumes a turn.

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?

Two short sentences, front-loaded with the action and followed by what comes back; there is no filler. The only inefficiency is that the second sentence describes a return value partially while omitting the options/response-shape detail the first sentence promises.

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

Completeness3/5

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

For a two-parameter blocking interaction with no output schema, the description carries the burden of explaining the response and does so in part (selection plus token). It leaves two significant holes: where the 'options' presented to the user come from given no such parameter, and what the agent should expect if no reply arrives.

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

Parameters2/5

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

Schema coverage is only 50%: project_id is documented but 'question' is not, so the description must compensate and does not (no format, length, or phrasing guidance). Worse, it advertises 'options' that the user can select from, yet no such parameter exists in the schema, which can send an agent hunting for a field that isn't there.

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 concrete verb and resource: it presents a question to the user and waits for a reply, which is unmistakably different from every sibling tool (all of which are video-editing operations). It stops short of stating the purpose of such interaction (confirmation vs. preference gathering), so it is clear but not fully differentiated in intent.

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 only implied: the mention of an 'account-bound choice' hints at when this tool is appropriate (irreversible or account-scoped decisions), but there is no explicit when-to-use guidance, no when-not-to-use, and no statement of what to do if a sibling tool could resolve the ambiguity instead.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.