Plori

Official

by plori-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

List connections

list_connections

Read-only

List an authenticated account's third-party OAuth connections with provider status, scopes, and expiry; check needs_reauth to see if a human must reconnect, without exposing tokens.

Instructions

List the authenticated account's third-party OAuth connections, including each provider's status, authorization and expiry times, and configured scopes. Read needs_reauth for whether a human has to go and reconnect one; status is the same fact spelled out (authorized needs no action, reconnect_needed and unauthorized do). Never derive it from expires_at: tokens refresh lazily when used, so an authorized row may have a past expires_at, and authorized with expires_at=null means the grant never expires. Token and client-secret material is never returned.

Input Schema

TableJSON Schema

Name	Required	Description	Default
No arguments

Output Schema

TableJSON Schema

Name	Required	Description	Default
`connections`	Yes	Third-party OAuth connection status records; never secret material.

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedv0.16.0Sep 19, 2026

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "properties": {
+    "connections": {
+      "description": "Third-party OAuth connection status records; never secret material.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "authorized_at": {
+            "description": "When the grant was last authorized; null when there has never been one.",
+            "type": [
+              "null",
+              "string"
+            ]
+          },
+          "expires_at": {
+            "description": "When the current access token expires; null when the grant does not expire. A past value on an authorized row is normal — tokens refresh lazily when used.",
+            "type": [
+              "null",
+              "string"
+            ]
+          },
+          "needs_reauth": {
+            "description": "True when a human must reconnect this provider before it can be used. Read this rather than comparing expires_at to the clock.",
+            "type": "boolean"
+          },
+          "provider": {
+            "description": "The third-party provider this row is about.",
+            "type": "string"
+          },
+          "scopes": {
+            "description": "The scopes this provider is configured to request.",
+            "items": {
+              "type": "string"
+            },
+            "type": [
+              "null",
+              "array"
+            ]
+          },
+          "status": {
+            "description": "authorized, reconnect_needed, or unauthorized.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "provider",
+          "status",
+          "authorized_at",
+          "expires_at",
+          "scopes",
+          "needs_reauth"
+        ],
+        "type": "object"
+      },
+      "type": [
+        "null",
+        "array"
+      ]
+    }
+  },
+  "required": [
+    "connections"
+  ],
+  "type": "object"
+}

Addedv0.7.0Aug 9, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Annotations already mark it read-only, but the description adds substantial context beyond them: which fields are returned, that needs_reauth is the actionable flag while status is a spelled-out equivalent, that authorized rows may have a past expires_at due to lazy refresh, and that token/client-secret material is never returned.

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?

Front-loaded with what is listed before the interpretive detail, and the expires_at caveat is genuinely load-bearing rather than filler. It is dense and slightly run-on in the 'Never derive it from expires_at' stretch, but no sentence is wasted.

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?

Despite an output schema being present (so return shapes need not be explained), the description front-loads the field-level semantics an agent needs to act on the result, including the reauth decision tree and the lazy-refresh/null-expiry edge cases. Nothing needed to call or interpret it correctly is missing.

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

Parameters4/5

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

Zero parameters, so there is nothing to document and the baseline of 4 applies. No parameter syntax or meaning is missing.

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?

States a specific verb (List) and resource (authenticated account's third-party OAuth connections) plus the exact fields surfaced (provider status, authorization/expiry times, configured scopes). No sibling overlaps with this resource, so an agent can identify it immediately.

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?

No explicit when-to-use or when-not-to-use guidance and no alternatives named, though none of the siblings compete for this resource. It spends its words on how to read the result (needs_reauth, status) rather than routing, leaving usage implied.

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