Skip to main content
Glama

AI Agent Analytics

List analytics products

list_products
Read-onlyIdempotent

List active products in the bearer token's organization and return the IDs needed by product-scoped tools. Use this when you need a product_id; do not use it for metrics, use get_portfolio_pulse instead. Takes no parameters because organization scope comes from the token. Requires products:read or products:create; invalid or expired authority fails closed, and the shared MCP limit is 300 calls per 60 seconds per caller before HTTP 429 with Retry-After.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
schemaYesResponse schema identifier.
productsYesActive products visible to this authorization.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed4 schema fields changed
    • addedInput schema / $schema
      Added value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / additionalProperties
      Added value: +false
    • addedInput schema / description
      Added value: +"This tool takes no parameters."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "https://json-schema.org/draft/2020-12/schema",
      +  "additionalProperties": {},
      +  "properties": {
      +    "products": {
      +      "description": "Active products visible to this authorization.",
      +      "items": {
      +        "additionalProperties": {},
      +        "properties": {
      +          "created_at": {
      +            "description": "UTC ISO-8601 product creation timestamp.",
      +            "type": "string"
      +          },
      +          "id": {
      +            "description": "Stable product/property ID to pass as product_id to product-scoped tools.",
      +            "type": "string"
      +          },
      +          "name": {
      +            "description": "Customer-visible product name.",
      +            "type": "string"
      +          },
      +          "status": {
      +            "description": "Current product state.",
      +            "type": "string"
      +          },
      +          "time_zone": {
      +            "description": "IANA time zone used for product-local daily metrics.",
      +            "type": "string"
      +          }
      +        },
      +        "required": [
      +          "id",
      +          "name",
      +          "status",
      +          "time_zone",
      +          "created_at"
      +        ],
      +        "type": "object"
      +      },
      +      "type": "array"
      +    },
      +    "schema": {
      +      "description": "Response schema identifier.",
      +      "type": "string"
      +    }
      +  },
      +  "required": [
      +    "schema",
      +    "products"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A5/5.0
Behavior5/5

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

Annotations already provide safety hints (readOnlyHint=true, idempotentHint=true, destructiveHint=false), and the description adds valuable behavioral context beyond them: auth requirements ('Requires products:read or products:create'), failure behavior ('invalid or expired authority fails closed'), and rate limits ('300 calls per 60 seconds per caller before HTTP 429 with Retry-After'). No contradiction exists.

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?

Every sentence earns its place: purpose, usage guidance, then behavioral constraints. The content is front-loaded with core purpose, with no filler. The third sentence is dense but well-structured, using semicolons to pack auth and rate-limit information efficiently.

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?

The description is complete for a zero-parameter list tool. It states what the tool returns (product IDs), when to use it, auth prerequisites, failure behavior, and rate limits. An output schema exists to document the return shape, so the description needs no further detail. Nothing an agent needs to call it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With zero parametersainer schema only says 'This tool takes no parameters.' The description adds meaning by explaining why: 'Takes no parameters because organization scope comes from the token.' This helps an agent understand the token-driven scope without needing to pass arguments, exceeding the schema's minimal coverage.

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: 'List active products in the bearer token's organization' and clarifies the output's purpose ('return the IDs needed by product-scoped tools'). It also distinguishes itself from a sibling by explicitly saying 'do not use it for metrics, use get_portfolio_pulse instead', so an agent can choose correctly.

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 usage guidance: 'Use this when you need a product_id; do not use it for metrics, use get_portfolio_pulse instead.' This clearly states when to use the tool and names the alternative, leaving no ambiguity about call selection.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources