Related Servers

Several tool pairs overlap substantially: get_client_services duplicates client-filtered views of list_invoices, list_tickets, list_subscriptions and list_collections; list_auxiliary_data and get_network_element both expose users, branches, warehouses and payment methods; get_ticket (with movement log) overlaps list_tickets_log. Descriptions do distinguish the global-list vs client-scoped intent, so a careful agent can pick correctly, but the boundaries require reading rather than being obvious from names.

Almost every tool follows a clean verb_noun snake_case pattern (list_/get_ + resource), with parallel list/get pairs per domain (list_suppliers/get_supplier, list_tickets/get_ticket). Minor deviations: search_clients is the only tool for listing clients rather than list_clients, get_fttx_trace uses a noun where others use a resource name, and log tools mix list_<resource>_log with list_<resource>s_log forms.

32 tools is heavy, but the surface spans many genuinely distinct ISP domains (clients, internet, TV, phone, subscriptions, invoicing, tickets, suppliers, FTTx, network, reference data), each getting a list/get pair. It is borderline bloated — the FTTx, supplier, and auxiliary-data clusters plus convenience duplicates (get_client_services) push it past what an agent can comfortably hold.

The surface is entirely read-only: no create, update, or delete operations exist for any resource (no create_ticket, update_client, register payment, or invoice issuance), which is a significant gap for an ISP management system. Coverage of the read side is broad and deep, so agents can investigate freely but will hit dead ends the moment a workflow requires a mutation.