Skip to main content
Glama

get_customer_logs

List paginated activity logs for a customer to track subscription events and changes.

Instructions

List activity logs for a customer. GET /customers/{customerId}/logs. Returns paginated log entries.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
customerIdYesCustomer ID (required)
pageNoNoPage number (default: 1)
itemPerPageNoItems per page (default: 25)

Implementation Reference

  • The handler function that parses input arguments, destructures customerId/pageNo/itemPerPage, and delegates to customerService.getCustomerLogs(). This is the core execution logic for the get_customer_logs tool.
    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 { customerId, pageNo, itemPerPage } = parsed.data;
      return handleToolCall(() =>
        customerService.getCustomerLogs(client, customerId, { pageNo, itemPerPage })
      );
    }
  • Zod validation schema for the tool's input: customerId (required string), pageNo (optional number), itemPerPage (optional number).
    const schema = z.object({
      customerId: z.string().min(1, "customerId is required"),
      pageNo: z.number().optional(),
      itemPerPage: z.number().optional(),
    });
  • The MCP tool definition/inputSchema used for registration, declaring the tool's name='get_customer_logs', description, and JSON Schema properties with customerId as required.
    const definition = {
      name: "get_customer_logs",
      description:
        "List activity logs for a customer. GET /customers/{customerId}/logs. Returns paginated log entries.",
      inputSchema: {
        type: "object" as const,
        properties: {
          customerId: { type: "string", description: "Customer ID (required)" },
          pageNo: { type: "number", description: "Page number (default: 1)" },
          itemPerPage: { type: "number", description: "Items per page (default: 25)" },
        },
        required: ["customerId"],
      },
    };
  • Import of getCustomerLogsTool into the customer tools registry module.
    import { getCustomerLogsTool } from "./getCustomerLogs.js";
  • getCustomerLogsTool is included in the registerCustomerTools() array, making it available for registration with the main tool registry.
    getCustomerLogsTool,
Behavior3/5

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

No annotations are present, so the description carries full burden. It discloses the GET method (suggesting idempotent read) and pagination, but does not mention required permissions, error handling, or rate limits. Adequate but not thorough.

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 short sentences with no filler. Each sentence adds value: purpose, endpoint, and pagination note. Front-loaded and efficient.

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

Completeness3/5

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

With no output schema, the description does not describe the structure of log entries. While it explains pagination, the absence of response details leaves the agent underinformed about what data to expect.

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?

The input schema has 100% coverage with descriptions for all three parameters. The description adds no additional semantics beyond the schema, meeting the baseline for a tool with full schema 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 clearly states the verb 'List', the resource 'activity logs for a customer', and even includes the HTTP method and path. It is specific and distinct from many sibling tools that focus on invoices or subscriptions.

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

Usage Guidelines3/5

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

The description provides no explicit guidance on when to use this tool versus alternatives like get_subscription_logs or other list tools. The purpose is clear but lacks contextual usage advice.

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