portkey-admin-mcp

list_audit_logs

Read-onlyIdempotent

Lists audit log records for Portkey organizations within a time range to support compliance and incident review. Enterprise plan only; other plans receive a permissions error.

Instructions

List audit log records for a Portkey organization within a time range (Enterprise plan only; other plans get a permissions error). Each record is a state-changing API request (POST, PUT, or DELETE) with timestamp, method, uri, request_id, user_id, user_type (user or api_key), organisation_id, workspace_id, response_status_code, resource_type, action, client_ip, country, plus request_body, query_params, and request_headers as JSON strings. Use it for compliance or incident review of individual events; use analytics instead for aggregates. Enterprise-gated. Returns 403 on non-Enterprise Portkey plans.

Input Schema

TableJSON Schema

Name	Required	Description
`uri`	No	Filter by request URI path
`action`	No	Filter by action type (e.g., 'create', 'update', 'delete')
`method`	No	Filter by HTTP method of the audited request
`country`	No	Filter by country derived from the client IP
`user_id`	No	Filter by the ID of the user or API key that made the request
`end_time`	Yes	End of time range filter (ISO 8601 format, e.g., '2024-01-31T23:59:59Z')
`client_ip`	No	Filter by client IP address
`page_size`	No	Number of results per page (max 100)
`user_type`	No	Filter by whether the request came from a user or an API key
`request_id`	No	Filter by request ID
`start_time`	Yes	Start of time range filter (ISO 8601 format, e.g., '2024-01-01T00:00:00Z')
`current_page`	No	Zero-based page number; the first page is 0
`workspace_id`	No	Filter audit logs by workspace ID
`resource_type`	No	Filter by resource type (e.g., 'workspace', 'config', 'virtual_key')
`organisation_id`	Yes	Organisation ID whose audit logs to list
`response_status_code`	No	Filter by HTTP response status code (e.g., 200, 403)

Output Schema

TableJSON Schema

Name	Required	Description
`ok`	Yes	Whether the tool call succeeded and returned structured data
`data`	No	Structured success payload when ok is true
`error`	No	Structured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

Changed14 schema fields changedv0.12.2Oct 2, 2026

changedInput schema / properties / action / description

Previous value: -"Filter by action type (e.g., 'create', 'update', 'delete', 'login')"New value: +"Filter by action type (e.g., 'create', 'update', 'delete')"

removedInput schema / properties / actor_id

Removed value: -{
-  "description": "Filter by the user ID who performed the action",
-  "type": "string"
-}

addedInput schema / properties / client_ip

Added value: +{
+  "description": "Filter by client IP address",
+  "type": "string"
+}

addedInput schema / properties / country

Added value: +{
+  "description": "Filter by country derived from the client IP",
+  "type": "string"
+}

addedInput schema / properties / method

Added value: +{
+  "description": "Filter by HTTP method of the audited request",
+  "enum": [
+    "POST",
+    "PUT",
+    "DELETE"
+  ],
+  "type": "string"
+}

addedInput schema / properties / organisation_id

Added value: +{
+  "description": "Organisation ID whose audit logs to list",
+  "type": "string"
+}

addedInput schema / properties / request_id

Added value: +{
+  "description": "Filter by request ID",
+  "type": "string"
+}

removedInput schema / properties / resource_id

Removed value: -{
-  "description": "Filter by specific resource ID",
-  "type": "string"
-}

changedInput schema / properties / resource_type / description

Previous value: -"Filter by resource type (e.g., 'user', 'workspace', 'config', 'virtual_key')"New value: +"Filter by resource type (e.g., 'workspace', 'config', 'virtual_key')"

addedInput schema / properties / response_status_code

Added value: +{
+  "description": "Filter by HTTP response status code (e.g., 200, 403)",
+  "maximum": 9007199254740991,
+  "minimum": -9007199254740991,
+  "type": "integer"
+}

addedInput schema / properties / uri

Added value: +{
+  "description": "Filter by request URI path",
+  "type": "string"
+}

addedInput schema / properties / user_id

Added value: +{
+  "description": "Filter by the ID of the user or API key that made the request",
+  "type": "string"
+}

addedInput schema / properties / user_type

Added value: +{
+  "description": "Filter by whether the request came from a user or an API key",
+  "enum": [
+    "user",
+    "api_key"
+  ],
+  "type": "string"
+}

addedInput schema / required

Added value: +[
+  "start_time",
+  "end_time",
+  "organisation_id"
+]

Changed3 schema fields changedv0.11.5Sep 8, 2026
- changedInput schema / properties / current_page / description
```
Previous value: -"Page number for pagination (starts at 1)"New value: +"Zero-based page number; the first page is 0"
```
- removedInput schema / properties / current_page / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / current_page / minimum
```
Added value: +0
```
Changed3 schema fields changedv0.5.0Jul 14, 2026
- addedInput schema / properties / current_page / maximum
```
Added value: +9007199254740991
```
- changedInput schema / properties / current_page / type
```
Previous value: -"number"New value: +"integer"
```
- changedInput schema / properties / page_size / type
```
Previous value: -"number"New value: +"integer"
```
Addedv1.0.1May 7, 2026
RemovedMay 1, 2026
First observedJan 1, 2026

TDQS

A4.4/5.0

Behavior4/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive), and the description adds real value beyond them: the Enterprise-plan prerequisite, the 403 failure mode on non-Enterprise plans, and the exact shape of each returned record. It stops short of describing pagination behavior despite page_size/current_page params.

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?

Front-loaded with purpose, scope, and gating, and each sentence carries information. Slightly redundant: 'Enterprise plan only' and the 403 consequence are stated twice, and the long field enumeration repeats what the output schema already covers.

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 a 16-parameter, read-only listing tool with an output schema, the description covers purpose, scope, plan gating, failure mode, and sibling disambiguation. Nothing an agent needs to select or invoke it correctly is missing.

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 description coverage is 100%, so all 16 filter parameters are already documented in the schema, which sets the baseline at 3. The description enumerates record fields rather than filter semantics, adding little beyond what the schema and output schema provide.

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?

States a specific verb+resource ('List audit log records for a Portkey organization within a time range') and immediately bounds the scope to state-changing API requests. It distinguishes itself from the analytics siblings by naming what each record represents.

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?

Explicitly routes usage: 'Use it for compliance or incident review of individual events; use analytics instead for aggregates.' It also flags the Enterprise gating and the resulting 403, so the agent knows when the call will fail before attempting it.

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

Deploy Server