portkey-admin-mcp

get_feedback_analytics

Read-onlyIdempotent

Retrieve feedback-submission time-series data with summary totals and per-bucket counts to view top-level feedback trends over a specified period.

Instructions

Get feedback-submission time-series data with summary totals and per-bucket counts. Use this as the top-level feedback trend view; use get_feedback_models_analytics, get_feedback_scores_analytics, or get_feedback_weighted_analytics for breakdowns. 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

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 destructiveHint=false, so safety is covered. The description adds genuinely non-derivable context: it is Enterprise-gated and returns 403 on non-Enterprise plans, which prevents wasted calls. It stops short of mentioning pagination or rate limits, but the gating disclosure is meaningful added value.

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?

Three tight sentences, each earning its place: what it returns, how it routes against siblings, and the gating constraint. The primary purpose is front-loaded and there is no filler.

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?

With an output schema present and 100% parameter coverage, the description does not need to explain return values or arguments. It covers purpose, routing, and access gating, which is sufficient for a 31-parameter analytics tool, though it omits any note on default bucketing or time-range granularity that a caller might wonder about.

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 31 parameters, including the legacy/structured alias pairs and the required time bounds, are already documented in the schema. The description adds no parameter-level syntax or format detail beyond what the schema provides, so the baseline of 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?

The description states a specific verb and resource ('Get feedback-submission time-series data') plus the exact shape of the return ('summary totals and per-bucket counts'). It explicitly distinguishes itself from the three sibling breakdown tools, so an agent can pick the right one without opening a schema.

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?

It gives an explicit routing rule: 'Use this as the top-level feedback trend view' and names the three alternatives (get_feedback_models_analytics, get_feedback_scores_analytics, get_feedback_weighted_analytics) for breakdowns. Both the when and the when-otherwise are stated.

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

Deploy Server