Skip to main content
Glama

get_error_stacks_analytics

Read-onlyIdempotent

Analyze stacked error-series grouped by HTTP status code over time to reveal which error classes dominate, with summary and per-code series.

Instructions

Get stacked error-series data grouped by HTTP status code over time, with summary and per-code series. Use this to see which error classes dominate; use get_error_status_codes_analytics for distinct-code distribution instead. Enterprise-gated. Returns 403 on non-Enterprise Portkey plans.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
configsNoLegacy Portkey query param for config slugs. Comma-separated string; prefer config_slugs for structured inputs.
span_idNoLegacy Portkey query param for span IDs. Comma-separated string; prefer span_ids for structured inputs.
cost_maxNoMaximum cost in cents to filter by
cost_minNoMinimum cost in cents to filter by
metadataNoLegacy Portkey query param for metadata filtering. Stringified JSON object, e.g. '{"env":"prod","app":"myapp"}'; prefer metadata_filter for structured inputs.
span_idsNoStructured alias for span_id. Use an array of span IDs; normalized to the legacy comma-separated Portkey query param.
trace_idNoLegacy Portkey query param for trace IDs. Comma-separated string; prefer trace_ids for structured inputs.
trace_idsNoStructured alias for trace_id. Use an array of trace IDs; normalized to the legacy comma-separated Portkey query param.
api_key_idsNoLegacy Portkey query param for API key UUIDs. Comma-separated string; request_analytics also accepts an array and normalizes it to this form.
prompt_slugNoFilter by prompt slug
status_codeNoLegacy Portkey query param for HTTP status codes. Comma-separated string; prefer status_codes for structured inputs.
ai_org_modelNoLegacy 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_slugsNoStructured alias for configs. Use an array of config slugs; normalized to the legacy comma-separated Portkey query param.
status_codesNoStructured alias for status_code. Use an array of HTTP status codes; normalized to the legacy comma-separated Portkey query param.
virtual_keysNoLegacy Portkey query param for virtual key slugs. Comma-separated string; prefer virtual_key_slugs for structured inputs.
workspace_slugNoFilter by specific workspace
metadata_filterNoStructured alias for metadata. Use an object such as { env: 'prod' }; normalized to a JSON string before the request is sent.
provider_modelsNoStructured alias for ai_org_model. Use provider__model strings in an array; normalized to the legacy comma-separated Portkey query param.
total_units_maxNoMaximum number of total tokens to filter by
total_units_minNoMinimum number of total tokens to filter by
prompt_token_maxNoMaximum number of prompt tokens
prompt_token_minNoMinimum number of prompt tokens
virtual_key_slugsNoStructured alias for virtual_keys. Use an array of virtual key slugs; normalized to the legacy comma-separated Portkey query param.
completion_token_maxNoMaximum number of completion tokens
completion_token_minNoMinimum number of completion tokens
weighted_feedback_maxNoMaximum weighted feedback score (-10 to 10)
weighted_feedback_minNoMinimum weighted feedback score (-10 to 10)
time_of_generation_maxYesEnd time for the analytics period (ISO8601 format, e.g., '2024-02-01T00:00:00Z')
time_of_generation_minYesStart time for the analytics period (ISO8601 format, e.g., '2024-01-01T00:00:00Z')

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesWhether the tool call succeeded and returned structured data
dataNoStructured success payload when ok is true
errorNoStructured error payload when ok is false

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed16 schema fields changedv0.11.5
    • 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
  2. Changed1 schema field changedv1.0.2
    • 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"
      +]
  3. Addedv1.0.1

TDQS

A4.4/5.0
Behavior4/5

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

Annotations already carry the safety profile (readOnlyHint, idempotentHint, destructiveHint=false, openWorldHint), so the bar is lower. The description adds genuinely new operational context: the response composition (summary plus per-code series over time) and the entitlement behavior ('Enterprise-gated. Returns 403 on non-Enterprise Portkey plans'), which neither annotations nor schema convey. It omits pagination or limit details, but that is minor for a read-only analytics tool with a rich output schema.

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 sentences with zero waste: the operation and output shape, the usage guidance with sibling routing, and the gating caveat. The core action is front-loaded before any caveats.

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?

For a 29-parameter analytics tool, the schema documents every parameter and an output schema exists, so the description need not explain return values. It covers what the tool computes, when to prefer it over the nearest sibling, and its critical failure mode (403 on non-Enterprise plans). Slightly more operational depth, such as data retention or date-range limits, would push it to a 5.

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%, and every parameter — including the two required time bounds with explicit ISO8601 format examples — is already documented in the schema. The description adds no parameter-level meaning 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 opening clause 'Get stacked error-series data grouped by HTTP status code over time, with summary and per-code series' names a specific verb, resource, and output shape. It explicitly distinguishes itself from get_error_status_codes_analytics, so an agent can tell the two analytics tools apart without opening either 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?

'Use this to see which error classes dominate' states the intended use case, and 'use get_error_status_codes_analytics for distinct-code distribution instead' gives an explicit exclusion with a named alternative. The Enterprise-gated and 403 note also tells agents when the call will fail, which is directly relevant to choosing and invoking the tool.

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

Deploy Server

Other Tools