ImmyBot MCP server and AI skills
Deployment automation you can interrogate.
ImmyBot is the machinery under your software fleet — deployments, maintenance sessions, and the schedule that runs while everyone is asleep. Connect your instance and a session can read all of it: which tenants and computers it manages, what's deployed where, which maintenance sessions failed and why, and what's queued to happen next. The connection is read-only in the structure of the code, not as a setting — there is no way to start a deployment, edit a task, or touch an endpoint from here. Switchboard connects through an MSPStuff-hosted MCP server, so there's nothing to install and no API keys to hand your techs.
- 111 skills
- 12 playbooks
- Read-only by default
- Every answer traced
A question in plain English. A result you can work with.
This illustrative session shows one of the documented questions below. Your results come from your connected environment and the access your admin grants.
| Deployment | Reported reason |
|---|---|
| Acme · PDF reader | Installer exit code |
| Harbor · Browser update | Device offline |
| Northstar · Office suite | Reboot required |
The story
What changes once it’s connected.
Hosted and external AI connections provide read-only access. Guidance, shared playbooks and automations we release for everyone are included with Dedicated. Bespoke automation builds are scoped separately. Any change a platform could make is held back — refused by our server before anything reaches the platform — until a person switches it on, and nothing is switched on today. Vendor consent does not switch any change on.
When an ImmyBot deployment goes wrong you find out the same way every time: by scrolling session logs at eight in the morning. Connected, the question is asked once instead — which deployments failed this week and why, what version of an app is actually deployed at a given client, which computers are stale or stuck in onboarding, and what tonight's maintenance window is going to touch before it touches it.
The coverage follows how ImmyBot is really structured. Tenants — the customer orgs it deploys into — with agent online/offline status as the first call for 'is anything down'. The computer roster with per-machine detail, sessions and primary person. Both software catalogs: the global one ImmyBot maintains and the local one your instance defines. Maintenance at both depths — the sessions that ran (the execution log) and the task library they ran from. And provider links: the RMM and PSA integrations your instance sits on top of, with their client mappings, which is the join key when a session cross-references ImmyBot against Automate or PSA data.
One honest edge worth knowing: the setup is the heaviest of the group, and we'd rather say so. Authentication is an Entra app registration using client credentials, and ImmyBot only accepts the token after a person mapping inside ImmyBot itself — the connect page walks through all of it, including the one step that bites everyone (the Enterprise App object ID, not the app registration's). Ten minutes with the walkthrough, and the connector verifies both stages live before saving anything.
Things you can ask
Ask it like you’d ask a teammate.
Skills and playbooks
Every skill, in the open.
Read-only today. No credential we issue carries a write scope. Any change the integration could make in ImmyBot is held back — refused by our server before anything reaches ImmyBot — until a person switches it on, and nothing is switched on today. So today nothing here starts or cancels a deployment, edits a maintenance task, changes a schedule, onboards a computer, or sends anything to an endpoint. The credential is your own Entra app mapped to an ImmyBot user, so everything the agent reads is attributed to that user in ImmyBot's own audit trail, and a session sees exactly what that user can see.
What it can do
- Tenants & agent healthThe shape of the instance: which customer tenants ImmyBot manages, and live agent online/offline status — the first call for 'is anything down'.2skills
Reading only — no tenant is created, renamed, or relinked from here.
- List the customer tenants, with filtering and paging.
- Agent online/offline rows, instance-wide or for one tenant.
- ComputersThe device roster ImmyBot deploys to, from fleet sweeps down to one machine's full detail.2skills
Reading only — no computer is onboarded, reassigned, or sent anything. Stale/onboarding flags are triage filters, not actions.
- Page through computers — filter by name/user, tenant, stale, or onboarding.
- One computer in full, optionally with its sessions and primary person.
- Software catalogsWhat ImmyBot can deploy: the global catalog it maintains and the local entries your instance defines.2skills
Reading only — nothing is added to either catalog, and no deployment is triggered.
- The ImmyBot-maintained global software catalog.
- Your instance's own software entries.
- Maintenance & tasksThe execution story: maintenance sessions that ran (and failed), and the task library they were built from.2skills
Reading only — no session is started, retried, or cancelled, and no task is edited. Session queries go through ImmyBot's grid endpoint, so very exotic filters are probed rather than assumed.
- Maintenance sessions (execution runs), filterable by computer or tenant.
- Search the maintenance task library, global or local.
- What your instance supportsThe shape of your own ImmyBot instance: what it offers that a session can ask it for, which is what settles whether a question has an answer here at all.1skills
Reading only — this reports what the instance says about itself, and turns nothing on.
- What your own instance supports — the answer to what this connection can be asked for, read from the instance rather than assumed.
- Provider linksThe RMM/PSA integrations your instance sits on top of, with client mappings — the join key for cross-referencing against Automate or PSA.1skills
Reading only — no provider is linked, unlinked, or remapped.
- Provider integrations and, optionally, their client mappings.
- Billing & licenses10skills
- The MSP's ImmyBot billing-platform account details (billing provider identifiers, plan tier).
- The MSP's ImmyBot customer/billing information (contact + billing address on file).
- Payment methods on file for the MSP's ImmyBot subscription.
- Current usage counts against the MSP's ImmyBot plan limits (e.g. computers, tenants) — the "how close to the cap" check.
- ImmyBot's billing product catalog (plans/tiers available).
- Line items within ImmyBot's billing product catalog (add-ons, per-unit pricing).
- The MSP's current ImmyBot subscription — plan, seats, renewal date, add-ons.
- Software license keys tracked in ImmyBot (for volume-licensed deployments). Optional filters/targetTenantId to scope.
- License keys via the DevExtreme grid endpoint.
- One tracked license key in detail (metadata only — not the key material via this tool). Requires licenseId.
- Detected software10skills
- Software detected on computers associated with one person (their devices). Requires personId.
- Org-wide search of detected/inventoried software by name substring or exact match. Requires q; optional searchMode.
- Find detected software by its MSI upgrade code (stable across version bumps — useful for "is this app anywhere" across renames). Requires q.
- Org-wide computer hardware/software inventory via the DevExtreme grid endpoint.
- Detected-computer-software rows via the DevExtreme grid endpoint, optionally scoped to one tenant.
- One detected-computer-software row by id (from the tenant software-from-inventory grid). Requires id.
- Raw result of one inventory script on one computer (custom inventory data point). Requires computerId and inventoryKey.
- Configured inventory tasks (the custom scripted inventory points computers collect, e.g. registry/file checks).
- Get software versions.
- Latest known version metadata for one software catalog entry. Requires scope (global|local) and softwareIdentifier.
- Maintenance actions7skills
- Maintenance actions via the DevExtreme grid endpoint, org-wide. Also accepts Sieve Filters/Sorts/Page/PageSize.
- Maintenance actions for one computer via the DevExtreme grid endpoint. Requires computerId.
- Get maintenance action logs.
- Most recent maintenance action recorded for one computer. Requires computerId.
- Latest maintenance actions for tenant.
- Resolve one maintenance item (a software or task reference) by type + identifier. Requires maintenanceType and maintenanceIdentifier.
- Resolve a specific software version referenced by a maintenance action. Requires softwareType and softwareIdentifier; optional version.
- Operations6skills
- All change requests (not just target-assignment ones) via the DevExtreme grid endpoint.
- Fast count of open (pending-decision) change requests instance-wide — the approval-backlog number.
- All ImmyBot notifications (acknowledged + unacknowledged) via the DevExtreme grid endpoint.
- List notifications.
- Available ImmyBot release versions and this instance's update-channel state.
- Timezone values ImmyBot accepts for scheduling — reference data for building/interpreting schedules.
- Provider health10skills
- One provider link in full detail (config, client mappings if requested). Requires id.
- Clients (companies) this provider link sees, as known to the upstream RMM/PSA. Requires id.
- List provider link client statuses.
- List provider link client types.
- Audit log for one provider link (config changes, sync events) via the DevExtreme grid endpoint. Requires id.
- Current rate-limiter statistics for one provider link — is this integration being throttled. Requires providerLinkId. 204 (no body) means the provider is not yet initialized; 404 means it does not support rate limiting.
- Circuit-breaker state for all policies (which upstream integrations are currently tripped/isolated).
- Provider agents pending counts.
- Why ImmyBot could/could not auto-identify one pending provider agent. Requires agentId.
- Identification conflicts for one computer (multiple candidate provider agents matching it). Requires computerId.
- Scripts13skills
- Scripts (global + local) via the DevExtreme grid endpoint. Optional databaseType to scope global vs local.
- Search scripts (Sieve Filters/Sorts + paging). globalOnly/localOnly narrow to one catalog.
- List global script names.
- One global script in full, including its content. Requires scriptId.
- Edit-history audit trail for one global script. Requires scriptId; optional skip for paging.
- What else references one global script (software/tasks that use it) — the "is this safe to touch" check. Requires scriptId.
- Lightweight name list of local (instance-defined) scripts. Optional searchFilter/scriptCategory/searchType.
- One local script in full, including its content. Requires scriptId.
- Edit-history audit trail for one local script. Requires scriptId; optional skip for paging.
- Authorization/permission details for one local script (who can run/edit it). Requires scriptId.
- What else references one local script — the "is this safe to touch" check. Requires scriptId.
- Reference counts for a script by type — a cheap check before drilling into get_*_script_references. Requires scriptType; optional id to scope to one script.
- Preflight scripts currently disabled instance-wide — a hygiene check for accidentally-skipped pre-checks.
- Target assignments10skills
- One local (tenant-scoped) target assignment in full — the deployment record itself (software/task, target, schedule). Requires id.
- One global (ImmyBot-maintained) target assignment in full. Requires id.
- All target-assignment change requests (pending edits awaiting approval) across the instance.
- Change requests scoped to one deployment (local target assignment). Requires deploymentId.
- One target-assignment change request by id — what edit is proposed and its approval state.
- Before/after diff for one target-assignment change request. Requires changeRequestId.
- ImmyBot-recommended optional-assignment approvals awaiting a decision — the approval backlog.
- Optional target-assignment approvals pending for one computer. Requires computerId.
- Configured run-order of maintenance items (software/tasks) — the sequencing target assignments deploy in.
- Preview which target assignments would apply/override for one computer still in onboarding (desired-state resolution). Requires computerId.
- Tools13skills
- Maintenance status counts.
- Per-tenant computer counts — the coverage denominator. Stable; use for "how many computers per client".
- List onboarding computers.
- Latest NON-compliant maintenance actions for one tenant (the compliance gaps). Requires tenantId.
- Maintenance actions needing attention on one computer. Requires computerId.
- Provider agents that are pending / unidentified (onboarding hygiene) — endpoints an RMM sees that ImmyBot has not matched.
- Deployments — what software/task is targeted at which tenant/computer/person (what SHOULD be installed). Set global for global assignments; optional tenantId.
- Software detected on one computer (from inventory) — for patch/version questions. Requires computerId.
- Recurring maintenance schedules. Optional tenantId.
- One maintenance session in detail (optionally its actions/stages). Requires sessionId. Logs are a separate live pull — not cached.
- Unacknowledged ImmyBot notifications (open alerts).
- Provider-link metrics — rate-limit / circuit-breaker health of the RMM connectors ImmyBot sits on. Use for integration health.
- This agent, org, token scopes, and derived write/destructive capability flags. No ImmyBot call — immybot-mcp enriches with connection status and cached-token expiry.
- Users & roles22skills
- ImmyBot users (technician/admin logins — distinct from Persons, which are per-tenant end users). Sieve Filters/Sorts + paging.
- One ImmyBot user in full. Requires userId.
- Groups one user belongs to. Requires userId.
- Auth claims for the calling PAT's underlying user — what ImmyBot itself thinks this identity can do.
- All role assignments and groups for the calling PAT's underlying user — the effective-permissions view.
- All defined roles (permission bundles) on this instance.
- One role in full, including its permission set. Requires roleId.
- Every permission string ImmyBot recognizes — the vocabulary roles are built from.
- Users assigned to one role, via the raw DevExtreme grid endpoint. Requires roleId.
- All user-role assignments instance-wide, via the raw DevExtreme grid endpoint.
- Role assignments for one user, via the raw DevExtreme grid endpoint. Requires userId.
- Count user role assignments for user.
- All user groups on this instance (the unit role assignments and permissions can target).
- One group in full. Requires groupId.
- Users belonging to one group. Requires groupId.
- Role assignments granted to one group, via the raw DevExtreme grid endpoint. Requires groupId.
- Per-tenant end-user identities (Persons — distinct from Users, which are technician/admin logins). Sieve Filters/Sorts + paging.
- One person in full. Requires id.
- List persons dx.
- Persons who have requested self-service portal access and are awaiting a grant/deny decision.
- Tags defined on this instance (the grouping primitive usable in tenant/computer filters). Optional name/tenantId filters and paging.
- One tag in full. Requires tagId.
How it has been taught to work it
Playbooks are the vetted techniques a session loads for this platform — what to check, in what order, and what a number means before it is reported.
- Deployment audit — what ran, what failed, what's deployableWhich deployments or maintenance sessions failed and why, what happened on a machine overnight, "did the rollout land", what software Immy can deploy.
- ImmyBot ↔ RMM cross-reference — using provider-links to join tenants across the brainA question spans ImmyBot and the RMM/PSA it sits on top of — matching ImmyBot tenants and computers to the ConnectWise (Automate/Asio) or other-RMM agents in the same brain, so deployment state and fleet/ticket state can be joined for one client.
- ImmyBot agent health — offline/stale agents, pending provider-agents, link metricsAre ImmyBot's agents healthy — which computers are offline or stale, which provider-agents are pending onboarding, and how the provider-links themselves are performing.
- ImmyBot billing and licensing — the MSP's own subscription, and software license keysThe MSP's own ImmyBot plan/subscription/invoicing/usage-vs-cap, or software license keys ImmyBot tracks for volume-licensed deployments. NOT for a client's billing — that's the PSA.
- ImmyBot domain model (a deployment/automation platform, NOT an RMM)Always when ImmyBot is attached. Its domain model — tenants/computers/persons, sessions vs actions, tasks+software as the catalog, target-assignments, provider-links, local vs global id spaces — why it is not a monitoring RMM, and the read/write boundary (a DARK write surface now exists — see [[immy-write-capability]]).Always on
- ImmyBot maintenance review — session status, failures, non-compliant actionsDid maintenance run and succeed — session status counts, failed or needs-attention runs, and the per-item non-compliant actions inside them, for a tenant or the fleet.
- ImmyBot onboarding coverage — backlog vs tenant computer countsHow much of the fleet is onboarded into ImmyBot — the onboarding backlog, per-tenant computer counts as the coverage denominator, and tenants with no computers at all.
- ImmyBot scripts catalog — global vs local script content, audit trail, referencesWhat a script actually does, its edit history, what software or tasks depend on it before touching it, whether it's authorized to run in this tenant, or which preflight scripts are disabled instance-wide.
- ImmyBot software deployment — target-assignments (desired) vs detected (actual), READ ONLYWhat software is ImmyBot supposed to deploy where, and what is actually installed — target-assignments (global vs tenant), the catalog, and per-computer detected software. Reads only; deploying is future work.
- ImmyBot target-assignment governance — change requests, approvals, single-assignment detailIs a specific deployment change pending approval, what exactly a proposed edit changes, what's waiting in the approval backlog for a tenant or computer, what a single target assignment or the maintenance-item run order actually says, or what would apply to a computer still in onboarding.
- Querying ImmyBot — the three paging regimes, shifting response shapes, and where the spec liesAlways when ImmyBot is attached. How to page it, the response shapes that differ between look-alike endpoints, why the captured spec cannot be trusted, the known traps (429s, onboarding 500, numeric status codes), and that a DARK write surface exists (see [[immy-write-capability]]).Always on
- Tenant roster & RMM cross-referenceWhich tenants ImmyBot manages, per-tenant computer counts, which RMM/PSA clients map to which Immy tenants, coverage gaps between Immy and the RMM.
Plus 18 more every session carries regardless of platform — how to shape an investigation, keep every number traceable, and say plainly when something is broken.
Connecting
Wire it in, in an afternoon.
How to connect
- 01Register a single-tenant app for ImmyBot in Microsoft Entra (client credentials) and create a secret.
- 02In ImmyBot, map the app's Enterprise App object ID to a Person (AD External ID) with an Admin user.
- 03Enter your instance URL and the three Entra values on the connect page — it verifies both auth stages live before saving.
Common questions
Asked before you had to ask.
Does ImmyBot have an API or MCP server?
ImmyBot publishes a RESTful API and includes a built-in MCP server in your instance, which lets AI tools look things up or take action. MSPStuff hosts a separate ImmyBot MCP server that is read-only today, across the tenants your mapped ImmyBot user can see: it starts no deployment, sends nothing to an endpoint, and traces every answer to the real tool calls behind it.
Is there an AI skill for ImmyBot?
Yes — MSPStuff ships AI skills for ImmyBot, hosted in Switchboard. You connect ImmyBot once; sessions then answer questions about it in plain English. There is nothing to install to use Switchboard and no API keys to hand your techs.
Is there a ImmyBot MCP server?
Yes. The ImmyBot integration is an MCP server that MSPStuff hosts and operates for you — Switchboard sessions call it with credentials you control, and every answer is traced to the real tool calls behind it.
Can it change anything in ImmyBot?
No. The integration is read-only today: every skill is a read. Any change the integration could make in ImmyBot is held back — refused by our server before anything reaches ImmyBot — until a person switches it on, and nothing is switched on today. See the access section above for the exact guarantee.
Does this use the ImmyBot API?
Yes. The ImmyBot integration is an MSPStuff-hosted MCP server built on the ImmyBot API. Read-only today. Any change the integration could make in ImmyBot is held back — refused by our server before anything reaches ImmyBot — until a person switches it on, and nothing is switched on today. You connect once with credentials you control; nothing is installed on your side.
Is there a ImmyBot connector for my AI?
Yes. Supported clients such as ChatGPT (OpenAI), Claude, Copilot and Cursor use the same MSPStuff MCP endpoint. Your admin controls access per person and data domain, and every platform call uses read-only permissions.
Related
Keep patching the board.
Get AI connected to your stack.
Apply for the beta: 14 days free on the Hosted plan against your own environment, read-only, every answer traced. Accepted MSPs get half off seats and client tenants for the first year. Dedicated infrastructure is priced separately.