ImmyBot Agent

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.