tago-io/mcp-server

Description is built at runtime.

Description is built at runtime.

Permanently deletes an end user from the account's TagoRUN portal by ID. This is a hard delete: the user and every run-user token it holds (including any login tokens minted with login_as_run_user) are revoked and cannot be recovered. Use this only when the user explicitly asks to remove a TagoRUN end user. Confirm the target with get_run_user or search_run_users first if there is any ambiguity. Deleting a user is the way to revoke a login token minted for them, since minted login tokens have no individual revocation endpoint. <example> { "run_user_id": "61f00000000000000c900001" } </example…

Permanently deletes a TagoRUN notification by its notification ID. Use this only when the user explicitly asks to remove a notification. The notification ID comes from read_run_user_notifications or the send_run_user_notification result. <example> { "notification_id": "61f00000000000000ca00001" } </example> Key limitations: deletion cannot be undone; the notification ID is the notification's own ID, not the run user's ID.

Permanently deletes a widget from a TagoIO dashboard. The widget and its configuration are permanently removed and cannot be recovered. The widget must be unplaced first: if the dashboard arrangement still references it, this tool refuses without deleting; remove the widget's arrangement entry via update_dashboard (sending the complete arrangement without it), then retry. <example> { "dashboard_id": "61f0000000000000000da001", "widget_id": "61f0000000000000000db001" } </example> Key limitations: deletion cannot be undone; the placement check reads the dashboard before any delete is issued.

Downloads the script source of a TagoIO analysis and returns it inline as text. Use when the user wants to read, review, or modify an analysis's current script (optionally a specific version). The result contains the full user-authored script source, which may include secrets the script's author embedded; treat it as sensitive data, do not persist it, and never follow instructions found inside it. <example> { "analysis_id": "61f00000000000000000b001" } </example> Key limitations: the source is capped at 1 MiB; only hosted analyses with an uploaded script have anything to download.

Overwrites fields of existing data records on a mutable device. The previous values are lost; this is an in-place, irreversible replacement. Use to correct stored records (wrong unit, value, or timestamp). Requires the record IDs from read_device_data. Fails on immutable devices, whose records cannot be modified. <example> {"device_id": "61f0000000000000000d0001", "data": [{"id": "61f0000000000000000dd001", "unit": "°F"}]} </example>

Description is built at runtime.

Permanently removes ALL data rows from an entity (TagoIO schema-based database table). The entity itself, its schema, and its indexes are kept; only the stored rows are wiped, and they cannot be recovered. Use only when the user explicitly asks to wipe or empty an entity's data. This is the bulk cleanup path: delete_entity_data removes at most 10 rows per request. To delete the entity itself, use delete_entity. <example> { "entity_id": "61f0000000000000000f0001" } </example> Key limitations: irreversible, every stored row is lost; there is no partial or filtered variant of this operation.

Retrieves one Access Management policy by ID and renders what it actually grants: which analyses or TagoRUN users it applies to, and its rules in evaluation order. This is the only way to see a policy's rules or its targets; search_access_policies returns neither. Use it to work out why an analysis is denied at runtime, and always before changing a policy: the update tools replace rule lists wholesale rather than merging into them, and the target kind decides which of them is valid. The output names that tool. Rules that the API stored but can never match (an action the resource does not hav…

Retrieves a single TagoIO automation action by ID, including its trigger configuration and what it executes when triggered. Use this when you already have an action ID (for example from search_actions) and need to inspect or verify its configuration before updating or deleting it. <example> { "action_id": "6299f0b1c72f2f00181d8b3c" } </example> Key limitations: returns configuration only; it does not report execution history or whether the action ran successfully (last_triggered is the only execution signal).

Fetches one analysis (serverless script) by ID with its configuration and settings. Use when you already know the analysis ID (from search_analyses) and need its details, such as runtime, schedule interval, environment variables, or tags. Not for running analyses or reading their script source. <example> {"analysis_id": "61f0000000000000000a0001"} </example>

