Claude Skills by WYRE-AI

Hudu website records: CRUD via /api/v1/websites, monitoring and pause/disable fields, SSL/TLS certificate tracking, email security status (DMARC, DKIM, SPF), DNS record fields, company linkage, and website validation errors.

Huntress endpoint agents: the agent lifecycle, organization and platform filters, health signals such as `last_seen_at` and version, fleet-audit workflows, and the errors returned for missing or empty agent results.

Huntress MCP fundamentals: HTTP Basic Auth via API key/secret headers, the full MCP tool catalog, token-based pagination, the 60 req/min rate limit, and the common HTTP error codes with their causes.

Huntress billing and summary reports: what each report type contains, the list/get tools for both, and the monthly reconciliation, QBR security summary, and cost-analysis workflows an MSP builds from them.

Huntress SOC escalations: how an escalation differs from an incident, escalation priority levels, the list/get/resolve tools, escalation-to-incident correlation, and the already-resolved and not-found error cases.

Huntress incidents and the remediation lifecycle: querying incidents by organization and status, SOC-recommended remediation details, individual and bulk approve/reject, remediation execution status, and the ordering constraint that incidents resolve only after all remediations are processed.

Huntress organizations as the multi-tenant boundary: org structure, the organization key used for agent deployment, full CRUD operations, client onboarding and offboarding workflows, and the duplicate-key and active-agent deletion errors.

Huntress security signals: how signals differ from incidents, the signal types, listing and filtering by organization, and the threat-hunting and pattern-analysis workflows built on signal data.

ImmyBot MCP fundamentals: Entra ID OAuth 2.0 client-credentials auth (four fields), the `immybot_<domain>_<action>` tool naming and domain list, the two-step desired-state deployment model, the four destructive operations that need explicit confirmation, task/session polling cadence, and HTTP error codes.

ImmyBot computers/endpoints and their tenant grouping: the computer tool surface, workflows for surveying a tenant fleet, locating a device, auditing inventory against desired state, onboarding a new computer record, and forcing an agent check-in, plus the filtering caveats around online status and serials.

ImmyBot maintenance sessions — the reconciliation engine that brings endpoints into their desired state: the session tool surface, start parameters (computer vs tenant scope, type, priority, reboot flag), pause/resume/cancel semantics, polling to a terminal state, failure investigation, and reboot-spanning and queued-vs-running edge cases.

ImmyBot's PowerShell script library and its SYSTEM-context execution model: the script tool surface, the find → validate → confirm target → approve → execute → review workflow, parameter/timeout/execution-context options, and the safety rules governing this destructive, highly privileged operation.

ImmyBot's desired-state software deployment model end-to-end: the software catalog, deployment, maintenance-session and computer tool surfaces; the canonical select → scope → assert → reconcile → verify workflow; and the pinned-vs-latest, conflicting-deployment, and reboot edge cases.

ImmyBot tenants (client organizations) and fleet-wide reporting: the tenant and background-task tool surfaces, the per-tenant compliance scorecard and fleet task-queue audit procedures, and how to assemble a client QBR report from stats, compliance, software inventory, and failed-task history.

Inforcer MCP fundamentals: the gateway X-Inforcer-Region / X-Inforcer-Api-Key headers, the region-based base URL and upstream Inf-Api-Key header, the /beta/ route prefix, the {success,message,errors,data} response envelope, continuationToken pagination, and the integer Client Tenant ID vs Azure AD GUID gotcha. Every other Inforcer skill assumes these patterns.

Inforcer assessments: listing a tenant's assessments (read-only) and triggering an assessment run — the one mutating action in the entire Inforcer surface. Covers what a run refreshes (the data behind alignment, secure score, and drift), its tenant-scoping, and the confirmation discipline it requires.

Inforcer's read-only record of changes and activity: searching and filtering auditEvents by type and date window (the search is account-wide — there is no tenant filter), enumerating the event-type catalog to build valid filters, and the continuationToken paging audit searches require.

Inforcer's core drift-detection surface: baseline templates, tenant alignment scores, alignment details (the per-policy breakdown of a tenant against its assigned baseline), and reading deployed tenant policy state. Read-only.

Inforcer compliance and posture reporting: per-tenant Microsoft 365 secure scores, combining them with alignment scores, and the alignedThreshold / semiAlignedThreshold settings that classify each tenant or policy as aligned, semi-aligned, or drifted. Covers portfolio posture roll-ups across the MSP's managed tenants.

Inforcer's read-only identity inventory for a managed Microsoft 365 tenant: users, groups, and role assignments. Answers "who and what exists" for governance and review rather than performing user administration. Covers the integer Client Tenant ID scoping every identity call requires.

Inforcer's managed Microsoft 365 tenant list and the resolution step that turns a friendly name, DNS domain, or Azure AD GUID into the integer Client Tenant ID. The starting point for almost every Inforcer workflow, since alignment, secure score, identity, and audit calls are all tenant-scoped.

Ironscales MCP fundamentals: API-key plus company-ID header authentication and the per-tenant scoping that follows from it, the nine tools this server registers and what each one actually changes, offset/limit pagination without a total count, rate-limit behavior, and how API failures surface to the model.

Ironscales phishing incidents end to end: incident statuses and severities, the five remediation actions and which of them are irreversible, the stateless AI email-classification tool and the message content it exports, allowlist entries for email/domain/IP, daily-triage and campaign workflows, and the failure modes — already-closed incidents, partial remediation, and allowlist scope.

