Skip to main content
Glama
Sign In
nofax

nofax

by AKzar1el
OverviewSchemaSourceRelated ServersDiscussionsAdmin
JavaScript
Hybrid

List pending Nofax requests

nofax_list_pending
Read-onlyIdempotent

Recover unresolved Nofax requests after interruption by listing pending handles. Specify an optional limit to control the result set; secret response topics are never exposed.

Instructions

List a bounded set of unresolved Nofax request handles for recovery after client or conversation interruption. Secret response topics are never returned.

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "nofax_list_pending"
  }
}

Input Schema

NameRequiredDescriptionDefault
limitNoMaximum number of unresolved requests to return; defaults to 20.

Output Schema

NameRequiredDescriptionDefault
statusYesThe pending-request scan completed successfully.
requestsYesBounded unresolved request projections with no secret response topics.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.2.7
    • addedInput schema / properties / limit / description
      Added value: +"Maximum number of unresolved requests to return; defaults to 20."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "https://json-schema.org/draft/2020-12/schema",
+  "additionalProperties": false,
+  "properties": {
+    "requests": {
+      "description": "Bounded unresolved request projections with no secret response topics.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "createdAt": {
+            "description": "ISO-8601 creation timestamp.",
+            "minLength": 1,
+            "type": "string"
+          },
+          "decision": {
+            "description": "Terminal human decision when resolved.",
+            "maxLength": 80,
+            "minLength": 1,
+            "type": "string"
+          },
+          "kind": {
+            "description": "Interaction mode that created the durable request.",
+            "enum": [
+              "approval",
+              "choice",
+              "refinement"
+            ],
+            "type": "string"
+          },
+          "requestId": {
+            "description": "Durable Nofax request handle.",
+            "maxLength": 84,
+            "minLength": 24,
+            "type": "string"
+          },
+          "resolvedAt": {
+            "description": "ISO-8601 terminal-response timestamp when resolved.",
+            "minLength": 1,
+            "type": "string"
+          },
+          "status": {
+            "description": "Current durable request state.",
+            "enum": [
+              "pending",
+              "resolved"
+            ],
+            "type": "string"
+          },
+          "text": {
+            "description": "Human refinement text when one was supplied.",
+            "maxLength": 2000,
+            "minLength": 1,
+            "type": "string"
+          }
+        },
+        "required": [
+          "requestId",
+          "kind",
+          "status",
+          "createdAt"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "status": {
+      "const": "ok",
+      "description": "The pending-request scan completed successfully.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "requests"
+  ],
+  "type": "object"
+}
  2. First observedv0.2.1

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already establish readOnlyHint, idempotentHint, and destructiveHint, but the description adds valuable behavioral context: it returns a bounded set and never returns secret response topics. This goes beyond the schema and 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?

The description is only two sentences and every clause earns its place. The main purpose and the critical security exclusion are both front-loaded without wasted words.

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 simple read-only list operation with one optional parameter Roy and a rich output schema, the description covers the essential context. It explains why the tool exists and the sensitive exclusion, though it could slightly enhance guidance on when to prefer this over get_request.

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 single 'limit' parameter is already fully documented. The description's mention of a 'bounded set' loosely ties to the limit but does not add specific syntax, defaults, or edge-case guidance beyond the schema.

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 has a specific verb ('List'), a clear resource (pending Nofax request handles), and a purpose ('recovery after client or conversation interruption'). It also distinguishes itself from siblings like get_request by focusing on pending handles rather than retrieving a single request.

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?

The description conveys a clear usage context: use this tool after client or conversation interruption to recover unresolved handles. It does not explicitly name alternatives or exclusions, but the purpose statement is specific enough to guide selection among siblings.

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