Wialon Platform

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

call_tsp_api

GET (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_module_api

Get 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_module_openapi

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

get_started

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

list_customers

Find 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_api

Explain 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).

search_docs