portkey-admin-mcp

get_latency_analytics

Read-onlyIdempotent

Retrieve latency time-series with avg and p50/p90/p99 percentiles to spot slowdowns and regressions across buckets. Enterprise plans only.

Instructions

Get latency time-series data with summary.avg_latency_ms, summary.p50_latency_ms, summary.p90_latency_ms, summary.p99_latency_ms, and per-bucket latency percentiles in ms. Use this to spot slowdowns and regressions; use get_cache_hit_latency when you only want cache-hit latency. 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.
`deployment_id`	No	Comma-separated list of deployment IDs (UUIDs) to filter by. Prefer deployment_ids for structured inputs.
`deployment_ids`	No	Structured alias for deployment_id. Use an array of deployment UUIDs; normalized to the comma-separated Portkey query param.
`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.

Changed2 schema fields changedv0.13.0Oct 3, 2026

addedInput schema / properties / deployment_id

Added value: +{
+  "description": "Comma-separated list of deployment IDs (UUIDs) to filter by. Prefer deployment_ids for structured inputs.",
+  "type": "string"
+}

addedInput schema / properties / deployment_ids

Added value: +{
+  "description": "Structured alias for deployment_id. Use an array of deployment UUIDs; normalized to the comma-separated Portkey query param.",
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}

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"
+]

Addedv1.0.1May 7, 2026
RemovedMay 1, 2026
First observedJan 1, 2026

TDQS

A4.3/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, openWorld). The description adds genuinely new behavioral context the annotations do not: it is Enterprise-gated and returns 403 on non-Enterprise plans, which tells the agent to expect an authorization failure rather than an empty result. It stops short of describing pagination or bucket granularity, so it is not 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?

Front-loaded with the resource and its return shape, then usage routing, then the gating caveat. The metric enumeration is slightly list-heavy but every clause carries information; no filler sentences.

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?

An output schema exists, so return values need not be re-explained, yet the gating and 403 behavior are critical for correct invocation and are present. For a read-only analytics tool with full schema coverage and annotations, the definition is complete enough; only minor gaps (granularity of buckets) remain.

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 the 31 parameters (legacy vs structured aliases, token/cost/feedback ranges, time window) are fully documented in the schema itself. The description adds no parameter-level meaning, so the baseline 3 applies.

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 ('Get latency time-series data') and enumerates the exact metrics returned (avg/p50/p90/p99 latency_ms plus per-bucket percentiles). It explicitly distinguishes itself from the sibling get_cache_hit_latency, so an agent can route without opening schemas.

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?

Gives explicit when-to-use ('spot slowdowns and regressions') and names the alternative with its selecting condition ('use get_cache_hit_latency when you only want cache-hit latency'). Nothing is left to inference.

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

Deploy Server