portkey-admin-mcp

get_request_analytics

Read-onlyIdempotent

Retrieve request-volume time-series data to monitor traffic and reliability trends, including total, successful, and failed request counts per time bucket.

Instructions

Get request-volume time-series data with summary.total_requests, summary.successful_requests, summary.failed_requests, and per-bucket total/success/failed counts. Use this for traffic and reliability trends; use get_error_analytics when you only need error counts. Enterprise-gated. Returns 403 on non-Enterprise Portkey plans.

Input Schema

TableJSON Schema

Name	Required	Description
`configs`	No	Legacy Portkey query param for config slugs. Comma-separated string; prefer config_slugs for structured inputs.
`span_id`	No	Legacy Portkey query param for span IDs. Comma-separated string; prefer span_ids for structured inputs.
`cost_max`	No	Maximum cost in cents to filter by
`cost_min`	No	Minimum cost in cents to filter by
`metadata`	No	Legacy Portkey query param for metadata filtering. Stringified JSON object, e.g. '{"env":"prod","app":"myapp"}'; prefer metadata_filter for structured inputs.
`span_ids`	No	Structured alias for span_id. Use an array of span IDs; normalized to the legacy comma-separated Portkey query param.
`trace_id`	No	Legacy Portkey query param for trace IDs. Comma-separated string; prefer trace_ids for structured inputs.
`trace_ids`	No	Structured alias for trace_id. Use an array of trace IDs; normalized to the legacy comma-separated Portkey query param.
`api_key_ids`	No	Legacy Portkey query param for API key UUIDs. Comma-separated string; request_analytics also accepts an array and normalizes it to this form.
`prompt_slug`	No	Filter by prompt slug
`status_code`	No	Legacy Portkey query param for HTTP status codes. Comma-separated string; prefer status_codes for structured inputs.
`ai_org_model`	No	Legacy Portkey query param for provider/model pairs. Format: 'provider__model' with double underscore, e.g. 'openai__gpt-4' or 'anthropic__claude-3-opus'. Comma-separated string; prefer provider_models for structured inputs.
`config_slugs`	No	Structured alias for configs. Use an array of config slugs; normalized to the legacy comma-separated Portkey query param.
`status_codes`	No	Structured alias for status_code. Use an array of HTTP status codes; normalized to the legacy comma-separated Portkey query param.
`virtual_keys`	No	Legacy Portkey query param for virtual key slugs. Comma-separated string; prefer virtual_key_slugs for structured inputs.
`workspace_slug`	No	Filter by specific workspace
`metadata_filter`	No	Structured alias for metadata. Use an object such as { env: 'prod' }; normalized to a JSON string before the request is sent.
`provider_models`	No	Structured alias for ai_org_model. Use provider__model strings in an array; normalized to the legacy comma-separated Portkey query param.
`total_units_max`	No	Maximum number of total tokens to filter by
`total_units_min`	No	Minimum number of total tokens to filter by
`prompt_token_max`	No	Maximum number of prompt tokens
`prompt_token_min`	No	Minimum number of prompt tokens
`virtual_key_slugs`	No	Structured alias for virtual_keys. Use an array of virtual key slugs; normalized to the legacy comma-separated Portkey query param.
`completion_token_max`	No	Maximum number of completion tokens
`completion_token_min`	No	Minimum number of completion tokens
`weighted_feedback_max`	No	Maximum weighted feedback score (-10 to 10)
`weighted_feedback_min`	No	Minimum weighted feedback score (-10 to 10)
`time_of_generation_max`	Yes	End time for the analytics period (ISO8601 format, e.g., '2024-02-01T00:00:00Z')
`time_of_generation_min`	Yes	Start time for the analytics period (ISO8601 format, e.g., '2024-01-01T00:00:00Z')

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.

Changed16 schema fields changedv0.11.5Sep 8, 2026
- removedInput schema / properties / completion_token_max / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / completion_token_max / minimum
```
Added value: +0
```
- removedInput schema / properties / completion_token_min / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / completion_token_min / minimum
```
Added value: +0
```
- removedInput schema / properties / cost_max / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / cost_max / minimum
```
Added value: +0
```
- removedInput schema / properties / cost_min / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / cost_min / minimum
```
Added value: +0
```
- removedInput schema / properties / prompt_token_max / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / prompt_token_max / minimum
```
Added value: +0
```
- removedInput schema / properties / prompt_token_min / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / prompt_token_min / minimum
```
Added value: +0
```
- removedInput schema / properties / total_units_max / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / total_units_max / minimum
```
Added value: +0
```
- removedInput schema / properties / total_units_min / exclusiveMinimum
```
Removed value: -0
```
- addedInput schema / properties / total_units_min / minimum
```
Added value: +0
```

Changed1 schema field changedv1.0.2Jul 4, 2026

changedInput schema / required

Previous value: -[
-  "time_of_generation_min",
-  "time_of_generation_max",
-  "api_key_ids"
-]New value: +[
+  "time_of_generation_min",
+  "time_of_generation_max"
+]

Changed1 schema field changedv0.3.7Jun 12, 2026

changedInput schema / properties / api_key_ids / description

Previous value: -"API key UUIDs. Accepts the legacy comma-separated string or a structured array; normalized to the legacy Portkey query param before the request is sent."New value: +"Legacy Portkey query param for API key UUIDs. Comma-separated string; request_analytics also accepts an array and normalizes it to this form."

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 declare readOnlyHint, idempotentHint, and non-destructive behavior, so the description does not need to restate those. It adds meaningful context by disclosing that the endpoint is Enterprise-gated and returns 403 on non-Enterprise plans, which is important operational behavior not present in the annotations.

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?

The description is three sentences with no filler. It front-loads the core purpose and output summary, then provides usage differentiation and gating constraints, all in a compact and scannable format.

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

Completeness4/5

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

Given the 29-parameter schema and existing output schema, the description provides enough context for correct invocation: purpose, sibling distinction, and enterprise access requirement. It could be slightly more complete by mentioning how this relates to other analytics siblings or what time-bucket granularity is expected, but it is largely sufficient.

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?

The input schema covers all parameters with detailed descriptions (100% coverage), so the baseline is 3. The description itself does not add parameter-level guidance, but the schema already does the heavy lifting, including required time range fields and structured alias relationships.

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 explicitly states the tool fetches request-volume time-series data and lists the key fields returned, making the verb, resource, and output scope clear. It also distinguishes itself from get_error_analytics by naming the sibling and the condition that selects it, which is strong differentiation.

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?

The description gives direct guidance on when to use this tool: for traffic and reliability trends. It also explicitly points to get_error_analytics as the alternative when only error counts are needed, giving the agent a clear routing decision.

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

Deploy Server