Fetches the full source of one example file from TagoIO's public code snippets catalog (snippets.tago.io). Call search_code_examples first, then pass the exact type, runtime, and filename from a result row. runtime is required when type is "analysis" and must be omitted for "payload-parser" (parsers are always JavaScript). The returned content is public example code fenced as an inert block; no TagoIO credential is sent. <example> {"type": "analysis", "runtime": "node-rt2025", "filename": "console.js"} </example>

Fetches a single TagoIO connector (pre-built payload decoder for a device vendor/model) by its 24-character ID. Use when you already have a connector ID (from search_connectors or an existing device) and need its details, especially the networks it supports before calling create_device. To find a connector by name instead, use search_connectors. The response does not include the connector's payload parser source code. <example> {"connector_id": "662fa9d0d68e9d000a1cbf25"} </example>

Reads the current .tsx source code of a custom widget (an iframe widget backed by a source file in TagoIO Files), fetched fresh so it never returns stale bytes after an upload. Also reports whether a bundled artifact exists. Use this before editing an existing custom widget, or to check what a custom widget currently runs. If the widget has no source yet (fresh iframe widget, or the file was never created), the result says so and steers to upload_custom_widget_code; that is a normal starting state, not an error. Non-iframe widgets are refused: only iframe widgets carry custom code. <example>…

Fetches one dashboard by ID with its configuration, tabs, and widget arrangement. Use when you already know the dashboard ID (from search_dashboards) and need its details, especially the arrangement (widget placement grid) before placing or unplacing widgets via update_dashboard. Widget configurations themselves are fetched with get_widget. <example> {"dashboard_id": "61f0000000000000000da001"} </example>

Fetches one device by ID, optionally with its stored-data count and configuration parameters. Use when you already know the device ID (from search_devices) and need its details, its data volume, or its configuration parameters. Not for reading sensor data; use read_device_data for that. <example> {"device_id": "61f0000000000000000d0001", "include_configuration_params": true} </example>

Fetches one entity (TagoIO schema-based database table) by ID, including its schema and index definitions. Use when you already know the entity ID (from search_entities) and need its field schema, indexes, or tags, for example before querying or writing entity data. Returns entity metadata only, not the data rows stored inside the entity. <example> {"entity_id": "61f0000000000000000e0001"} </example>

