Kilo IoT Platform
Control real-world devices with AI.
От сообщества: Добавлен пользователем или импортирован; проверьте владельца перед подключениемРаботаетБез входаГлобальныйБесплатноМожет изменять данные
Что умеет
- Alarm Definition Create: Create a new alarm definition for the organisation.
- Alarm Definition Delete: Permanently delete an alarm definition by its ID. This action is irreversible. Always confirm with the user before calling this tool.
- Alarm Definition List: List alarm definitions (rules) for the organisation.
Какие данные видит
Нужен ли аккаунт
Не нужен: сервер работает без входа
Control real-world devices with AI. Kilo is an IoT platform for commercial and industrial operations, and this connector hands a live deployment to your AI client.
Ask what's going on — which devices at the north site went quiet overnight, what the alarms looked like around Tuesday's compressor failure, what the cold-store dashboard is showing right now. Then tell it to act: onboard hardware in a batch, build an automation rule and simulate it against the device's real readings before it reaches production, deploy it, work the alarm queue, and send commands to the equipment itself.
Protocol-agnostic by design — whatever your devices speak, the data lands normalized, so the same question works across every vendor in the building. Behind the connector sits the whole platform: IoT device management and digital twins, a rules engine with versioning and rollback, alarms with escalation, dashboards and multi-tenant access control.
You authorize in your browser with your own Kilo account — no API key to mint, nothing stored locally. The connection carries your permissions and nothing more, and every tool is annotated so anything that changes real state asks you first.
Docs: https://docs.kiloiot.io/kilo-iot-server/api/mcp-server · Start free at https://kiloiot.io
Список инструментов сервера (57)
Технические названия из tools/list. Нужны только разработчикам.
| alarm_definition_create | Create a new alarm definition for the organisation. |
| alarm_definition_delete | Permanently delete an alarm definition by its ID. This action is irreversible. Always confirm with the user before calling this tool. |
| alarm_definition_list | List alarm definitions (rules) for the organisation. |
| alarm_definition_update | Update an existing alarm definition. Only provided fields are changed. |
| alarm_get | Get a single alarm event by its ID. |
| alarm_history | List alarm events within a time range (RFC3339 timestamps). |
| alarm_list | List alarm events for the organisation with optional filters (status, severity). |
| alarm_resolve | Resolve an active alarm event, optionally providing a resolution reason. |
| alarm_stats | Get aggregated alarm statistics: total active/resolved counts and breakdown by severity. |
| connection_create | Create a new device connection. A connection binds a connector type (e.g. lorawan) to a configuration (e.g. network settings). Required before provisioning physical devices. |
| connection_delete | Delete a device connection by ID. The connection must belong to the user's organization. |
| connection_list | List device connections for the organization, optionally filtered by connector type |
| connector_configure | Configure a connector connection (placeholder - not yet implemented) |
| connector_list | List all available connector types (lorawan, mqtt_cloud, mqtt_external, etc.) |
| dashboard_create | Create a new dashboard or folder. Folders can contain dashboards. |
| dashboard_list | List all dashboards and folders in the organisation as a tree structure. |
| dashboard_update | Update an existing dashboard or folder. Only provided fields are changed. |
| device_delete | Permanently delete a digital device by ID or name, along with its sensors, sensor mappings and physical-device binding. Irreversible — require explicit user confirmation before calling. Provide either device_id (UUID) or device_name. |
| device_diagnostics | Get composite diagnostics for a device by ID or name: metadata + last-seen timestamps for all sensors. Provide either device_id (UUID) or device_name (human-readable name from device.list results). |
| device_get | Get a single device by ID or name. Provide either device_id (UUID) or device_name (human-readable name from device.list results). |
| device_list | List all digital devices (end-devices / sensors) in the organization. Each device includes its connectionType (lorawan / mqtt / mqtt_cloud / mqtt_external / tracker, empty if unbound). Use connection_type to return only devices of one type, e.g. all LoRaWAN devices. Gateways / LNS gateways / miners are NOT digital devices and are never returned here — the assistant currently has no tool to list or manage gateways (they are managed in the platform web app); never present a device or connection as a gateway. |
| device_profile_create | Create a custom device profile (placeholder - not yet implemented) |
| device_profile_list | Look up a LoRaWAN device profile template by brand, model and frequency band |
| device_provision_lorawan | Create a LoRaWAN device, optionally attaching sensors and sensor mappings. |
| device_provision_mqtt | Create a device that receives INCOMING telemetry over an MQTT-family connection (mqtt_cloud or mqtt_external). This tool only configures the platform to read messages PUBLISHED BY the device — it does NOT publish messages TO the device. The platform does not provide outbound MQTT publish / downlink / actuator-command capability through any tool. If the user asks to control / turn on / turn off / send a command to an MQTT device, refuse per PROTOCOL rule 9, do NOT call this tool as a substitute. The connector variant is inferred from connection_id. |
| device_provision_tracker | Create a GPS tracker device. |
| device_telemetry | Get aggregated OHLC telemetry history for device sensors over a time range |
| device_update | Update an existing device by ID or name. Provide either device_id (UUID) or device_name (human-readable name from device.list results). Set detach_physical_device=true to unbind the physical device (DevEUI / connection / configuration) while keeping the digital device and its sensors. |
| hardware_search | Search for IoT sensor and gateway hardware in the Kilo Electronics catalog. Returns two independently-labelled buckets: `kilo_catalog` (Kilo Electronics catalog, German-language taxonomy) and `web_search` (web fallback). Each bucket carries its own `status` (`ok` / `empty` / `unavailable` / `skipped`) and its own `results` array — they NEVER overlap. PREFERRED CALL SHAPE: pass `categories` (array of German slugs from the catalog) and optionally `intersect=true` to find products tagged with ALL listed categories. Translate the user's intent (in any language) into one or more of these German slugs: Protocols: lorawan, cellular, bluetooth, knx-protokoll, bacnet-protokoll, meshtastic Sensors: distanz (distance/range), bewegung (motion/PIR), bodenfeuchte (soil moisture), leckageerkennung (water/leak detection), luftfeuchtigkeit (humidity), co2-sensoren, co-sensoren (carbon monoxide), kontaktsensoren (door/contact), fuellstand (tank/silo level), durchfluss (flow), gewichtssensoren (weight/load), lichtsensoren (light/lux), beschleunigung (vibration/accel), luftdruck (air pressure), elektrische-leitfaehigkeit (water conductivity) Devices: tracker (GPS), gateways (LoRaWAN gateways), controller, basisplatinen Examples: - User asks 'LoRaWAN water leak sensor' → call with categories=["lorawan","leckageerkennung"], intersect=true - User asks 'distance sensor' → call with categories=["distanz"] - User asks 'датчик движения LoRaWAN' → categories=["lorawan","bewegung"], intersect=true - User asks for a model name not in the slug list → fall back to free-text `query` parameter Rules for the agent: (1) If `kilo_catalog.status == "ok"`, prefer those results, format as `[Name](url)` since they are real catalog entries with permalink. (2) If `kilo_catalog.status == "unavailable"` (network/timeout), explicitly tell the user the catalog is temporarily down — do NOT present `web_search` results as if they were from the catalog. (3) If both buckets are empty/unavailable, recommend only the device class (e.g. 'LoRaWAN temperature sensor'), do NOT fabricate model names. |
| log_export | Export audit log entries as CSV or JSON. (Not yet available — pending audit-service integration) |
| log_query | Query audit log entries for the organisation within an optional time range. (Not yet available — pending audit-service integration) |
| my_permissions | Return the SIGNED-IN user's own role (owner/admin/operator/viewer/billing, or custom for a non-standard permission set), ownership status, and granted permissions in the current organisation. ALWAYS call this to answer any question about the current user's OWN role, permissions, or whether they are the owner (e.g. "what are my rights?", "am I the owner?"). Never claim the user is the owner or has any specific role without calling this tool; never infer the current user's role from team_list, which carries no role field. |
| notification_channel_configure | Enable or disable a user's notification channel (email, SMS, push). |
| notification_recipient_list | List notification channels (email, SMS, push) for a user. |
| notification_test | Send a test notification to verify channel delivery. (Feature not yet implemented) |
| org_get | Get organisation details: name, owner, creation date. |
| org_update | Update the organisation name or transfer ownership to another user. |
| recommend_products | Declare your final product recommendation to the user. Call AFTER one or more hardware_search calls have populated your context with candidates. This tool is your ONLY visible output for a recommendation turn — the UI renders the `summary` text above the resolved product cards as a single block. Do not emit any free-form prose around this call; everything the user should read goes into `summary`. Use this to compose a curated answer: pick a single product for a single need, or a package of several products covering different parts of the user's task (e.g. motion sensor + door contact + leak detector). `highlight_ids` is optional and meant for the rare case when you can OBJECTIVELY justify preferring one product over another comparable one in the same role (price, reliability, fit). Do NOT invent a winner if the options are equally valid — leave highlight_ids empty in that case. |
| rule_delete | Move a rule definition to trash (soft delete). The rule can be restored from trash. |
| rule_example_get | Get a worked Chirp BPMN rule example for an approved AITaxonomy use case ID. Returns the canonical alarm_definition shape (severity, escalation), rule flow steps (CEL expressions), sensor template hints, and design notes. Call BEFORE `rule_provision` when the user's request matches one of the shipped IDs. Currently shipped (curated, not generative): AG-DIST-SILO-001, AG-DIST-TANK-001, AG-DIST-TROUGH-001, PM-DIST-WATER-001, PM-DIST-WATER-003. |
| rule_execution_history | Read the real execution history of a deployed rule to diagnose why it did or didn't fire. Query ADDRESSABLY: filter by sensor_id and a time window (since/until RFC3339) and/or status (SUCCESS|FAILED|SKIPPED_THRESHOLD). Returns recent runs with per-element snapshots (which gateway branch was taken, variable values). Use this to OBSERVE a real run instead of guessing; do not rely on the last run alone on a busy rule. |
| rule_get | Get a single rule definition by ID including its current version info |
| rule_list | List automation rule definitions for the organisation |
| rule_provision | Create a complete rule from a structured JSON flow description. Generates BPMN XML server-side, creates the rule, builds, and deploys in one operation. Use this instead of rule.create + rule.build for AI-driven rule creation. Returns rule_definition_id and version_id on success. |
| rule_simulate | Simulate a deployed rule against a synthetic sensor event. Side effects (alarms, sends, enrichments) are CAPTURED, not fired. Use this after a rule is deployed via rule_provision with two calls: one trigger value (expected to fire the alarm/action) and one non-trigger value (expected to fall through to default end), to behaviourally verify the rule before reporting 'done' to the user. Ground the values in the sensor's REAL data — pick trigger/non-trigger values from the device's actual recent readings and range (see device_telemetry), not arbitrary numbers, so the check reflects the physical device. Synchronous, 5s timeout. |
| rule_stop | Stop a running rule deployment |
| rule_update | Update an existing rule definition metadata. Only provided fields are changed. |
| sensor_add | Add sensors to an existing device by sensor template IDs. Provide either device_id (UUID) or device_name. |
| sensor_map | Replace a device's sensor→payload-field mappings. This MUTATES device configuration. Call it only to (a) set up mappings while provisioning a device the user is creating, or (b) change a mapping the user explicitly asked to change. When changing an already-configured device, confirm with the user first. NEVER call it to silently fix or re-map an existing device as a side-effect of rule creation, diagnostics, or any task the user did not frame as a mapping change. Provide either device_id (UUID) or device_name. |
| sensor_template_create | Create an org-scoped sensor template. Use when sensor.template.list does not return a template for the payload field you need to attach to a device. Requires key_name_id (UUID of an existing normalized key) — discover via sensor.template.list (key_name_id field on each result). Returns the new template UUID; pass it to sensor.add. |
| sensor_template_list | List available sensor templates in the organization. Use this to discover sensor template IDs for adding sensors to devices. |
| team_list | List all members of the organisation with their profile data (name, email) and ownership status. |
| user_get | Get profile information for a user (name, email, phone). |
| user_invite | Invite a user to join the organisation by email. Supply either a predefined role OR granular permissions — not both. When permissions is provided it takes precedence. Valid objects: audit_trail, cameras, connectors, dashboards, devices, gateways, geofencing, logs, manage_users, notification_center, notifications, overview, rules, sim_cards, subscription. Valid actions: read, write. |
| user_role_assign | Assign a predefined role OR granular ABAC permissions to an organisation member, replacing their current permissions. Supply either role or permissions — not both. Valid objects: audit_trail, cameras, connectors, dashboards, devices, gateways, geofencing, logs, manage_users, notification_center, notifications, overview, rules, sim_cards, subscription. Valid actions: read, write. |
| user_update | Update profile fields for a user (first name, last name, phone). |
| widget_data_query | Retrieve widget definitions (type + configuration) for the given widget IDs so the LLM can understand data sources. |