MunkiSee MunkiSee
Log in
Documentation

Deploy, configure, integrate.

Everything needed to get the agent onto a fleet, tune what it watches, and wire the MCP server into an AI assistant.

Installing the agent

The Windows agent is an Inno Setup installer. It runs without any end-user interaction and can be deployed through Intune, SCCM, Group Policy, or anything else that can run a command line. Everything it needs can go on that command line, so a deployment is one line with no files to stage alongside it.

cmd.exe — admin
REM hosted — the key is the only thing it needs
C:\> MunkiSeeClient_1.0.0-x64.exe /VERYSILENT /NORESTART /ApiKey=YOUR-LINKING-KEY
REM self-hosted — point it at your own server too
C:\> MunkiSeeClient_ent_1.0.0-x64.exe /VERYSILENT /NORESTART ^
/ServerUrl=https://munkisee.example.com /ApiKey=YOUR-LINKING-KEY
PARAMETERS
/VERYSILENTNo UI and no prompts. /NORESTARTNever reboots the machine. /ApiKey=The linking key from Settings › Linking Key. Binds the device to your organisation, and can be given an expiry and an enrolment limit. /ServerUrl=Self-hosted builds only. The hosted installer always points at app.munkisee.com. /TlsThumbprint=Self-hosted builds only, optional. Pins the server certificate for installs behind a private CA or a self-signed certificate.

A silent install verifies the key against the server before it completes, so a wrong or expired key fails the deployment instead of leaving a device that quietly never reports in.

OR, WITH AN ANSWER FILE

If your deployment tool would rather not carry the key on a command line, drop an .ini beside the executable instead and pass no parameters. Command-line values always win over the file, so the two can coexist.

CLIENT-CLOUD-INSTALL.INI
[Munkisee] ApiKey=YOUR-LINKING-KEY
CLIENT-INSTALL.INI
[Munkisee] ServerUrl=https://munkisee.example.com ApiKey=YOUR-LINKING-KEY

Once running, the agent reports in every five minutes with one of four states: active, idle, paused, or nothing at all when recording is not permitted. It needs outbound HTTPS to your instance and nothing else — no inbound rules, no VPN, no agent-to-agent traffic.

Working hours

Working hours decide which activity counts as in-hours. They are set for the organisation and can be overridden further down; the most specific rule wins.

SCOPEBEATS
Calendar entryEverything, for the period it covers
UserTheir team, department and the organisation
TeamTheir department and the organisation
DepartmentThe organisation
OrganisationThe default everyone inherits
ACTIVITY OUTSIDE WORKING HOURS

What happens to activity recorded outside those hours is a deliberate, separate choice, and changing it is recorded in the audit log.

full
Recorded in the same detail as in-hours activity.
aggregate
Reduced to a daily total at the moment it is written. The detail is never stored.
disabled
Not recorded at all.

Calendar entries — time off, sick leave, holidays — suspend recording for the period they cover, for one person or for the whole organisation.

Idle time

Two separate settings govern idle time, and they answer different questions.

IDLE THRESHOLD — WHEN A SESSION COUNTS AS IDLE

How long a machine goes without keyboard or pointer input before the agent calls it idle. Anywhere from 1 to 120 minutes, five by default. Agents pick the value up on their next check-in, so a change takes up to one five-minute interval to apply everywhere.

2 min
Kiosks and shared front-desk devices
5 min
Default for office and remote staff
15 min
Review-heavy and engineering workstations
ACCEPTABLE IDLE — HOW MUCH IDLE IS FINE

A daily allowance of idle time that does not count against anyone. It is still recorded and still shown; it simply does not feed the idle offenders ranking. Thirty minutes by default, and it follows the same inheritance order as working hours: a person’s own allowance beats their team’s, which beats their department’s, which beats the organisation default.

Reporting exposes both figures, so a raw idle total and the total that actually counts are never confused for one another.

Accounts and SSO

Every account carries one of four roles. Roles are cumulative — each one includes everything below it.

ROLEADDS
ViewerRead-only access to dashboards, devices and reports.
ManagerTeams, departments and calendar entries.
AdminTracking settings, working hours, thresholds, API tokens and other accounts.
OwnerBilling and licensing.
SINGLE SIGN-ON

SSO is Microsoft Entra ID, over OAuth 2.0. Register MunkiSee as an application in your Entra tenant, then paste the directory (tenant) ID, application (client) ID, client secret and redirect URI into Settings › SSO. A test button verifies the credentials against Microsoft before you switch it on.

OAUTH2Microsoft Entra ID (Azure AD)

SAML and generic OIDC providers are not supported. Multi-factor authentication is available on every account and enforced on hosted MunkiSee accounts.

API tokens

Named tokens give scripts and integrations direct access to the admin API. They are separate from the linking key that agents use, and they are scoped: each token is granted no access, read, or read and write, one area at a time.

