Plori

Official

by plori-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

List pending questions

list_pending_inputs

Read-only

Lists agent runs paused for human approval or input, including write-consent requests with always_allow and scope options. Excludes sessions already superseded by later runs.

Instructions

List the agent's runs that are paused awaiting a human approval or input (the HITL queue). A row with a "consent_tool" is a write-consent approval: answering it with always_allow=true also stops the agent asking for that tool, and scope="thread" allows only the rest of this conversation's calls to the same connection, method and host. A request whose session has already moved on is not listed: a later run in that conversation has completed, so answering it would resume a superseded turn.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`agent_id`	Yes	The agent's UUID.

Output Schema

TableJSON Schema

Name	Required	Description	Default
`pending_inputs`	Yes	Runs currently parked on a human approval or input request. A request whose session has already moved on is left out: answering it would resume a superseded turn.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.16.0Sep 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "pending_inputs": {
+      "description": "Runs currently parked on a human approval or input request. A request whose session has already moved on is left out: answering it would resume a superseded turn.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "agent_id": {
+            "type": "string"
+          },
+          "args": {
+            "description": "Arbitrary JSON owned by the producing engine."
+          },
+          "connect": {
+            "additionalProperties": false,
+            "properties": {
+              "provider": {
+                "type": "string"
+              },
+              "workflow_id": {
+                "type": "string"
+              }
+            },
+            "required": [
+              "workflow_id",
+              "provider"
+            ],
+            "type": [
+              "null",
+              "object"
+            ]
+          },
+          "consent_tool": {
+            "type": "string"
+          },
+          "created_at": {
+            "type": "string"
+          },
+          "expires_at": {
+            "type": [
+              "null",
+              "string"
+            ]
+          },
+          "id": {
+            "type": "string"
+          },
+          "kind": {
+            "type": "string"
+          },
+          "prompt": {
+            "type": "string"
+          },
+          "risk": {
+            "type": "string"
+          },
+          "run_id": {
+            "type": "string"
+          },
+          "schema": {
+            "description": "Arbitrary JSON owned by the producing engine."
+          },
+          "secret": {
+            "type": "boolean"
+          },
+          "status": {
+            "type": "string"
+          },
+          "tool_call_id": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "id",
+          "run_id",
+          "agent_id",
+          "tool_call_id",
+          "kind",
+          "prompt",
+          "status",
+          "created_at"
+        ],
+        "type": "object"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    }
+  },
+  "required": [
+    "pending_inputs"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jul 4, 2026

TDQS

A4.5/5.0

Behavior5/5

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

Beyond the readOnlyHint annotation, the description explains significant behaviors: it lists only paused runs, it includes consent_tool approval semantics with always_allow=true and scope='thread', and it explicitly notes that stale/superseded requests are omitted. This provides actionable detail that annotations alone do not convey.

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 compact and information-dense, with the core purpose stated first and important behavioral caveats following. Every sentence adds meaningful value, and the length is appropriate for the complexity of the HITL semantics being explained.

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?

Given the single parameter, the presence of an output schema, and the readOnlyHint annotation, the description covers the essential context for correct use: what is listed, what the consent_tool rows mean, and how stale requests are handled. No critical operational questions remain unanswered for an agent invoking this tool.

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?

The only parameter, agent_id, is fully described in the schema as 'The agent's UUID.' The description adds minimal interpretive value beyond implying the tool lists runs for a given agent, so it meets the baseline for high schema coverage without adding much new semantic insight.

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 states a specific verb ('List') and a well-defined resource ('the agent's runs that are paused awaiting a human approval or input'), clearly identifying this as the HITL queue listing tool. This distinguishes it from related tools like answer_pending_input by focusing on listing pending items rather than resolving them.

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 gives clear context about what the tool returns and even explains when requests are excluded (if the session has moved on). It does not explicitly name sibling alternatives or state 'use this instead of X', but the domain is straightforward enough that an agent can infer when listing pending inputs is appropriate.

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