Skip to main content
Glama

list_promo_code_pools

Read-onlyIdempotent

Retrieve promo-code pools to inspect discount and validity settings. Since codes only track usage, pools determine how much a code is worth.

Instructions

List promo-code pools - the campaigns individual codes belong to.

    A pool carries the DISCOUNT and the VALIDITY WINDOW; the codes in it carry only
    their own usage. So "how much is this code worth" is a question about the pool,
    not the code.

    `percent_off` and `price_cents` are alternatives: a pool sets one or the other.
    `starts_at` / `expires_at` bound when codes in it can be redeemed, and
    `expire_content` says whether access granted through the pool expires too - a
    different thing from the code expiring.

    Over 4,000 pools here. Read `total` rather than paging through them.

    Requires `CSA_SKILLJAR_V1_API_KEY`, a separate credential from the v2 client.
    

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pageNo
page_sizeNo
filter_nameNo
filter_offer_idNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
noteYes
pageNo
rowsYes
totalNo
has_moreNo
next_pageNo
Install Server

TDQS

A4.3/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds meaningful behavioral context beyond annotations: the scale warning (over 4,000 pools) and the credential requirement (`CSA_SKILLJAR_V1_API_KEY`, separate from v2 client). These are genuinely useful behavioral traits that annotations do not convey.

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?

The description is tightly written with each paragraph serving a purpose: entity distinction, field semantics, scale guidance, and credential warning. It is slightly longer than strictly necessary but every sentence adds value and the critical scoping information is front-loaded.

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 output schema exists and annotations cover the read-only/idempotent profile, the description is largely complete for a list operation. It covers scale, credential, and domain semantics. The remaining gap is not explaining what the output contains beyond the schema, but with an output schema present that burden is reduced. The filter parameters remain undocumented, which keeps this from a 5.

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

Parameters4/5

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

The input schema has 0% description coverage, so the description must compensate for the four parameters. It does not explain `page`, `page_size`, `filter_name`, or `filter_offer_id` individually, but it does explain core domain fields that inform parameter usage: `percent_off`/`price_cents` alternatives and `starts_at`/`expires_at`/`expire_content` semantics. The description partially compensates but leaves the filter parameters' exact meaning and format undocumented.

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 starts with a specific verb and resource: 'List promo-code pools' and immediately distinguishes the pool from the code entity ('the campaigns individual codes belong to'). It clarifies key domain semantics like discount and validity window living on the pool, which differentiates this tool from the sibling list_promo_codes without needing to open that schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives clear context on when to use this tool: when a question concerns what a code is worth, its discount, or its validity window, the answer is about the pool. It also advises reading `total` instead of paging through 4,000+ pools, which is practical usage guidance. However, it does not explicitly name an alternative tool for code-level queries like list_promo_codes, so the when-not-to-use is implied rather than stated.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/CloudSecurityAlliance/csa-skilljar'

If you have feedback or need assistance with the MCP directory API, please join our Discord server