Nopaque TotalPath

Read the Activity Log

listAuditEvents

Read-onlyIdempotent

Read the workspace's activity log, newest first: who changed what and when, and how (in the web app, with an API key, or by nopaque staff). Covers API keys, members and roles, billing, tests and their schedules, load tests, batches, sweeps, mapping jobs, imports, phone numbers and caller ID, alert rules and destinations. Filters: category (access, keys, billing, workspace, testing, numbers, assistant), action (e.g. api_key.created), actor (a user id or API key id), target (type:id, e.g. test:), from/to (dates), limit (at most 100) and cursor (nextCursor from the previous page, sent with from = the previous window.from). Use cases: "who changed our API keys last week" (category keys), "who deleted that test" (target test:), "what did this key do" (actor ). Entries hold ids, not names: name a test with getTestConfig or getMissionTestConfig. nopaque staff show with no id. Only entries inside the plan's window (window in the response) are returned. Needs an Enterprise workspace and an API key created by an owner or admin with the audit:read scope by name; a key with full access (*) or with no scopes is refused (403), and a key made by a billing admin reads only the billing category. Every call through this server counts as a call with an API key. Read-only.

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

Input Schema

Name	Required	Description
`to`	No	End of the range. A date alone means the whole of that day.
`from`	No	Start of the range. Earlier than the plan's window counts as the window's start.
`actor`	No	Only actions by this user id or API key id.
`limit`	No	Entries per page, at most 100.
`action`	No	Only this action, e.g. `api_key.created`.
`cursor`	No	`nextCursor` from the previous page. Send `from` = the previous `window.from` with it.
`target`	No	Only actions on this record, as `type:id`, e.g. `test:3f2a...`.
`category`	No	Only this category.

Output Schema

Name	Required	Description
`window`	Yes	How far back the workspace's plan shows the log.
`entries`	Yes
`nextCursor`	No	Pass back as `cursor`, with `from` set to `window.from`, for the next page.
`windowApplied`	Yes	True when the plan's window set the start of the range.

Schema Changelog

Changes observed during successful MCP inspections.

First observedNov 11, 2026

TDQS

A4.9/5.0

Behavior5/5

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

Beyond the read-only/idempotent annotations it discloses auth and scope requirements, the 403 refusal conditions, the billing-admin category restriction, the plan-window truncation (only entries inside window are returned), pagination mechanics via nextCursor plus window.from, and the fact that entries carry ids rather than names and staff appear without an id. This is unusually rich behavioral context for a read tool.

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?

It is dense but front-loaded: what the log is and its ordering come first, then coverage, then filter semantics, then use cases, then prerequisites and caveats. No sentence is filler, though the inline enumeration of category values is the one spot that duplicates structured data.

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?

For an eight-parameter audit query with an output schema, everything an agent needs is present: scope/auth gating, the plan-window limitation on results, pagination protocol, id-vs-name caveat with the sibling tools that resolve names, and how staff actors are represented.

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 100%, so baseline is 3; the description still adds meaning by tying parameters to query intents (actor as user id vs API key id, target as type:id) and by restating the cursor/from coupling and the 100-entry cap. Some of the filter listing (the category names) merely repeats the schema enum, which keeps this below 5.

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 plus ordering ("Read the workspace's activity log, newest first: who changed what and when, and how"), then enumerates the exact domain covered (API keys, members, billing, tests, load tests, batches, sweeps, mappings, imports, numbers, alert rules). It also distinguishes itself from name-resolving siblings by pointing to getTestConfig/getMissionTestConfig for turning ids into names.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Three concrete use cases are given with the filter that answers each ("who changed our API keys last week" -> category keys; "who deleted that test" -> target test:<id>; "what did this key do" -> actor <key id>), which is exactly the when-to-use information an agent needs. It also states prerequisites (Enterprise workspace, owner/admin-created key with audit:read by name) and the failure modes (403 for full-access or scope-less keys, billing admin sees only billing), so an agent can decide before calling.

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.