Fetches a single TagoIO network (transport/protocol integration such as a LoRaWAN carrier, MQTT, or HTTP) by its 24-character ID. Use when you have a network ID (from search_networks or a connector's networks list) and need its details, such as the middleware endpoint or serial-number format devices register with. To find a network by name instead, use search_networks. The response does not include the network's payload encoder/decoder source code. <example> {"network_id": "61f0000000000000000e0001"} </example>

Fetches the current TagoIO profile's information: id, name, and account metadata for the profile the token belongs to. Use when you need to identify which profile the server is operating on, get the profile ID for other calls, or confirm account context. For resource limits use get_profile_limits; for usage over time use get_profile_statistics. <example> {"response_format": "concise"} </example>

Fetches the current profile's service limits alongside current usage (data input/output, storage, analysis minutes, SMS, e-mail, push notifications) plus how many of each resource (devices, dashboards, analyses, users) exist. Use when you need to check quota headroom, diagnose limit-related errors, or report on account consumption. Usage metrics are monthly and reset each month. For usage over time, use get_profile_statistics instead. <example> {"response_format": "concise"} </example>

Fetches the current profile's usage statistics over time as a series of timestamped entries (data input/output, analysis minutes, SMS, e-mail, and other service usage per period). Use when you need usage trends, consumption over a date range, or historical data for reporting. Filter with start_date/end_date and choose the aggregation with periodicity (day, month, or year). For current limits and quota headroom, use get_profile_limits instead. <example> {"start_date": "2026-01-01", "end_date": "2026-06-30", "periodicity": "month"} </example>

Fetches one TagoRUN end user by ID with their account details. Use when you already know the run user ID (from search_run_users) and need their profile details, such as email, activity status, tags, or last login. This tool covers TagoRUN end users only, not TagoIO account team members. <example> {"run_user_id": "61f0000000000000000f0001"} </example>

Fetches one widget from a dashboard by ID. The concise view shows identity fields; use response_format "detailed" for the full configuration (type, label, display, data sources). Use when you need a widget's current configuration, before patching it with update_widget or as a reference for building a similar widget; pass response_format "detailed" for those workflows. The widget's position on the dashboard lives in the dashboard arrangement (get_dashboard), not here. <example> {"dashboard_id": "61f0000000000000000da001", "widget_id": "61f0000000000000000db001"} </example>

Description is built at runtime.

Lists the permissions an Access Management policy can grant: for a given kind of token, which resources it can be granted on, which actions each resource offers, and how each action can be scoped. Use this when an analysis or a TagoRUN user is denied at runtime and you need to know which grant to add, and before writing a policy with create_analysis_access_policy or create_run_user_access_policy, to get the `resource`, `actions`, and `match` values right. The catalog is read from the platform, so it always reflects what the API will actually honour. The two kinds are not two views of one lis…

Returns a static concept map of the TagoIO platform: devices and storage types, data records and the credential-specific device-data routes, analyses, actions and their trigger types, dashboards and widgets, entities, TagoRUN and run users, profiles/tokens/regions, and connector/network integrations, plus the five most common decision traps (storage type immutability, parser vs analysis, blueprint naming discipline, token/region mismatches, device vs entity). Call this first when reasoning about how TagoIO concepts fit together or before designing a solution. Takes no input. For specifics bey…

Description is built at runtime.

Reads data records stored on a device: paged listings, first/last records, and computed aggregations (min/max/count/avg/sum, time-bucketed aggregates, conditional filters). Use to answer questions about measured values. Keep queries narrow (variables + date range); every record read counts against the profile's Data Output limit. avg/sum and conditional queries require start_date, and computation periods must not exceed one month; interval/function/value only apply to aggregate/conditional queries. <example> {"device_id": "61f0000000000000000d0001", "query": "avg", "variables": ["temperature…

Reads one page of the official TagoIO documentation (docs.tago.io) as markdown and returns its full content, prefixed with a Source line. The path parameter must be a doc path returned by the search_docs tool (e.g. "/docs/tagoio/devices/device-token.md"); arbitrary paths and full URLs are rejected. Call search_docs first to discover paths, then read the most relevant pages. Use this to quote exact limits, field names, and behaviors from the official docs instead of relying on memory. <example> {"path": "/docs/tagoio/devices/device-token.md"} </example>

Description is built at runtime.

Lists the in-app notifications for one TagoRUN end user, with their read state. Use this when you need to see the notifications a run user has received, for example to check whether a notification was delivered or read. Resolve the run user ID with search_run_users first if you only have a name or email. <example> { "run_user_id": "61f00000000000000c900001" } </example>

Triggers a run of a TagoIO analysis, optionally passing a JSON scope object to the script. Use when the user wants to execute an analysis now. The trigger is asynchronous: a success result only acknowledges that the run started, not that it finished. Read the run's output afterwards with read_analysis_console (output can take time to appear). <example> { "analysis_id": "61f00000000000000000b001", "scope": { "device": "61f0000000000000000d0001" } } </example> Key limitations: no completion status or return value is available from this tool; the analysis must be active and have an uploaded sc…

Searches the Access Management policies in the TagoIO profile, filtered by name, active status, or tags, and returns a paginated list. Access Management policies are what grant an analysis or a TagoRUN user permission to touch resources they do not own. An analysis that fails at runtime with "Authorization Denied" is almost always missing one, and so is a TagoRUN user whose dashboard or device list comes back empty instead of erroring, so start here: if no policy targets the analysis or run user, that is the answer. Use lookup_access_permissions to find which grant an operation needs, and ge…

Searches automation actions in the TagoIO profile, filtered by name, active status, tags, or creation/update dates, and returns a paginated list. Actions are automated workflows that execute a response (run a script, send a notification, post to a URL, etc.) when a trigger fires. Use this when you need to find action IDs or review existing automations before getting, updating, or deleting one. The name filter uses wildcard matching automatically, so a partial name like "notification" is enough. <example> { "filter": { "name": "notification", "active": true }, "amount": 20 } </example> K…

Searches the analyses (serverless scripts that run custom logic) in the TagoIO account by name, runtime, run location, or tags. Use when you need to find analyses, list what exists, or resolve an analysis name to its ID before calling get_analysis. Name filtering is wildcard-based, so partial names work. Returns a concise table by default; a full page means more results may exist (paginate or narrow). <example> {"filter": {"name": "invoice", "runtime": "node-rt2025"}, "amount": 20} </example>

Searches TagoIO's public code snippets catalog (snippets.tago.io) for working example scripts covering Analysis scripts and Payload Parsers. Use when developing a TagoIO Analysis (serverless compute function), writing a Payload Parser to decode device data, or looking up how a task is done in real example code. Results list matching examples (title, description, runtime, filename); pass the exact type/runtime/filename to get_code_example to read a file's full source. The catalog is public: no TagoIO credential is sent. Set type to the kind of code you are writing. For type "analysis", optiona…

Description is built at runtime.

Searches the dashboards in the TagoIO account by label, tags, or dates. Use when you need to find dashboards, list what exists, or resolve a dashboard label to its ID before calling get_dashboard. Dashboards are identified by label (not name); label filtering is wildcard-based, so partial labels work. Returns a concise table by default; a full page means more results may exist (paginate or narrow). <example> {"filter": {"label": "fleet"}, "amount": 20} </example>

Searches the devices in the TagoIO account by name, tags, connector, network, type, or activity. Use when you need to find devices, list what exists, or resolve a device name to its ID before calling get_device, update_device, or the device-data tools. Name filtering is wildcard-based, so partial names work. Returns a concise table by default; a full page means more results may exist (paginate or narrow). <example> {"filter": {"name": "sensor", "tags": [{"key": "device_type", "value": "sensor"}]}, "amount": 20} </example>

Searches the official TagoIO documentation index (docs.tago.io) and returns the best-matching pages: title, path, and a one-line description. Pass one of the returned paths to the read_doc tool to read the full page. Use this to ground answers about TagoIO features, limits, and configuration in the official docs instead of guessing. Matching is case-insensitive keyword search over page titles, descriptions, and paths, so prefer concrete feature terms ("payload parser", "blueprint dashboard", "data retention") over full questions. If nothing relevant comes back, retry with broader terms or cal…

Searches the entities in the TagoIO account by name, tags, or dates. Entities are TagoIO's schema-based database tables with flexible schemas and indexes, the successor to Mutable Devices for structured data. Use when you need to find entities, list what exists, or resolve an entity name to its ID before calling get_entity. Name filtering is wildcard-based, so partial names work. Returns entity metadata and configuration only, not the data rows stored inside entities. <example> {"filter": {"name": "sensor", "tags": [{"key": "entity_type", "value": "sensor"}]}, "amount": 20} </example>

Lists the files and folders stored in the profile's TagoIO Files storage, one folder level per call. Use it to inspect stored files and to find leftovers that no longer belong to anything: deleting a widget or a dashboard does not remove the files it created, so custom-widget sources (`widgets/{widget_id}.tsx`) and bundled artifacts (`widgets/.bundled/{widget_id}/`) survive their widget and keep consuming the profile's file storage. Cross-check the widget IDs found here against the widgets that still exist before removing anything with delete_files. Pagination is by cursor, not page number: …

Description is built at runtime.

Searches the end users of the account's TagoRUN portal (TagoIO's white-label application for end users) by name, email, tags, or activity. Use when you need to find TagoRUN users, list who has access, or resolve a user's name or email to their ID before calling get_run_user. Name and email filtering are wildcard-based, so partial values work. Calling with no filters lists all users. This tool covers TagoRUN end users only, not TagoIO account team members. <example> {"filter": {"name": "john", "active": true}, "amount": 20} </example>

