action1-mcp-server

Export of audit trail data

action1_export_audit_log

Read-onlyIdempotent

Extract complete audit trail data from the system. Filter results by date range or event name, and download the report in your preferred format (CSV, HTML).

Instructions

Export of audit trail data. Exports audit data. Use parameters to filter out exported data. Perm: view_audit.

Input Schema

Name	Required	Description
`from`	No	Provide the number of the first record to be returned.
`event`	No	The list of comma-separated event names to include.
`limit`	No	Set the maximum number of items to be returned (the page size).
`filter`	No	Provide a case-insensitive substring to filter and narrow down returned results (i.e., if...
`format`	No	Specify the report format.
`sortby`	No	Define the sorting order by a certain field.
`timeto`	No	The end date and time in the following format: YYYY-MM-DD_HH-MM-SS
`from_id`	No	Provide the sequential ID of the first record to be returned.
`verbose`	No	Skip per-item compactor.
`timefrom`	No	The start date and time in the following format: YYYY-MM-DD_HH-MM-SS
`response_format`	No	Output format. Default markdown.

Output Schema

Name	Required	Description	Default
`value`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed13 schema fields changedv0.6.0Oct 26, 2026

changedInput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

addedInput schema / properties / from / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / from / minimum
```
Added value: +0
```
addedInput schema / properties / limit / maximum
```
Added value: +50000
```
addedInput schema / properties / limit / minimum
```
Added value: +1
```

changedInput schema / properties / limit / type

Previous value: -"number"New value: +"integer"

removedInput schema / properties / timefrom / format
```
Removed value: -"date-time"
```

addedInput schema / properties / timefrom / pattern

Added value: +"^(?:\\d{4}-\\d{2}-\\d{2}_\\d{2}-\\d{2}-\\d{2}|\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d+)?(?:Z|[+-]\\d{2}:?\\d{2}))$"

removedInput schema / properties / timeto / format
```
Removed value: -"date-time"
```

addedInput schema / properties / timeto / pattern

Added value: +"^(?:\\d{4}-\\d{2}-\\d{2}_\\d{2}-\\d{2}-\\d{2}|\\d{4}-\\d{2}-\\d{2}T\\d{2}:\\d{2}:\\d{2}(?:\\.\\d+)?(?:Z|[+-]\\d{2}:?\\d{2}))$"

changedOutput schema / $schema

Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"

changedOutput schema / additionalProperties
```
Previous value: -trueNew value: +{}
```
addedOutput schema / properties / value
```
Added value: +{}
```

First observedv0.5.0Jun 27, 2026

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already establish that this is a read-only, idempotent, non-destructive, open-world operation. The description adds the important authorization requirement 'Perm: view_audit,' but it does not disclose export scope, output format behavior, pagination limits, or large-export handling, leaving substantial behavioral context to the schema.

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

Conciseness2/5

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

The first two sentences are redundant restatements of the same purpose, and the third sentence is vague. The definition is short but not efficient because it repeats itself and omits more useful details.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For an export tool with 11 parameters, optional time filters, format controls, pagination limits, and an output schema, the description is too sparse. It gives the required permission but does not clarify export scope, when to use it over audit search/list tools, or how filters and formats affect the exported result.

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 all 11 parameters are already documented in the input schema. The description only says to use parameters to filter exported data, which adds no specific meaning about time ranges, event filtering, format selection, pagination, or sorting beyond what the schema provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: exporting audit trail data. However, it does not distinguish this export tool from sibling tools such as action1_list_audit_events, action1_audit_log_search, or action1_get_export_for_report, so an agent must infer when export is preferred over search or listing.

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

Usage Guidelines2/5

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

The only usage guidance is 'Use parameters to filter out exported data,' which is vague and does not explain when to use this export tool versus audit search or listing alternatives. The permission note is useful but is not usage guidance.

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

Deploy Server