AREACOVERS
Devices & activityEnrolment, the fleet, per-person activity and events.
ReportsFleet summaries, heatmaps, exports and scheduled runs.
CalendarTime off and calendar entries.
ConfigurationOrganisation settings, people, teams, departments and keys.
Help centreHelp articles and collections.
curl https://app.munkisee.com/api/v1/devices/status \ -H "x-api-key: <token>"

Anything a token was not granted is refused, including endpoints added to the API after the token was issued. Write includes read. Tokens can be revoked at any time and stop working immediately, and they work the same way on the hosted service and on a self-hosted install.

MCP server

The MCP server exposes fleet data to an AI assistant as tools it can call, over the Model Context Protocol. It is a small Node process that speaks stdio and talks to your MunkiSee instance over HTTPS, so the assistant never holds a connection to MunkiSee itself — only to the server you run.

How you connect depends on where MunkiSee runs, and the settings page shows the right snippet either way — filled in with your own address, so it can be pasted straight into your assistant’s configuration.

HOSTED — NOTHING TO INSTALL

Your MunkiSee serves the MCP endpoint itself. Point the assistant at it with your key; there is no process to run, keep updated, or leave switched on.

{ "mcpServers": { "munkisee": { "url": "https://app.munkisee.com/api/v1/mcp", "headers": { "x-api-key": "<your MCP key>" } } } }

A key only ever reaches its own organisation. The tenant it belongs to is read from the key itself, and the rest of the key is then checked against that tenant’s own record — so a key cannot be pointed at anyone else’s data.

SELF-HOSTED — A LOCAL PROCESS

The installer puts the server on disk alongside MunkiSee, so there is nothing extra to download and no Node of your own to install.

{ "mcpServers": { "munkisee": { "command": "C:\\Program Files\\MunkiSee Server\\node.exe", "args": ["C:\\Program Files\\MunkiSee Server\\mcp\\server.js"], "env": { "MUNKISEE_URL": "https://app.munkisee.com", "MUNKISEE_KEY": "<your MCP key>" } } } }
TOOLS EXPOSED
list_usersPeople being monitored, with their devices. get_user_activityOne person, day by day, over a date range. get_team_summaryEvery person’s totals for a date range. list_devicesThe fleet and each device’s current state. get_device_activityOne machine, day by day, over a date range. list_teamsTeams, members, hours and idle allowance. list_departmentsDepartments, members, hours and idle allowance. get_calendar_eventsTime off and other scheduled absences. get_fleet_summaryOrganisation totals and period-on-period change. get_idle_offendersIdle ranking, after each person’s allowance. get_activity_trendWeek-by-week direction over time. get_automation_signalsPossible jiggler and auto-clicker patterns. get_business_hoursSchedule, timezone, thresholds and allowance. get_hourly_breakdownActive, idle, offline and paused minutes by hour of the day. get_eventsThe raw event stream, every state change, for questions no summary answers.
WHAT IT CANNOT DO
READThe MCP key is refused on anything but a read. There is no write path.
LIMITRate limited to 60 or 300 requests a minute, your choice.
PICKEvery tool can be switched off individually, so an assistant only sees what you chose to expose.

Tools are registered when the assistant starts the server, so enabling or disabling one takes effect on the next start. Rotating the key stops the old one immediately.

Self-hosting

Self-hosted MunkiSee is a Windows installer, the same shape as the agent. It carries its own copy of Node and everything it depends on, so there are no prerequisites to install first and nothing to build. Run it, and the machine is a MunkiSee server.

cmd.exe — admin
REM double-click to run the wizard, or unattended:
C:\> MunkiSeeServer_1.0.0-x64.exe /VERYSILENT /NORESTART

Unlike the agent, the server installer takes its settings from a server-install.ini beside the executable or from the wizard — not from the command line.

[Munkisee] Port=3001 ApiKey= EnableMcp=false
PortWhat the server listens on. 3001 by default; a firewall rule is opened for it automatically. ApiKeyThe linking key agents will use. Leave it blank and one is generated for you — read it back from server-config.json in the install folder, or from the dashboard once you are in. EnableMcpTurns on the MCP server and generates its own separate key.
WHAT YOU GET

The installer registers MunkiSee as a Windows service set to start automatically, so it comes back on its own after a reboot and needs nobody logged in. Logs are written to the install folder and rotated.

The dashboard is served by that same service — it is not a separate application to deploy or a desktop client to roll out. Open a browser on any machine that can reach the server and you get exactly the interface hosted customers use, on your own infrastructure:

http://your-server:3001

The first person to open it creates the administrator account. Everything on this page — working hours, idle settings, accounts and SSO, API tokens, the MCP server — is configured from there, the same way it is on the hosted service.

YOUR DATA

Activity is stored in SQLite alongside the install. There is no separate database server to run, back up, or keep patched, and nothing leaves the machine — agents talk to your server and your server talks to nobody. Back it up by backing up the folder.

Agents need to reach the server on its port and nothing else — no inbound rules on the endpoints, no VPN. Talk to sales for installers and a licence key.