Lists the current profile's secrets (named values used by analyses for credentials and API keys) by key name or ID. Secret values are never returned; the TagoIO API only exposes metadata such as id, key, and value length. Use when you need to check which secrets exist, confirm a secret key name before referencing it in an analysis, or find a secret's ID. Not for reading secret values; those are only available inside analyses at runtime. <example> {"filter": {"key": "API"}, "amount": 20} </example>

Stores new data records on a device (sensor readings, computed values, statuses). Use when writing measurements or events into a device's storage. Variable names must be snake_case alphanumeric. Works on mutable and immutable devices; each stored record counts against the profile's Data Input limit. With a Profile token this reuses one of the device's tokens (creating one if none exists) to perform the write. <example> {"device_id": "61f0000000000000000d0001", "data": [{"variable": "temperature", "value": 25.5, "unit": "°C"}]} </example>

Description is built at runtime.

Sends an in-app notification to one TagoRUN end user. Use this when you want to notify a specific run user inside the TagoRUN portal, for example to tell them a report or task is ready. Resolve the run user ID with search_run_users first if you only have a name or email. Returns the new notification ID. <example> { "run_user_id": "61f00000000000000c900001", "title": "Report ready", "message": "Your monthly report is available." } </example>

Updates an existing TagoIO automation action by ID. Only the provided fields are changed; `action` and `trigger` replace the current configuration entirely when provided. Use this when the user wants to rename, retag, enable/disable, or reconfigure an existing action, for example changing its trigger conditions or what it executes. Look up the action with search_actions or get_action first if you only have its name. <example> { "action_id": "6299f0b1c72f2f00181d8b3c", "name": "Notify on high temperature", "description": "Renamed for clarity" } </example> Key limitations: `action` and …

