portkey-admin-mcp

list_audit_logs

Read-onlyIdempotent

Lists Portkey organization audit log records within a time range for compliance and incident review, filtering state-changing API requests by user, workspace, action, status, and more.

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

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

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.

Changed2 schema fields changedv1.0.9Oct 26, 2026

changedInput schema / $schema

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

changedOutput schema / $schema

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

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.6/5.0

Behavior5/5

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

Annotations already declare readOnly/idempotent/openWorld, so the bar is lower, yet the description still adds real behavior: Enterprise-only entitlement, a 403 on non-Enterprise plans, the time-range scoping requirement, and the filter semantics of what counts as an audit record. No contradiction with readOnlyHint — it only reads records.

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, gating, and the alternative-use clause. The long field inventory is the weakest element since an output schema exists, so it partly duplicates structured data rather than earning full space.

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, gated, paginated read tool, the description covers entitlement, failure mode, scope, and routing to the alternative. Pagination details are left to the schema, which is acceptable given 100% coverage and an output schema.

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 every filter is already documented and the baseline applies. The description's field enumeration describes returned record fields, not the filter parameters, and adds no filter syntax or combination guidance beyond what the schema provides.

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 and resource (list audit log records) plus the scope (Portkey organization, time range), and immediately distinguishes the content: only state-changing requests (POST/PUT/DELETE). That differentiator is not derivable from the name and separates it cleanly from log/analytics siblings.

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 assigns the tool to compliance/incident review of individual events and names the alternative ('use analytics instead for aggregates'). It also states the gating condition (Enterprise plan only), so an 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