Skip to main content
Glama
Sign In
Vobiz MCP Server

Vobiz MCP Server

Official
by vobiz-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

List account transactions

list_transactions
Read-only

Retrieve a Vobiz account's billing ledger, newest first, to review call charges, rentals, recharges, and adjustments and get total debit/credit for filtered transactions.

Instructions

List this Vobiz account's billing ledger, newest first: call charges, number rentals, recharges and adjustments, with a summary of total debit and credit over the whole filtered set, not just the page. Use it for 'what did I spend' questions and to find a transaction_id; for the current balance use get_account_balance, and for the reference_type values to filter on use list_transaction_types. All filters combine with AND. Pagination is stateless: pass page and per_page on every call and follow pagination.next_page while has_more is true.

Input Schema

NameRequiredDescriptionDefault
pageNo1-based page number (default 1). Take the next value from pagination.next_page.
typeNocredit (money in), debit (money out), or an exact transaction type as it appears on entries.
statusNoOnly entries in this state: completed (posted), pending, failed or cancelled.
to_dateNoEnd of the period, inclusive, in the same formats as from_date.
currencyNoThree-letter ISO 4217 code such as USD or INR (any case).
per_pageNoEntries per page, max 1000. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20).
from_dateNoStart of the period, inclusive: YYYY-MM-DD (the whole UTC day) or an ISO 8601 timestamp with offset such as 2026-08-28T00:00:00+05:30.
referenceNoCase-insensitive substring of the reference.
descriptionNoCase-insensitive substring of the description.
reference_typeNoSpend source, e.g. cdr or did_rental; the valid values come from list_transaction_types.
transaction_idNoFetch one ledger entry by its UUID (from an earlier listing); other filters still apply.

Output Schema

NameRequiredDescriptionDefault
okNotrue on success; false (with error and message) when the tool failed.
countNoEntries in this page.
summaryNoTotals (debit, credit, net) over every entry matching the filters, or null when Vobiz did not report them.
paginationNoStateless paging block for the next call.
transactionsNoLedger entries as Vobiz returns them: id, type, amount, currency, status, reference_type, description, reference and timestamps.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed10 schema fields changedv1.4.2
    • addedInput schema / properties / currency / description
      Added value: +"Three-letter ISO 4217 code such as USD or INR (any case)."
    • addedInput schema / properties / from_date / description
      Added value: +"Start of the period, inclusive: YYYY-MM-DD (the whole UTC day) or an ISO 8601 timestamp with offset such as 2026-08-28T00:00:00+05:30."
    • addedInput schema / properties / page / description
      Added value: +"1-based page number (default 1). Take the next value from pagination.next_page."
    • changedInput schema / properties / per_page / description
      Previous value: -"Max 1000."New value: +"Entries per page, max 1000. Defaults to the server's VOBIZ_DEFAULT_PAGE_SIZE (20)."
    • changedInput schema / properties / reference_type / description
      Previous value: -"Spend source, e.g. cdr or did_rental."New value: +"Spend source, e.g. cdr or did_rental; the valid values come from list_transaction_types."
    • addedInput schema / properties / status / description
      Added value: +"Only entries in this state: completed (posted), pending, failed or cancelled."
    • addedInput schema / properties / to_date / description
      Added value: +"End of the period, inclusive, in the same formats as from_date."
    • changedInput schema / properties / transaction_id / description
      Previous value: -"Fetch one ledger entry by its ID."New value: +"Fetch one ledger entry by its UUID (from an earlier listing); other filters still apply."
    • changedInput schema / properties / type / description
      Previous value: -"credit, debit, or an exact transaction type."New value: +"credit (money in), debit (money out), or an exact transaction type as it appears on entries."
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "count": {
+      "description": "Entries in this page.",
+      "type": "number"
+    },
+    "ok": {
+      "description": "true on success; false (with error and message) when the tool failed.",
+      "type": "boolean"
+    },
+    "pagination": {
+      "additionalProperties": {},
+      "description": "Stateless paging block for the next call.",
+      "properties": {
+        "has_more": {
+          "description": "true when another page exists.",
+          "type": "boolean"
+        },
+        "next_page": {
+          "description": "Page to request next, or null on the last page.",
+          "type": [
+            "number",
+            "null"
+          ]
+        },
+        "page": {
+          "description": "Page that was returned (1-based).",
+          "type": "number"
+        },
+        "per_page": {
+          "description": "Page size used for this request.",
+          "type": "number"
+        },
+        "returned": {
+          "description": "Number of entries in this page.",
+          "type": "number"
+        },
+        "total": {
+          "description": "Total entries matching the filters, or null when Vobiz did not report it.",
+          "type": [
+            "number",
+            "null"
+          ]
+        }
+      },
+      "type": "object"
+    },
+    "summary": {
+      "description": "Totals (debit, credit, net) over every entry matching the filters, or null when Vobiz did not report them."
+    },
+    "transactions": {
+      "description": "Ledger entries as Vobiz returns them: id, type, amount, currency, status, reference_type, description, reference and timestamps.",
+      "items": {
+        "additionalProperties": {},
+        "propertyNames": {
+          "type": "string"
+        },
+        "type": "object"
+      },
+      "type": "array"
+    }
+  },
+  "type": "object"
+}
  2. First observedv1.1.1

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare readOnlyHint and openWorldHint; the description adds genuinely non-obvious behavior — newest-first ordering, aggregate debit/credit totals computed over the whole filtered set rather than the current page, stateless pagination requiring page/per_page on every call, and the loop condition (follow pagination.next_page while has_more is true). These are the 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?

The scoping statement is front-loaded and no sentence is filler, but five distinct concerns (content, routing, filter logic, pagination, aggregate semantics) are packed into a single dense paragraph. A short break between routing guidance and pagination behavior would make it easier to scan without adding length.

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?

An output schema exists, so return-value documentation is unnecessary, yet the description still surfaces the one return fact that changes agent behavior — totals span the entire filtered set, not the page. With 11 optional parameters and a stateless pagination model, nothing needed to call this correctly 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 description coverage is 100%, so the baseline is 3, but the description adds meaning beyond the schema: type is credit vs debit, reference_type is the 'spend source' whose values come from a sibling tool, and transaction_id fetches a single entry while other filters still apply. It also clarifies that filters are conjunctive rather than substitutive.

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?

Opens with a specific verb+resource+scope ('List this Vobiz account's billing ledger, newest first') and immediately enumerates what the ledger contains (call charges, number rentals, recharges, adjustments). It explicitly separates itself from get_account_balance and list_transaction_types, so an agent can route without opening any schema.

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?

Gives explicit when-to-use ('what did I spend' questions, finding a transaction_id) plus two named alternatives with the exact condition that selects them: get_account_balance for current balance, list_transaction_types for valid reference_type values. Also states that all filters combine with AND, removing a common inference error.

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