Skip to main content
Glama
brilliantdirectories

brilliant-directories-mcp

Official
by brilliantdirectories
OverviewSchemaSourceRelated ServersDiscussions(1)Admin
JavaScript
Remote

getUserTransactions

Read-onlyIdempotent

Fetch a member's billing transactions and invoices by user ID or client ID to review payments, unpaid balances, payment methods, and billing status.

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.

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 entry is { invoice_details, subscription_details }. invoice_details 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 is the linked subscription, or false when there is none.

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`.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv6.55.39
  2. Removedv6.55.19
  3. Addedv6.49.4
  4. Removedv6.48.1
  5. Addedv6.0.19
  6. Removedv6.0.18
  7. Addedv6.0.7
  8. Removed
  9. First observedv1.0.0

TDQS

A4.8/5.0
Behavior5/5

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

Beyond the annotations (which already declare readOnly/idempotent/non-destructive), the description adds high-value operational context: the MariaDB zero-date sentinel for unpaid invoices, the admin-facing `notes` field requiring redaction, and the exact response envelope shape. These are non-obvious traits an agent would otherwise get wrong.

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?

Bold headers front-load purpose, parameters, usage, sibling routing, and return shape, and every section earns its place given the missing output schema. It is on the verbose side, but the length is largely justified by the edge-case warnings.

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?

With no output schema and no enums, the description fully carries the burden by specifying the response structure, the invoices array nesting, per-field semantics, and the sentinel/redaction pitfalls. Nothing needed to call or interpret the tool is missing.

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?

Schema coverage is 100%, so the schema already documents both parameters and the baseline is 3. The description adds meaning beyond the schema by explaining the default preference (user_id) and the purpose of client_id as a power-user bypass pointing at users_data.clientid.

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 and resource ('Get member billing transactions (invoices)') and immediately disambiguates the scope as 'for a specific member'. It explicitly names the sibling resources it is not (getUserSubscriptions, getUser), so an agent can tell it apart from adjacent tools.

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?

Provides an explicit 'Use when' section with concrete scenarios (paid/unpaid invoices, reconciliation, 'what did I pay for?') and a 'See also' that names alternatives and how they differ. The parameter-choice rule (default to user_id, reach for client_id only when in hand) is spelled out directly.

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

Deploy Server

Other Tools