- Brand
- Koquelani Systems
- Category
- Developer Tools
- Primary Subcategory
- Desktop, OS & File Automation
Integration details
Description
Manage your workstations, kiosks, servers and more from the prompt with this plugin and its easily deployable Endpoint application. Designed for busy IT managers and sys admins with a desire to leverage the power of AI to solve problems across larger networks of IT equipment from a single prompt. Supports team operations as well with a single shared group of Endpoints (Endpoints are servers, workstations, kiosks, or any device that can run the Endpoint). Sign in with your SupportFlow account, add devices with the provided Endpoint installer in your user portal. Manage them from the prompt. NOTE: Higher security level options available from the user portal.
- Integration type
- Plugin
- Verification status
- Not applicable
- Platform
- ChatGPT
- Primary Subcategory
- Desktop, OS & File Automation
- Secondary Subcategories
- None listed
- Brand
- Koquelani Systems
- Access
- Account required
- First tracked
- 2026-10-27
- Tool count
- 39
- Market
- US
The Primary Subcategory used for this profile’s headline score.
Other Subcategories where the Integration is listed.
Your score is coming
ChatGPT now suggests Plugins on its own when they match a user's request.Your Plugin Discovery Score measures how often yours appears, and it will show here as soon as it’s ready.
What discovery looks like