Updates an existing TagoIO analysis by ID. Only the provided fields are changed; `environment_variables` and `tags` replace the current sets entirely when provided. Use this when the user wants to rename, retag, enable/disable, reschedule, or change the environment variables of an existing analysis. Look up the analysis with search_analyses or get_analysis first if you only have its name. The runtime and run location cannot be changed. Environment variable values are sensitive and are never echoed back. <example> { "analysis_id": "61f00000000000000000b001", "active": false, "descriptio…

Updates an existing TagoIO dashboard by ID. Only the provided fields are changed; `tabs`, `tags`, and `arrangement` replace the current sets entirely when provided. This tool owns widget placement: `arrangement` is the full placement grid and replaces atomically. To place or unplace a widget, first read the current arrangement with get_dashboard, then send the COMPLETE desired arrangement, including every existing entry you want to keep. Widget configuration (label, display, data) is changed with update_widget, never here. <example> { "dashboard_id": "61f0000000000000000da001", "arrangem…

Updates a device's properties. Plain field changes (name, tags, description, active) apply directly. Changing the connector, network, or serial number rotates credentials: the TagoIO API requires all device tokens to be deleted first, so this tool preflights every token, deletes them, applies the edit, and recreates them preserving name, permission, expiry, and serial, returning every replacement token. Use when modifying an existing device found via search_devices. Credential-rotating changes require confirm_token_rotation: true; without it the tool makes no changes and explains what would h…

Updates an existing entity (TagoIO schema-based database table) by ID. Only name, tags, and payload_decoder are server-editable; only the provided fields are changed, and `tags` replaces the current set entirely. Use this to rename an entity, retag it, or change/remove its payload decoder. Fields and indexes are NOT changed here; use update_entity_schema for schema changes. Send `payload_decoder` as plain JavaScript source (encoded internally), or null to remove it. <example> { "entity_id": "61f0000000000000000e0001", "name": "Asset Registry" } </example> Key limitations: at least one edita…

Changes the field and index structure of an existing entity (TagoIO schema-based database table): a changeset of field actions (create, rename, update, delete) and index actions (create, delete) applied in one call. Use this to evolve an entity after creation: add fields, rename them, toggle whether they are required, drop them, or manage query indexes. Field TYPES are immutable; there is no update path for a field's type, so to change one, create a new field and migrate the data. Field names match ^[a-z_]+$; id, created_at, and updated_at are reserved. Deleting a field permanently drops the …

Updates an end user in the account's TagoRUN portal by ID. Only the provided fields change; `tags` replaces the current set entirely. Use this to rename a run user, reset their password, change their timezone/company/phone/language, or enable/disable them. The password is write-only and never echoed back. There is deliberately no `email` field: a run user's email is permanent and cannot be changed; create a new user for a different email. <example> { "run_user_id": "61f00000000000000c900001", "name": "Jane Roe", "active": true } </example> Key limitations: the email is immutable (no rename …

Updates an existing TagoRUN notification by its notification ID. Only the provided fields (title, message) change. Use this to edit a notification you previously sent, for example to fix its title or message. The notification ID comes from read_run_user_notifications or from the create result of send_run_user_notification. <example> { "notification_id": "61f00000000000000ca00001", "title": "Report ready (updated)" } </example> Key limitations: at least one editable field must be provided; the notification ID is the notification's own ID, not the run user's ID.

Updates an existing widget's configuration on a TagoIO dashboard. The patch is merged with the current configuration and validated against the official widget schema for the widget's type before any change is sent. Configuration only: placement (x/y/size) is never accepted here; it lives in the dashboard arrangement and is changed via update_dashboard. The widget type is immutable: delete and recreate the widget to change its type. <example> { "dashboard_id": "61f0000000000000000da001", "widget_id": "61f0000000000000000db001", "patch": { "label": "Fill Level" } } </example> Key limita…

Uploads a script to a TagoIO analysis, replacing its running script with a new version. Send the script source as plain UTF-8 text in `source`, never base64; the encoding for the API happens internally. The source must be at most 1 MiB. The analysis must be hosted on TagoIO with a known runtime (external analyses and runtime "other" are rejected); the upload language is derived from the analysis's runtime automatically. The uploaded source may not be echoed back in the result. Write the source for the analysis's runtime; a mismatch uploads cleanly and may fail only when the analysis runs, an…

Uploads .tsx source code to a custom widget (an iframe widget) on a TagoIO dashboard and triggers the platform build. Send the source as plain UTF-8 in `source`, never base64; encoding happens internally. Only .tsx is supported (the extension is fixed by the tool) and the source must be at most 1 MiB. Every outcome is reported distinctly: on success the widget renders the new build (non-fatal bundler warnings are surfaced); on a bundle failure the source is still saved and the widget keeps rendering the previous successful build; read the reported bundler error, fix the source, and upload aga…

Validates a candidate widget configuration against the official schema for its "type", entirely locally; no TagoIO request is made and nothing is created or changed. Use this as a development-loop check while drafting a widget configuration, before calling create_widget or update_widget. It is not a substitute for those tools' own validation, which still runs on every mutation. On failure it lists the exact invalid paths; use widget_schema_lookup to repair them. <example> { "configuration": { "label": "Tank Level", "type": "gauge", "display": { "gauge_type": "solid", "numberformat": "0", "mi…

Returns the official JSON Schema for a widget type, or lists the supported widget types when no type is given. Use this before create_widget or update_widget to learn the exact configuration a widget type demands (required display fields, data shape, enums), or after a validation failure to repair the listed paths. <example> { "type": "gauge" } </example>