Nopaque TotalPath

List Digital Connectors

listDigitalConnectors

Read-onlyIdempotent

List the saved connectors in your workspace: each names one bot a digital test can talk to, with an id, name, description, type (connect-chat, http-json, web-widget, lex-v2 or direct-line), targetRef (the stable name reports group runs by) and the connection settings for that type. A connector holds no password or secret: an http-json connector names a stored credential by reference only. Takes optional type, limit (1 to 200, default 50) and cursor. Use when: the user asks which bots are set up, or you need the targetRef of a bot to filter listDigitalTestRuns or read getDigitalComplianceAudit. Read-only. Needs digital:read.

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": "listDigitalConnectors"
  }
}

Input Schema

Name	Required	Description
`type`	No	Filter to one connector type. An unknown type is a 400, not an empty list.
`limit`	No	Rejected with 400 outside 1-200 rather than silently clamped.
`cursor`	No	Opaque base64 cursor from `nextCursor` in a previous response.

Output Schema

Name	Required	Description	Default
`connectors`	Yes
`nextCursor`	No	Opaque base64 cursor. Present ONLY when another page exists, and OMITTED (not null) on the last page.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so safety is covered; the description still adds real context by naming the required scope ('Needs digital:read') and stating that no secrets or passwords are stored, only credential references. That last point is behavior an agent could not infer from annotations or schema and matters when deciding whether it is safe to surface results.

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?

It is one dense but well-ordered paragraph: what it returns, what it does not expose, then parameters, then usage, then auth. Every clause carries information, though the redundant restatement of limit/cursor semantics adds bulk the schema already handles.

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?

With an output schema, rich annotations, and full schema descriptions, the description supplies the missing layer: usage triggers, auth scope, and the targetRef-to-downstream-tool relationship. The one completeness defect is the type enumeration that disagrees with the schema, which undercuts the filter guidance it is trying to give.

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 schema already carries the enum, the 1-200 bounds, the default of 50, and the cursor format; the description largely restates those. Worse, it lists five connector types ('connect-chat, http-json, web-widget, lex-v2 or direct-line') while the schema enum accepts only three, which could lead an agent to expect a filter value that would actually be rejected. Baseline 3 applies, with a small accuracy penalty baked in.

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 and resource ('List the saved connectors in your workspace') and immediately enumerates the returned fields (id, name, description, type, targetRef, connection settings). That field list alone tells an agent this is the collection view, distinct from the singular getDigitalConnector, without needing the schema.

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 gives an explicit 'Use when' clause with two concrete triggers: the user asking which bots exist, or needing a targetRef to feed listDigitalTestRuns or getDigitalComplianceAudit. It does not say when to prefer this over getDigitalConnector for a single known connector, so it stops short of full routing guidance.

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

All Nopaque TotalPath tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.