Forge Magery

list_audits

List security audits run on your domains, newest first.

Every argument is optional. domain matches domains whose name contains
the given text. date_from and date_to (each a calendar date) bound the
range an audit was started in, inclusive of both ends. source is how
the audit was started: "on_demand" for one requested directly, or
"autopilot" for one the account's automated schedule started.
audit_status is the audit's current stage: "new", "in_progress",
"done", or "error". result is its overall verdict once finished:
"green", "yellow", or "red". limit caps how many audits are returned in
one call (default 20, maximum 100). cursor requests the next page and
is the nextCursor value a previous call to this tool returned — omit it
for the first page.

Returns a page of audit summaries — each with the audit's id, when it
started, the domain it ran against, its status, result and numeric
score — plus nextCursor, which is present when another page follows and
absent on the last page.

Input Schema

Name	Required	Description	Default
`limit`	No
`cursor`	No
`domain`	No
`result`	No
`source`	No
`date_to`	No
`date_from`	No
`audit_status`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedOct 7, 2026

changedInput schema / properties / source / anyOf

Previous value: -[
-  {
-    "enum": [
-      "on_demand",
-      "autopilot"
-    ],
-    "type": "string"
-  },
-  {
-    "type": "null"
-  }
-]New value: +[
+  {
+    "enum": [
+      "on_demand",
+      "autopilot",
+      "admin"
+    ],
+    "type": "string"
+  },
+  {
+    "type": "null"
+  }
+]

First observedSep 16, 2026

TDQS

A4.2/5.0

Behavior4/5

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

No annotations are provided, so the description carries the full burden and does well: it discloses ordering (newest first), inclusive date bounds, pagination behavior (limit default 20/max 100, cursor from prior nextCursor, nextCursor presence signalling more pages), and that results are summaries. It omits auth/permission requirements and rate limits, keeping it short of a 5.

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?

Two front-loaded paragraphs: purpose and ordering first, then parameter semantics, then return shape. The length is justified by 8 parameters with zero schema descriptions, though the return-value paragraph is partly redundant given the output schema exists.

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 8-parameter, no-annotation list tool this is essentially complete: every filter's semantics, pagination contract, and the returned summary fields are covered, and the read-only nature is evident from 'List'. Only the undocumented 'admin' source enum value 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?

Schema description coverage is 0%, so the description must compensate and largely does: it defines substring matching for domain, inclusive range semantics for date_from/date_to, page mechanics for cursor/limit, and the meaning of every audit_status and result value. The one gap is source, whose schema enum includes 'admin' but the description explains only 'on_demand' and 'autopilot'.

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?

Opens with a specific verb+resource+scope: 'List security audits run on your domains, newest first.' The plural listing plus 'a page of audit summaries' clearly differentiates it from the singular get_audit / get_audit_status siblings, and the sort order is stated up front.

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?

Usage context is implied by 'List security audits run on your domains' and by the per-filter explanations, but there is no explicit routing guidance relative to siblings (e.g., when to use get_audit for full details versus this summary list) and no stated prerequisites or exclusions.

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

All Forge Magery tools Inspect

Try in Browser

Shareable, User-Owned Context BackendPeople, applications, and agents read, write, and coordinate together in one context lake. Reach it over MCP, a CLI, a Python SDK, or REST.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?