Get alerts for KQS SupportFlow
Get updates when KQS SupportFlow’s Discoverability Score or category rank changes.
Competing in ChatGPT Desktop, OS & File Automation
View Category39 tools agents can invoke
APPEND one or more lines to the Common Client Knowledge file. Record what you had to work out - a path, an INI name, a caveat that applies at one site - so the next caller does not rediscover it. One line per entry; suggested shape '<what it is> | <path on the kiosk> | <notes>'. The file is shared fleet-wide, so write general knowledge rather than notes about a single machine (per-kiosk observations belong in add_station_note). Capped at 1 MB per tier; a write that would exceed the cap is refused, never truncated. Survives rebuilds via the admin Backup / Restore download. WHICH TIER: if your account is in exactly one VPN group the entry goes there by default; pass 'group' to choose, and an unrestricted operator account writes to the Common tier (read by everyone) unless it names a group. You cannot write into a group you do not belong to.
add_client_knowledge
ADD an operator note to a kiosk — WRITES to the production database (dbo.KioskSpyTerminalNotes), so the note is permanent and visible to everyone using Kiosk Spy and the CCS Support Viewer. Use it to record what you did or found on a kiosk so the next person sees it. Identify the kiosk by 'kioskId' OR 'clientGuid'. 'note' is required. 'addedBy' is who the note is from — supply the actual person's name where you know it; it is written into the note text itself rather than into a user id column, because that column holds Kiosk Spy user NUMBERS an MCP caller does not have. EVERY note added this way is tagged 'Added by MCP <callerIP>' at the end, whether or not addedBy was given, so the origin is always recoverable — a supplied name is whatever the caller typed, the IP is observed. The note is timestamped in the notes timezone so it sorts correctly beside notes written by Kiosk Spy itself. NOT available on the read-only endpoint.
add_station_note
Approve a NEW station waiting to join your organization (list_stations shows it with Trust=Onboarding), so it can be controlled. SupportFlow authorizes it with your organization's ControlKey (Low Security Mode). Only the organization's Administrator or a Manager may approve. The station must be online.
approve_new_station
Capture a fresh LIVE screenshot of the kiosk's screen right now. The FIRST call starts a live relay session and can take ~30s; once connected the session stays warm. Returns a current JPEG frame plus width/height for click mapping.
capture_screen_live_session
Clear all pending commands for a kiosk. Returns how many were dropped.
clear_command_queue
Click (or double-click) at a point on the kiosk screen. Pass x/y in the pixel space of the capture_screen_live_session image along with that image's width/height; or pass x/y as per-mille 0-1000 and omit width/height.
click
Close a persistent shell session started by shell_exec. Call this for EVERY shellId you open once you are done with it — otherwise the shell keeps running on the remote kiosk and sessions accumulate over time.
shell_close
Double-click at a point on the kiosk screen (same coordinate rules as click).
double_click
Terminate a process by pid or by name (best-effort). Returns how many were killed.
kill_process
READ the Common Client Knowledge file - this server's own notes on WHERE things live on the machines it looks after: config files, logs, INIs, install folders, registry keys. CALL THIS FIRST whenever a request names a file by description rather than by path ('pull the configs', 'grab the logs', 'get its settings'), and resolve what the user meant from what is recorded here instead of guessing a path. Optional 'query' narrows it to matching lines (a line must contain ALL the space-separated terms). Knowledge is TIERED: a Common tier everyone sees, plus one tier per VPN group. You are shown the Common tier plus the tiers of the groups your account belongs to, and each result is labelled with the tier it came from. No kiosk required. READ-ONLY.
get_client_knowledge
READ YOUR GROUP'S OWN client-knowledge file, verbatim, as one block of text. This is the per-group tier of the knowledge store - your group's private notes on where things live on ITS kiosks - as opposed to get_client_knowledge, which merges the Common tier and every tier you can see into one labelled listing. Use this one when you intend to EDIT the file: it returns exactly what is stored, which is what set_group_knowledge expects back. If your account is in exactly one VPN group that is the tier you get; pass 'group' to choose when you are in several, or 'Common' for the shared fleet-wide tier. No kiosk required. READ-ONLY.
get_group_knowledge
FAST: return the kiosk's app config GMK100_KIOSK_APP.exe.Config (the Kiosk_configstxt field) as stored in dbo.KioskTelemetry for the given kioskId. This is a pure database read of the value captured on the kiosk's last telemetry sweep — it does NOT poll or contact the kiosk, so it returns almost immediately. The result therefore reflects the kiosk's config as of its last sweep, not necessarily this instant; the age of the reading is included in the output.
get_config
IF A CALLER WISHES TO SEE A SCREENSHOT OF A KIOSK OR STATION, USE THIS CALL UNLESS OTHERWISE SPECIFIED. Returns the MOST-RECENT STORED screenshot of the kiosk's screen from the Telemetry database — immediate, with no live-session setup, and typically only seconds old because it rides the Collector's normal sweep. Identify the kiosk by 'kioskId' or by 'clientGuid' — either on its own is enough, and passing both scopes the frame to that one collector when a KioskID is shared by several. The image is RESIZED before encoding so it costs the caller very little: by default it is fitted inside 128 pixels, giving 128x72 for a normal 16:9 screen — aspect ratio is always preserved, never squashed to a square. That default reply is a few KB. SIZE OPTIONS: pass 'size' for a different longest edge, 32-1920 (e.g. 256 or 512 when you need to read on-screen text), or ask for FULL RESOLUTION with full=true — you may also just pass size='full'. Full resolution returns the stored frame untouched with no re-encode, which for a 1920x1080 desktop is ~250KB of base64 and MAY EXCEED YOUR CLIENT'S RESULT LIMIT, so use it deliberately rather than by default. The reply carries the base64 JPEG plus a JSON block with freshnessSeconds and a readable freshness string, the capture time, the returned and original dimensions, and the byte sizes. For a frame captured RIGHT NOW rather than the last stored one, use capture_screen_live_session instead.
capture_screen_cached
The signed-in account's own organization (or, with none, its own stations): the organization name and code, the account's role, the service plan it is on and its status, every plan on offer, how many stations it has and how many are answering or in Sleep Mode, how many members and how many are signed in right now, and the website and support-ticket page addresses. One JSON object. READ-ONLY - this is what the SupportFlow Client's My Organization page shows.
my_organization
Recent OPERATOR NOTES for one kiosk, newest first, from Kiosk Spy's dbo.KioskSpyTerminalNotes — the same notes the CCS Support Viewer shows on its Notes tab. These are human-written observations about a terminal (what was replaced, what was tried, why it is unusual), so read them BEFORE diagnosing a kiosk: they often explain in one line something telemetry cannot show at all. Identify the kiosk by 'kioskId' OR 'clientGuid' — either on its own is enough. Returns the last 3 by default; pass 'count' for more, up to 50. Each note shows its timestamp, the author where recorded, and the full text. NOTE the timestamps have no timezone in the database — they are stored as Kiosk Spy wrote them, and the Support Viewer renders them using the SupportViewer:NotesTimeZone setting. READ-ONLY.
get_kiosk_notes
Read back the operator DESCRIPTIVE TAG previously set on a kiosk with set_desc_tag (the kioskDescTag value for this KioskID). Returns the tag text, or a note that none is set. READ-ONLY; available on both the full and read-only MCP endpoints.
get_desc_tag
EstimatedLocation is a BEST-EFFORT guess at where the station physically is, worked out from its PublicIP against a public IP-geolocation database - roughly 'City, Region, Country', or the word 'undetermined' when it could not be worked out. It is an ESTIMATE and nothing more: a site behind a corporate WAN egresses wherever its provider breaks out, which can be a different town or a different country, so use it to orient yourself and never as proof of where a machine is. It is looked up ONCE per public address and cached, so it only changes when that station's PublicIP changes. A freshly seen address can read 'undetermined' on the first listing and be filled in on the next. KIOSK DETAILS: return the COMPLETE latest KioskTelemetry record for ONE kiosk as JSON — every column (CPU, RAM, disk, SMART, OS, versions, process list, hardware and KioskApp status, IPs, network counters, event log, ...), included even when null so you can also see which fields exist for that kiosk rather than only the currently-populated ones. This is the companion to list_stations: that tool gives a small summary of the fleet, this one gives EVERYTHING about a single kiosk, so use it whenever you need a field list_stations does not carry. IDENTIFY THE KIOSK BY EITHER 'kioskId' OR 'clientGuid' — you do NOT need both. A clientGuid on its own is resolved to its kiosk, which is the precise way to target one collector when a KioskID is shared by several. The large Screenshot_Base64 column is EXCLUDED because it would dwarf the rest of the record; use the screenshot/capture tools for the image.
get_telemetry
One read of what every station this account can reach currently TRUSTS: KioskID, Responding (telemetry within 2 minutes), Trust (its ctlMode - Onboarding / Enforcing / Corrupt / Locked / Relegated, or empty for a build without ControlKey), its station fingerprint, the keyId:label pairs it holds, the protocol it speaks, the age of its last post, SkewSec (its clock against this server's), Source, and UNKNOWN - keys it trusts that nobody in its organization holds, which means a station claimed by a stranger. Pipe-delimited under a columns= header. READ-ONLY, from the live registry (stations seen since the service started).
controlkey_fleet_state
Read what KIND of machine a station is (the stationType set with set_station_type). CONSULT THIS BEFORE ACTING ON CLIENT KNOWLEDGE for a station: the config paths, expected processes and failure rules in the Common and group knowledge tiers are written per kind of machine, and applying a kiosk's rules to a server or a signage controller can mean reporting a healthy machine as broken - or restarting something that was never meant to be running there. An UNSET value means nobody has classified it, which is NOT the same as 'kiosk': treat it as unknown and ask, rather than assuming. The same value is shown as the StationType column in list_stations, so a fleet-wide answer needs no call at all. READ-ONLY; available on both the full and read-only MCP endpoints.
get_station_type
Read a date range of telemetry snapshots for a SPECIFIC kiosk from dbo.KioskTelemetry_Timeline (UTC), filtered to that kioskId. kioskId is REQUIRED. Excludes 'Lite' heartbeat pings (set includeLite=true to keep them). The large inline screenshot (Screenshot_Base64) is OMITTED by default — set includeScreenshot=true to include it. startDate/endDate are UTC; default range is the last 24h, though the server keeps only its retention window (15 minutes to 72 hours, set on the billing desk; 6 hours by default). Kiosk_configstxt and Process_List are stored only when they change: a row without them means unchanged since the last row that has them (get_telemetry always has the latest). Returns at most the 500 newest rows. READ-ONLY.
telemetry_history
ControlKey transfer requests on your own account. The machine holding a key passes its own 'holderKeyId' to see what is being asked of it; a machine that has asked calls this to see whether it has been answered. Live requests only unless 'all' is true. Each row carries what the asking machine said about itself - NewMachine and RequestNote, both typed at that end and worth exactly what that makes them - and RequestIp / RequestLoc, the address this server SAW the request arrive from and a best-effort guess at where that is. The address is the one field the asking machine did not choose. Pipe-delimited under a columns= header. READ-ONLY.
list_controlkey_transfers
The ControlKeys this account may see: its own, plus the keys of the members it MANAGES; an unrestricted account sees them all. One line per key - keyId, fingerprint, point, label, status (pending / approved / revoked), holder, created, last seen, approved, revoked, reason, machine, who approved it, which key vouched for it, and the signed approval itself (Vouch: base64url statement '.' signature) - pipe-delimited under a columns= header. READ-ONLY.
list_controlkeys
List the contents of a directory on the kiosk.
list_directory
The keys a new station of your organization (or, with estate=mine, of your own stations) may be installed trusting: every approved key of its Administrator and Managers. The SupportFlow Client pins these into an Endpoint installer it saves, so a new station accepts its first authorization only from one of them. Public keys only. READ-ONLY.
org_anchor_keys
List the commands currently queued for a kiosk.
list_pending_commands
Discover which kiosks this MCP can control, most-recently-seen first. TWO DEFAULTS TO KNOW. (1) ROWS: only kiosks currently RESPONDING are listed (telemetry within the last 2 minutes) — pass includeNotResponding=true to list every known kiosk instead, responding or not. (2) FIELDS: a deliberately small summary per kiosk — KioskID, DescTag, StationType, TelemetryCollectorGUID, MachineName, PublicIP, EstimatedLocation, LocalIP, ATMMode, Responding, Kiosk_Running, Explorer_IsRunning — because the complete record for the whole fleet is very large. EstimatedLocation is a BEST-EFFORT guess at where the station physically is, worked out from its PublicIP against a public IP-geolocation database - roughly 'City, Region, Country', or the word 'undetermined' when it could not be worked out. It is an ESTIMATE and nothing more: a site behind a corporate WAN egresses wherever its provider breaks out, which can be a different town or a different country, so use it to orient yourself and never as proof of where a machine is. It is looked up ONCE per public address and cached, so it only changes when that station's PublicIP changes. A freshly seen address can read 'undetermined' on the first listing and be filled in on the next. StationType is WHAT KIND OF MACHINE the row is (kiosk, server, desktop, signage_controller, ...), set with set_station_type: read it before applying any advice from the client knowledge to that station, because config paths and expected processes differ by kind, and a BLANK means nobody has classified it rather than 'kiosk'. DescTag is the operator's own free-text note about that kiosk (what it is, where it sits, why it is unusual), written with set_desc_tag; it is NOT telemetry and is empty on kiosks nobody has tagged, but where it is present it is often the fastest way to tell which row is the machine being asked about — read it before guessing from the KioskID. Pass full=true to get EVERY KioskTelemetry column instead (all except Screenshot_Base64, which is excluded as it would dwarf the rest); expect a big payload, so prefer get_telemetry when you only care about one kiosk — it returns that kiosk's COMPLETE telemetry record by kioskId or clientGuid. RESULT FORMAT: plain PIPE-DELIMITED text, not JSON. A one-line note, then count=N, then a 'columns=' line naming the fields once, then ONE LINE PER KIOSK whose pipe-separated values follow that column order. An empty field means null. Any pipe, tab or newline occurring inside a value is replaced with '^' so a row can never be mis-split; semicolons are left alone, so semicolon-separated fields like Process_List arrive intact. In the summary view TelemetryCollectorGUID is populated ONLY for a KioskID served by more than one live collector — a blank GUID means that KioskID is unambiguous on its own. Use this to pick a target, then pass the chosen kioskId to each tool — there is no select step, every kiosk-scoped tool takes its own kioskId, so you can drive several kiosks at once. A KioskID appearing on more than one row has multiple live collectors: pass that row's clientGuid to target one of them.
list_stations
Force an OS reboot of the kiosk (shutdown /r /f, ~3s delay).
reboot
Refuse a NEW station waiting to join your organization (Trust=Onboarding in list_stations): it stays unauthorized and is never accepted automatically. Only the organization's Administrator or a Manager may refuse. It can be approved later with approve_new_station.
deny_new_station
DELETE every line of the Common Client Knowledge file that contains the given text (case-insensitive substring, at least 3 characters). The exact lines removed are echoed back so you can confirm the right ones went. Use it to retire an entry that has gone stale or turned out to be wrong. Acts on ONE tier - the same default and 'group' rules as add_client_knowledge - so it can never delete another group's notes.
remove_client_knowledge
Remove the two SAMPLE stations - SAMPLE-PC and SAMPLE-SERVER - from this account's station list. They are made-up stations SupportFlow shows every customer account so it can be tried before any Endpoint is installed: they answer questions about their health, telemetry and installed applications, but they are not real PCs and refuse every command. Removing them affects only this account, and none of its real stations.
remove_sample_stations
RENAME a collector - change its KioskID, and move everything that KioskID owns onto the new name in the same call. Use it when a station is renamed, re-sited, or was named wrongly when it was first deployed. IT IS ONE OPERATION FOR A REASON: the KioskID is the key for the telemetry history, the operator notes, the descriptive tag, the station type, the VPN group memberships and the Support Portal assignments. Change only what the machine reports and it comes back as a stranger - no group (so a kiosk-limited account stops seeing it at all), no notes, no type - while the old name sits in list_stations forever looking like a terminal that died. TWO STEPS, ALWAYS. (1) Call it with kioskId (the CURRENT name) and newKioskId. NOTHING is changed: you get back a count of exactly what would move, so you can show the user what they are agreeing to. (2) Call it AGAIN with confirm:true to do it. The machine is renamed FIRST and the records follow, so a collector that is unreachable leaves everything untouched rather than stranding its history under a name the machine never adopted. The new name must not already be a known station - merging two machines histories cannot be undone, so that is refused. WHAT IS NOT TOUCHED: the Windows machine name, and the kiosk applications own TerminalID in its config (reported separately as Kiosk_KioskID). Those are different facts about the same box and this tool does not rewrite either. No restart is needed - the collector picks the new name up on its next sweep and remembers it across restarts. If the machine has ALREADY been renamed by hand, or is offline, pass serverOnly:true with confirm:true to move the server-side records on their own. NOT available on the read-only endpoint.
rename_endpoint
REPLACE your group's client-knowledge file with the text you supply. This OVERWRITES the whole tier - it does not merge - so the correct sequence is always: call get_group_knowledge, edit the text it returns, then send ALL of it back here. To append a single line without rewriting anything, use add_client_knowledge instead; to delete specific lines, use remove_client_knowledge. A replacement that would REMOVE entries is refused unless you pass replace_all=true, which stops a partial rewrite from silently destroying notes somebody else recorded. Same tier rules as add_client_knowledge: your own group by default, 'group' to choose, and you cannot write into a group you do not belong to or into Common unless your account is unrestricted. Capped at 1 MB per tier. Survives rebuilds via the admin Backup / Restore download.
set_group_knowledge
Ask a station to catalogue WHAT IS INSTALLED ON IT and WHAT FILE TYPES ARE REGISTERED, and to post the result back to this Listener's Feedback Repository. Use it when a call turns on what a machine actually has on it - which version of an application is deployed, whether something is installed at all, or what program a given extension opens - because nobody sitting at the station can answer that accurately. NOTHING COMES BACK IN THIS CALL. The command is queued and the station runs it on its next telemetry sweep, so it works on a station with no live tunnel; the catalogue then arrives as an upload, normally within a minute for a station reporting normally, and whenever it next reports for one that is offline. Then call 'list_catalog_sweeps' to see it land and 'read_catalog_sweep' to read it. The sweep reads the REGISTRY only - installed-program entries from all three uninstall hives, and extension-to-handler registrations - so it costs the station milliseconds and does not walk its disk.
start_catalog_sweep
Run a command in a hidden, persistent cmd.exe on the kiosk and return its output. Reuse a session by passing the returned shellId; omit it to start a new shell. IMPORTANT: every shell session you start stays OPEN on the kiosk until you close it — when you are finished with a session, ALWAYS call shell_close with its shellId. Leaving sessions open lets them pile up on the remote kiosk and consume its resources.
shell_exec
Type text / send keystrokes to the kiosk's foreground window using System.Windows.Forms.SendKeys syntax (e.g. 'hello{ENTER}', '^c' = Ctrl+C, '%{F4}' = Alt+F4).
send_keys
INVITE somebody into a VPN organization by email. The invitation link creates their account and puts them straight into the organization - there is nothing further to approve - and it is good for 24 HOURS and works ONCE. The address matters: the invitation is LOCKED to it, so forwarding the link to somebody else will not let them in. WHO CAN USE IT: an account that MANAGES an organization (the account that created it at signup) may invite into that organization and no other; an unrestricted operator account may invite into any, but must name it. An invited member does NOT become a manager and cannot invite anyone else. Requires the signup portal's public address and outgoing mail to be configured, and says so plainly if either is missing - it will not send a link built from a hostname that only resolves on the server itself. If the mail fails, the invitation still exists and the reply carries the link so it can be passed on by hand.
send_invite_email
Assign (or clear) an operator DESCRIPTIVE TAG on a kiosk — free-text you choose (e.g. a location note, an owner, a ticket #). Stored in the kioskDescTag column of dbo.KioskTelemetry; it is NOT telemetry, so it PERSISTS across the kiosk's sweeps and is never overwritten by the Collector. The tag belongs to the KioskID (applies to every collector reporting under it) and is read back with get_desc_tag. Pass 'tag' (up to 1000 chars); an empty/omitted 'tag' CLEARS it. Does not change the kiosk's last-seen time, and does nothing if the kiosk has never reported telemetry. NOT available on the read-only endpoint.
set_desc_tag
Classify WHAT KIND OF MACHINE a station is: kiosk, server, desktop, signage_controller, or any other short label an estate needs. Stored in the stationType column of dbo.KioskTelemetry; it is NOT telemetry, so it PERSISTS across sweeps and the Collector can never overwrite it. Belongs to the KioskID (applies to every collector reporting under it). WHY IT MATTERS: client knowledge - both the Common tier and your group's - describes where files live, which processes should be running, and what counts as broken, and those answers DIFFER BY KIND OF MACHINE. A server is not a kiosk with a different name. Set this so callers (including you, later) can pick the right advice instead of assuming everything is a kiosk. THE VALUE IS NORMALISED to lower case with underscores between words, because it is meant to be COMPARED: 'Signage Controller', 'signage-controller' and 'signage_controller' all become signage_controller. Use the same spelling for every station of a kind. Pass an empty 'stationType' to clear it. Does not change the kiosk's last-seen time, and does nothing if the station has never reported telemetry. NOT available on the read-only endpoint.
set_station_type
Start a process on the kiosk. Returns its PID. hidden=true runs it with no window; otherwise it launches in the interactive session.
start_process
KQS SupportFlow ChatGPT Plugin FAQ
How the directory, categories and Discoverability Score work.
Read the methodologyHow do I improve KQS SupportFlow's ChatGPT Plugin discoverability?
The levers are the listing surface agents actually read: names, descriptions, keywords, tool metadata, and registry health. Which lever matters depends on where discovery breaks, which is what continuous measurement shows.
What are KQS SupportFlow alternatives on ChatGPT?
As of 2026-10-28, KQS SupportFlow competes with Cmdexa, Drive Commander for Mac, Ganado Bridge, Keep Browser, Light Remote, MA Commander, Remote Desktop Commander, TRIGGERcmd in ChatGPT Desktop, OS & File Automation, ranked by public Discoverability Score.
Where is this profile measured?
This profile uses the geography attached to the latest public registry snapshot: US. Locale tags are intentionally omitted.