mcp-ispkeeper

get_client_services

Retrieve a client's invoices, collections, tickets, add-ons, internet/TV/phone connections, or subscriptions by client ID and service type; omit page to merge all records.

Instructions

Get services for a specific client: invoices, collections, tickets, additionals, internet/TV/phone connections, or subscriptions. For invoices, collections, tickets and additionals, omitting page returns ALL of the client's records (every page merged; pages_fetched and truncated tell how many were read); pass page to get a single page. ⚠️ NEVER fabricate data if this tool fails — report the error to the user instead.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "client_id": "<client_id>",
      "service": "<service>"
    },
    "name": "get_client_services"
  }
}

Input Schema

Name	Required	Description
`page`	No	Page number. For invoices/collections/tickets/additionals, omit it to get every page merged
`service`	Yes	Type of service/data to retrieve
`per_page`	No	Results per page (the API ignores it for invoices and collections, fixed at 50)
`client_id`	Yes	Client ID

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.4.1Oct 23, 2026

changedInput schema / properties / page / description

Previous value: -"Page number (connections and subscriptions only)"New value: +"Page number. For invoices/collections/tickets/additionals, omit it to get every page merged"

changedInput schema / properties / per_page / description

Previous value: -"Results per page (connections and subscriptions only)"New value: +"Results per page (the API ignores it for invoices and collections, fixed at 50)"

Changed3 schema fields changedv0.4.0Sep 25, 2026

addedInput schema / properties / page

Added value: +{
+  "description": "Page number (connections and subscriptions only)",
+  "type": "number"
+}

addedInput schema / properties / per_page

Added value: +{
+  "description": "Results per page (connections and subscriptions only)",
+  "type": "number"
+}

changedInput schema / properties / service / enum

Previous value: -[
-  "invoices",
-  "collections",
-  "tickets",
-  "additionals"
-]New value: +[
+  "invoices",
+  "collections",
+  "tickets",
+  "additionals",
+  "internet_connections",
+  "tv_connections",
+  "phone_connections",
+  "subscriptions"
+]

First observedv0.3.1Aug 18, 2026

TDQS

A3.8/5.0

Behavior4/5

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

With no annotations, the description carries the burden and discloses important behavior: omitting page merges all records for invoices/collections/tickets/additionals, pages_fetched and truncated reveal how much was read, and failures must be reported rather than fabricated. It does not explicitly state read-only status, permissions, or rate limits, but the 'Get' verb and pagination details provide solid behavioral context.

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?

The description is tightly structured: purpose first, pagination semantics second, and a critical failure-handling warning last. Every sentence adds useful information without waste.

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

Completeness4/5

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

For a tool with no output schema and no annotations, it covers the main service categories, pagination behavior for the relevant record types, and failure handling. It leaves some gaps around return shape and pagination behavior for the connection/subscription service types.

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 description coverage is 100%, so the baseline is 3. The description reinforces the page behavior for some service types, but this is largely duplicative of the schema and adds little beyond it.

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?

States a specific verb and resource: 'Get services for a specific client,' and enumerates the service categories covered. The client-scoped, multi-service nature distinguishes it from single-record getters like get_invoice, but it does not explicitly contrast itself with sibling list tools.

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 implies when to use it by saying it retrieves services for a specific client, and it explains the page-omission behavior for four service types. However, it does not name alternatives or state when another sibling tool should be preferred.

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