call_module_api
ChatGPTGET (read-only) module data for ONE customer: trips, geofences, maintenance, drivers, reactions, inspections, etc. Writes (POST/PUT/DELETE) are NOT supported. Module APIs are domain-specific and scoped to a single customer via the X-Platform-CID header; use call_tsp_api for top-level resources (devices, customers, sensors). module='tsp-api' is NOT valid here — call call_tsp_api for TSP-level resources. A module may also be disabled for a given customer (check customer.disabled_modules in the /customers response). LIST ENDPOINTS CAN BE LARGE: the upstream API does not currently accept limit/offset/fields, and this connector passes the response through unchanged. Typical workflow: 1. list_customers → get customer IDs. 2. get_module_openapi(module='trips', path=...) → see available paths and params. 3. call_module_api(customer_id=123, module='trips', path='/trips') → get data. Returns the raw upstream JSON ({code, data}) on success, or {ok: false, error: {code, message, ...}} on failure. The error's code is a stable string the agent can branch on — e.g. unknown_module, invalid_path, token_exchange_failed, upstream_http_error.
call_tsp_api
ChatGPTGET (read-only) TSP-level Wialon Platform data: devices, customers, sensors, sites, channels, auth. Writes (POST/PUT/DELETE) are NOT supported. The request is authenticated with the current user's credentials and scoped to their organization. LIST ENDPOINTS CAN BE LARGE. /customers and /devices return every record with no native pagination or field projection — the upstream API does not currently accept limit/offset/fields, and this connector passes the response through unchanged. Expect tens-of-KB to MB-scale replies for orgs with many devices, and budget context accordingly. To just enumerate or look up customers, prefer list_customers — it returns a much smaller, reshaped summary. Use this raw call only when you need the full customer config. For module data (trips, geofences, maintenance, drivers, reactions, ...) use call_module_api. For exact request/response shapes, call get_module_openapi(module='tsp-api', ...) first. New to this server? See get_started. Returns the raw upstream JSON ({code, data}) on success, or {ok: false, error: {code, message, ...}} on failure. The error's code is a stable string the agent can branch on — e.g. reauth_required, invalid_path, upstream_http_error, upstream_unreachable.
get_module_openapi
ChatGPTGet the exact GET schema for ONE Wialon Platform route (params, response, permissions). Self-contained: every $ref is resolved inline against the full module schema, and x-platform-permissions is preserved. Use when you know module and path and need exact parameters or response fields; if you don't know the path, call search_api first. Only GET operations are returned today. Other HTTP methods (POST/PUT/DELETE) will be selectable via a method parameter in a future version — but since this connector is read-only, only GET schemas are usefully callable here. Use module='tsp-api' for the top-level TSP API (devices, customers, channels, auth, sites, commands, sensors). Returns {ok: true, module, path, operations: {...}} on success, or {ok: false, error: {code, message, ...}} on failure. The error's code is stable — path_not_found puts available_paths (or a sampled list + total_paths) under error.context; no_get_operation puts available_methods there; unknown_module lists valid_modules.
get_started
ChatGPTOrientation for Wialon Platform — call once at the start of a task here. Returns the entity model, the TSP-API vs module-API split, the available tools and when to use each, and recommended workflows. Cheap and read-only; call it when unsure instead of guessing. This is the de-facto manual for the server: short server instructions are not reliably delivered by all clients (notably the Claude app, where tools are deferred until tool_search loads them), so any deep guidance lives here.
list_customers
ChatGPTList the organization's customers (subaccounts) as lightweight summaries. Calls the TSP API GET /customers and returns a trimmed view of each customer — id, name, billing_plan, disabled_modules, devices_count, limit_id, intl, created. The bulky internal blocks (counters, wh, *_custom_fields_schema, detector_settings, emissions_methodology, custom_terms) are dropped — they're rarely useful for "list/find customers" questions and inflate the payload by ~10x. devices_count is the number of devices in the customer (from the upstream counters.devices.count); it is null when counters are unavailable. Prefer this over call_tsp_api(path='/customers') whenever you only need to enumerate customers or look one up. Reach for call_tsp_api only when you genuinely need the full customer config. Returns {ok: true, count: N, customers: [...]} on success, or {ok: false, error: {code, message, ...}} on failure (same envelope as call_tsp_api).
search_api
ChatGPTFind WHICH Wialon Platform endpoint to call for a task (read-only API discovery). Use when you know what you want to do but not which endpoint to call. New to this server? Call get_started first for the entity model and the TSP-vs-module split. Returns a best-match endpoint (module, method, path). Does NOT return parameter schemas — follow up with get_module_openapi for those, then execute via call_tsp_api or call_module_api. Caveats: - Results may include write endpoints (POST/PUT/DELETE) that this read-only connector cannot execute — only GET endpoints can be called. - Some answers arrive as a markdown-fenced JSON string inside answer (``json ... `); strip the fence before parsing. Good queries: "endpoint for unit position history", "which method updates user properties", "how to create a geofence via API". Not for conceptual questions (use search_docs). Returns {ok: true, answer: ...} on success or {ok: false, error: {code, message, ...}} on failure (search_not_configured if the bot isn't set up, search_failed` for upstream errors).
search_docs
ChatGPTExplain HOW a Wialon Platform feature works (conceptual docs, not API calls). Use for "how does X work?" / terminology / configuration questions about trips, geofences, maintenance, reactions, inspections, etc. Not for finding endpoints (use search_api) or exact schemas (use get_module_openapi). Good queries: "how geofence inheritance works", "how token auth is configured", "troubleshooting unit visibility". Returns prose plus doc links. Some links may arrive as relative paths (e.g. /en/wialon-platform/...); prefix with the docs host to navigate. Returns {ok: true, answer: ...} on success or {ok: false, error: {code, message, ...}} on failure (search_not_configured if the bot isn't set up, search_failed for upstream errors).