Kaseya Quote Manager (Datto Commerce) API fundamentals: API-key auth and the gateway's header translation, the read-only `kqm_<entity>_list`/`_get` tool surface across the sales, procurement, catalog, CRM, and org domains, page/pageSize/modifiedAfter pagination, rate limits, and error codes.

Kaseya Quote Manager procurement data: purchase orders with their lines and costs, the suppliers they are placed with, and product-supplier records mapping catalog products to supplier SKUs and pricing. Read-only tool surface.

Kaseya Quote Manager quoting data: the quote → section → line item hierarchy, and the sales orders, order lines, and payments a quote becomes once accepted. Read-only tool surface.

Autotask REST API fundamentals: header-based authentication, zone detection, the query/filter DSL (14 operators, logical grouping, includes), pagination, rate limits, and CRUD conventions across the 215+ entity PSA.

Autotask billing item retrieval, approval-level workflows, and invoice search — covering billing item types, approval status filtering, and reconciliation of billable work against invoices for MSP finance teams.

Autotask Configuration Item (CI) asset management: CI types and categories, lifecycle status codes, the CI field schema, related-item relationships, DNS records, notes, and contract/billing associations for MSP infrastructure tracking.

Autotask contract and service agreement management - contract types (recurring services, block hours, time & materials, fixed price, retainer), service/service bundle associations, SLAs, and how contracts drive billing for MSP account managers.

Autotask CRM entities - companies (accounts), contacts, and sites/locations - including field references, company type classifications, and how these records underpin tickets, contracts, and projects for MSP account management.

Autotask expense report and expense item structure - the report/item parent-child relationship, approval status workflow, expense categories, payment types, and the billable vs reimbursable distinction for MSP operational expenses.

Autotask picklist and reference-data lookups — queues, ticket statuses, ticket priorities, and project phases — the instance-specific configured values required before creating or filtering tickets and other entities.

Autotask product catalog structure - Products, Services, and Service Bundles - and how Price Lists override default unit pricing. Covers product/service fields, inventory tracking, and cost-vs-billing margin analysis for MSP quoting and procurement.

Autotask project structure - projects, phases, tasks, and milestones - including project and task fields, status values, resource assignment, and how project work links to contract billing for MSP project managers.

Autotask quote structure and line items - quote item types (product, service, service bundle, labor, expense, shipping), the mutually-exclusive catalog reference rules, and the three discount mechanisms (unit, line, percentage) used to build customer proposals.

Autotask Service Call data model - the ServiceCall / ServiceCallTicket / ServiceCallTicketResource three-layer structure - covering fields, status codes, and how tickets and technicians (resources) are linked to scheduled work.

Autotask ticket notes, attachments, and charges — the secondary entities attached to tickets: retrieving/searching notes and attachments, and creating, updating, or searching ticket charges for labor and expenses billed directly to a ticket.

Autotask ticket lifecycle: status/priority codes and transition rules, the ticket field schema, SLA calculation and clock behavior, escalation rules, ticket metrics, and the MCP tool surface (create, update, search, history, notes) for MSP service desk operations.

Autotask time entry structure: approval status codes and workflow, the time entry field schema, the billing rate hierarchy, budget and contract-limit validation, utilization analytics, and the MSP business rules for rounding and minimum billing increments.

The Autotask MCP lazy-loading pattern - four meta-tools (list_categories, list_category_tools, execute_tool, router) that expose the full 39+ tool catalog progressively instead of loading every tool schema upfront, plus the natural-language router for intent-based tool lookup.

Datto BCDR (Backup Portal) REST API fundamentals: public/private key HMAC-SHA256 request signing, the /v1 endpoint surface, pagination, appliance/agent hierarchy, and screenshot verification retrieval.

Datto RMM alert structure, priorities, and the 25+ alert context types (antivirus_ctx, eventlog_ctx, perf_disk_usage_ctx, ransomware_ctx, and more), each with its own type-specific fields. Covers alert resolution workflows and context-specific triage guidance.

Datto RMM REST API v2 fundamentals: OAuth 2.0 client-credentials-style authentication, the 6 regional platforms (Pinotage, Merlot, Concord, Vidal, Zinfandel, Syrah), token lifecycle, cursor-based pagination, rate limiting, Unix-millisecond timestamps, and error handling.

Datto RMM audit data structure covering hardware inventory (CPU, RAM, disks, motherboard, BIOS), software inventory, network interfaces, and ESXi/printer audits, along with audit collection cadence and data freshness semantics.

Datto RMM device management: identifiers (UID, hostname, MAC), device types and statuses, user-defined fields (UDF1-30), warranty data, and device lookup/update/delete operations.

Datto RMM job execution: quick jobs vs. scheduled vs. policy jobs, the job status lifecycle, component scripts and their variables, and stdout/stderr/exit-code result handling.

Datto RMM site management: site hierarchy and identifiers, proxy and patch-window settings, site-scoped device/alert queries, and create/update/delete operations for client locations.

Datto RMM account-level and site-level variables: scoping and inheritance (site overrides account), naming conventions and reserved prefixes, CRUD operations, and referencing variables from component scripts.

Datto SaaS Protection (formerly Backupify) REST API fundamentals: regional base URLs, bearer-token auth, the seat/tenant object model, backup status queries, and restore operations.