nofax

Request human choice

nofax_request_choice

Send up to three explicit options to a human for a decision, returning a pending requestId to poll until resolved; avoid deciding on their behalf.

Instructions

Send up to three explicit options to the phone and return a durable pending requestId. IMPORTANT: call nofax_wait_for_response and repeat while pending; do not choose on the human's behalf.

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": {
      "message": "<message>",
      "options": "<options>"
    },
    "name": "nofax_request_choice"
  }
}

Input Schema

Name	Required	Description
`title`	No	Optional choice prompt title shown to the human; defaults to "Nofax choice".
`message`	Yes	Question or decision context shown to the human.
`options`	Yes	One to three explicit choices to present to the human.

Output Schema

Name	Required	Description
`status`	Yes	The request is unresolved and must not be treated as approval.
`mustWait`	Yes	Signals that the caller must keep waiting for a terminal human response.
`requestId`	Yes	Durable Nofax request handle.
`instruction`	Yes	Fail-closed next-step instruction for the caller.

Schema Changelog

Changes observed during successful MCP inspections.

Changed5 schema fields changedv0.2.7Sep 22, 2026

addedInput schema / properties / message / description

Added value: +"Question or decision context shown to the human."

addedInput schema / properties / options / description

Added value: +"One to three explicit choices to present to the human."

changedInput schema / properties / options / items / anyOf

Previous value: -[
-  {
-    "maxLength": 80,
-    "minLength": 1,
-    "type": "string"
-  },
-  {
-    "properties": {
-      "label": {
-        "maxLength": 32,
-        "minLength": 1,
-        "type": "string"
-      },
-      "value": {
-        "maxLength": 80,
-        "minLength": 1,
-        "type": "string"
-      }
-    },
-    "required": [
-      "value",
-      "label"
-    ],
-    "type": "object"
-  }
-]New value: +[
+  {
+    "description": "String shorthand for a choice value; its first 32 characters are also used as the human-facing label.",
+    "maxLength": 80,
+    "minLength": 1,
+    "type": "string"
+  },
+  {
+    "properties": {
+      "label": {
+        "description": "Short human-facing label displayed for this choice.",
+        "maxLength": 32,
+        "minLength": 1,
+        "type": "string"
+      },
+      "value": {
+        "description": "Choice value returned as the terminal human decision.",
+        "maxLength": 80,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "value",
+      "label"
+    ],
+    "type": "object"
+  }
+]

addedInput schema / properties / title / description

Added value: +"Optional choice prompt title shown to the human; defaults to \"Nofax choice\"."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "instruction": {
+      "description": "Fail-closed next-step instruction for the caller.",
+      "minLength": 1,
+      "type": "string"
+    },
+    "mustWait": {
+      "const": true,
+      "description": "Signals that the caller must keep waiting for a terminal human response.",
+      "type": "boolean"
+    },
+    "requestId": {
+      "description": "Durable Nofax request handle.",
+      "maxLength": 84,
+      "minLength": 24,
+      "type": "string"
+    },
+    "status": {
+      "const": "pending",
+      "description": "The request is unresolved and must not be treated as approval.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "requestId",
+    "mustWait",
+    "instruction"
+  ],
+  "type": "object"
+}

First observedv0.2.1Sep 21, 2026

TDQS

A4.3/5.0

Behavior4/5

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

Beyond the annotations, the description adds that the returned requestId is durable, that the request remains pending, and that the caller must poll rather than assume a terminal answer. It also explicitly forbids deciding for the human, which is useful behavioral guidance. No contradiction with 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?

Two tight sentences with no filler. The core behavior and return value come first, followed by a high-value usage warning. The 'IMPORTANT' note earns its place.

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?

For a tool with a fully documented schema and output schema, the description covers the critical workflow details: send options, receive pending requestId, poll with wait_for_response, and avoid self-serving decisions. Nothing essential is missing.

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 coverage is 100%, so the baseline is 3. The description only reinforces the 'up to three options' constraint and does not add meaning beyond what the schema already documents for message, title, and options.

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 clearly states the action: send up to three explicit options to the phone and return a durable pending requestId. This distinguishes it from the sibling tools, especially nofax_notify, nofax_request_approval, and nofax_request_refinement.

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 provides a clear operational protocol: call nofax_wait_for_response and repeat while pending, and do not choose on the human's behalf. It does not formally enumerate when to use this versus the other request-type siblings, but the context is sufficiently clear.

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

Deploy Server