Skip to main content
Glama

list_product_rate_plans

Retrieve rate plans assigned to a product by specifying its product ID. Optional parameters allow filtering, sorting, and paginating the results.

Instructions

List product rate plans for a product. GET /products/{productId}/product-rateplans. Product reference: productId (URI: /products/{productId}). Optional: include, orderBy, sortBy, pageNo, itemPerPage.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
productIdYesProduct ID (URI: /products/{productId})
includeNoAttributes to include
orderByNoSort column
sortByNoSort direction
pageNoNoPage number
itemPerPageNoItems per page

Implementation Reference

  • Main handler implementation for the 'list_product_rate_plans' tool. Defines the tool definition (name, description, input schema), a Zod validation schema, and the handler function which parses args, extracts productId, and calls the service layer's listRatePlans function.
    import { z } from "zod";
    import type { Tool } from "../types.js";
    import type { Client } from "./helpers.js";
    import { errorResult, handleToolCall } from "./helpers.js";
    import * as ratePlanService from "../../services/productRatePlanServices.js";
    
    const schema = z.object({
      productId: z.string().min(1, "productId is required"),
      include: z.string().optional(),
      orderBy: z.string().optional(),
      sortBy: z.string().optional(),
      pageNo: z.number().int().min(1).optional(),
      itemPerPage: z.number().int().min(1).optional(),
    });
    
    const definition = {
      name: "list_product_rate_plans",
      description:
        "List product rate plans for a product. GET /products/{productId}/product-rateplans. Product reference: productId (URI: /products/{productId}). Optional: include, orderBy, sortBy, pageNo, itemPerPage.",
      inputSchema: {
        type: "object" as const,
        properties: {
          productId: { type: "string", description: "Product ID (URI: /products/{productId})" },
          include: { type: "string", description: "Attributes to include" },
          orderBy: { type: "string", description: "Sort column" },
          sortBy: { type: "string", description: "Sort direction" },
          pageNo: { type: "number", description: "Page number" },
          itemPerPage: { type: "number", description: "Items per page" },
        },
        required: ["productId"],
      },
    };
    
    async function handler(client: Client, args: Record<string, unknown> | undefined) {
      const parsed = schema.safeParse(args);
      if (!parsed.success) {
        return errorResult(parsed.error.errors.map((e) => e.message).join("; "));
      }
      const { productId, ...params } = parsed.data;
      return handleToolCall(() => ratePlanService.listRatePlans(client, productId, params));
    }
    
    export const listRatePlansTool: Tool = {
      definition,
      handler,
    };
  • Input schema definition for list_product_rate_plans. Uses both a Zod schema (lines 7-14) for runtime validation and an explicit inputSchema object (lines 20-31) for MCP tool definition format. Required parameter: productId. Optional: include, orderBy, sortBy, pageNo, itemPerPage.
    const definition = {
      name: "list_product_rate_plans",
      description:
        "List product rate plans for a product. GET /products/{productId}/product-rateplans. Product reference: productId (URI: /products/{productId}). Optional: include, orderBy, sortBy, pageNo, itemPerPage.",
      inputSchema: {
        type: "object" as const,
        properties: {
          productId: { type: "string", description: "Product ID (URI: /products/{productId})" },
          include: { type: "string", description: "Attributes to include" },
          orderBy: { type: "string", description: "Sort column" },
          sortBy: { type: "string", description: "Sort direction" },
          pageNo: { type: "number", description: "Page number" },
          itemPerPage: { type: "number", description: "Items per page" },
        },
        required: ["productId"],
      },
    };
  • Export of the Tool object containing definition and handler. This gets collected via src/tools/product_rate_plans/index.ts (line 9) and registered into the central tool array in src/tools/index.ts (line 29).
    export const listRatePlansTool: Tool = {
      definition,
      handler,
    };
  • Service-layer listRatePlans function. Builds a URL with query parameters (include, orderBy, sortBy, pageNo, itemPerPage, query, status) and makes a GET request to /products/{productId}/product-rateplans. This is the actual API call implementation.
    export async function listRatePlans(
      client: Client,
      productId: string,
      params?: ListRatePlansParams
    ): Promise<PaginatedResponse<unknown>> {
      const search = new URLSearchParams();
      if (params?.include) search.append("include", params.include);
      if (params?.orderBy) search.append("orderBy", params.orderBy ?? "");
      if (params?.sort) search.append("sort", params.sort);
      if (params?.sortBy) search.append("sortBy", params.sortBy ?? "");
      if (params?.pageNo != null) search.append("pageNo", String(params.pageNo));
      if (params?.itemPerPage != null) search.append("itemPerPage", String(params.itemPerPage));
      if (params?.query) search.append("query", params.query);
      if (params?.status) search.append("status", params.status);
      const q = search.toString();
      return client.get<PaginatedResponse<unknown>>(
        `/products/${productId}/product-rateplans${q ? `?${q}` : ""}`
      );
    }
Behavior3/5

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

The description implicitly indicates a read operation via the GET method, but without annotations, it carries the burden. It does not disclose additional behavioral traits like pagination behavior or response structure beyond listing parameters.

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 description is short but includes redundant information (product reference repeated). It front-loads the purpose but could be more concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the lack of output schema and annotations, the description does not explain the return format, pagination behavior, or potential errors. It is minimally viable but leaves gaps for an AI agent.

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 coverage is 100%, and description repeats the optional parameters but does not add new meaning (e.g., valid values for include, default pagination). Baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the tool lists product rate plans for a product, specifying the HTTP method and URI. However, it does not differentiate from sibling list tools like list_product_rate_plan_charges or list_products.

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

Usage Guidelines2/5

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

No guidance on when to use this tool vs alternatives (e.g., get_product_rate_plan for a single plan, or list_subscription_rate_plans). The description only lists optional parameters without context.

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

Install Server

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/rhinosaas/rebillia-mcp-server'

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