Skip to main content
Glama

ThriveCart: List coupons

thrivecart_list_coupons
Read-only

ThriveCart: Coupons with code, discount, status, dates, products and number of uses. Lists the coupons of the Coupons area with code, discount, status, redeemable dates, the products they work on and how many times each was used. Use the coupon_id of each item in update_coupon. Needs the user's Cotlet API key with access to this app.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
searchNoPart of the coupon name or code.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnlyHint=true, destructiveHint=false, openWorldHint=true). The description adds behavior the annotations cannot: it discloses the auth requirement ('Needs the user's Cotlet API key with access to this app') and enumerates returned fields, which matters because no output schema exists.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The opening fragment ('ThriveCart: Coupons with code, discount, status, dates, products and number of uses') is a verbless restatement that the next sentence repeats almost verbatim, so a full sentence is spent twice on the same content. The remaining sentences are tight and front-loaded.

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?

For a one-parameter, read-only list tool with no output schema, the description covers what it returns (fields), what it needs (API key scope), and the natural next step (coupon_id into update_coupon). 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.

Parameters3/5

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

Schema description coverage is 100% for the single 'search' parameter, so the schema already documents it as a partial name/code match. The description adds no further semantics (no matching rules, no pagination/limit behavior), so baseline 3 is appropriate.

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 (lists) and resource (ThriveCart coupons) and enumerates the returned fields, so the agent knows exactly what it gets back. The sibling set (create_coupon, update_coupon, list_products) makes the read-only listing role unambiguous.

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?

Explicitly routes the agent forward: 'Use the coupon_id of each item in update_coupon' tells the agent this is the discovery step before mutation. It stops short of stating when-not to use it or naming other list alternatives, but the usage context is clear.

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