GreatWait

List API credentials

credentials_list

Read-onlyIdempotent

Lists the credentials issued for the caller's own project, oldest first, one page at a time. The authority tuple comes from the verified principal, so there is no parameter that could name another project — a listing is the caller's own book or nothing. Revoked and rotated credentials stay in the listing and carry the fields that say so; a credential nobody can see is a credential nobody can audit. limit is bounded by the contract and cursor is the opaque value the previous page returned. No page carries a secret: the item is the read shape, which has no field one could be put in.

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

Input Schema

Name	Required	Description	Default
`limit`	No
`cursor`	No

Output Schema

Name	Required	Description	Default
`data`	Yes
`freshness`	Yes
`nextCursor`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedNov 4, 2026

removedOutput schema / properties / data / items / properties / environmentKind

Removed value: -{
-  "enum": [
-    "test",
-    "live"
-  ],
-  "type": "string"
-}

changedOutput schema / properties / data / items / required

Previous value: -[
-  "createdAt",
-  "displayPrefix",
-  "environmentKind",
-  "id",
-  "project",
-  "scopes"
-]New value: +[
+  "createdAt",
+  "displayPrefix",
+  "id",
+  "project",
+  "scopes"
+]

Changed1 schema field changedNov 2, 2026

addedOutput schema / properties / data / items / properties / name

Added value: +{
+  "maxLength": 80,
+  "minLength": 1,
+  "pattern": "^[^\\p{C}]+$",
+  "type": "string"
+}

First observedOct 10, 2026

TDQS

A4.5/5.0

Behavior5/5

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

With annotations the bar is lower, yet the description still carries real weight: it declares oldest-first ordering, one-page-at-a-time pagination, that revoked and rotated credentials remain visible with the fields that mark them, and that no page contains a secret. None of that is in the annotations.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Scope and ordering are correctly front-loaded, but the prose is padded with editorial asides ("a credential nobody can see is a credential nobody can audit") that cost tokens without adding callable information.

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?

The output schema exists, so return values need not be spelled out, and the description still notes the response is the read shape with no secret field. Combined with ordering, pagination, and the own-project constraint, an agent has everything needed to call it correctly.

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?

Schema coverage is 0%, so the description must carry the parameter burden. It explains cursor well ("the opaque value the previous page returned") but describes limit only as "bounded by the contract" without giving the 1–100 range or the default of 25 that the schema holds.

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 opens with a specific verb and resource ("Lists the credentials issued for the caller's own project") and adds scope, ordering (oldest first), and paging. That is enough to separate it from the write siblings credentials_revoke and credentials_rotate without opening any 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?

The stated scope ("the caller's own project ... a listing is the caller's own book or nothing") and the audit rationale tell the agent clearly when this tool applies. It stops short of naming the alternatives explicitly, so it does not reach the routing precision of a 5, but the read-versus-revoke/rotate split is unmistakable.

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

All GreatWait 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.

Resources

Need Help?