Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official

getUserTransactions

Read-onlyIdempotent

Retrieve billing transaction history (invoices) for a specific member using member ID or WHMCS client ID.

Instructions

Get member billing transactions (invoices) - Fetch the billing transaction history (invoices) for a specific member. Read-only. Backed by the WHMCS billing integration.

Required: exactly one of user_id (standard — the BD member ID) OR client_id (power-user — the WHMCS billing record ID stored on the user as users_data.clientid). Default to user_id; reach for client_id only when you already have one in hand and want to bypass the user lookup.

Empty result with misleading error: if the member has no billing record yet (never enrolled in any paid plan), BD returns HTTP 400 + {status:"error", message:"user_id or client_id is required"} even though the identifier WAS sent. The error wording is BD's, not the wrapper's. Treat that exact error message on this endpoint as "no billing data for this member" rather than "missing parameter".

Use when: you need to see a member's paid/unpaid invoices, payment methods, billing history, or reconcile billing status. Common reasons: answering a member's "what did I pay for?" question, exporting billing history, auditing revenue per member.

See also: getUserSubscriptions (active/past membership plan signups - different resource from invoices), getUser (member profile).

Returns: { status: "success", message: { total: <count>, invoices: [{...invoice records}] } }. Each invoice includes id, invoicenum (may be empty string), date, duedate, datepaid, subtotal, credit, tax, total, status (Paid, Unpaid, etc.), paymentmethod, notes (admin-facing; may contain internal comments - redact before surfacing to end users), and an items array with per-line description, amount, type. NOT a simple list of rows - the message is an object containing invoices as the array. Unpaid invoices have datepaid: "0000-00-00 00:00:00" (MariaDB zero-date sentinel) - do NOT parse as ISO-8601; check status === 'Unpaid' or datepaid.startsWith('0000') first. subscription_details may be false (literal boolean) when absent.

Reference support articles:

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
user_idNoMember ID (the standard input). Pass this OR `client_id`.
client_idNoWHMCS billing record ID. Power-user alternative to `user_id`. Pass this OR `user_id`.
Behavior5/5

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

Annotations indicate read-only and idempotent, and the description reinforces 'Read-only' and adds behavioral details: returns 400 with misleading error when no billing record, return format including MariaDB zero-date sentinel, and notes that subscription_details may be false. No contradiction with annotations.

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?

Well-structured with sections, front-loaded summary, and all information relevant. Slightly verbose (e.g., long error handling explanation) but every sentence adds value; could be tightened without losing clarity.

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?

Despite no output schema, the description fully details return structure, edge cases (unpaid invoices, zero-date, subscription_details false), and error handling. Covers all needed context for successful invocation.

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?

Schema coverage is 100% but description adds mutual exclusivity rule, explains the difference between user_id (standard BD ID) and client_id (WHMCS record), and provides guidance on default behavior. This adds significant meaning beyond the schema.

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?

Clearly states 'Get member billing transactions (invoices)' and distinguishes from sibling getUserSubscriptions by specifying invoices vs. subscriptions. The verb 'get' and resource 'transactions/invoices' are explicit.

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?

Explicitly states when to use (e.g., see invoices, billing history) and provides parameter selection guidance (prefer user_id, use client_id only when you have it). Also warns about a misleading error and how to interpret it. 'See also' references relevant siblings.

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/brilliantdirectories/brilliant-directories-mcp'

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