Claude Skills by wyre-technology

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 device management: identifiers (UID, hostname, MAC), device types and statuses, user-defined fields (UDF1-30), warranty data, and device lookup/update/delete operations.

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.

IT Glue REST API fundamentals: JSON:API request/response structure, x-api-key authentication across regional endpoints (US/EU/AU), filter and sort syntax, pagination, sideloading with includes, rate limits, CRUD operations, and error handling.

IT Glue contacts — the people (clients, vendors, partners) associated with an organization. Covers contact types, the emails/phones array structure, location linkage, PSA sync, and lookup patterns.

IT Glue organizations (companies/clients): the foundational entity all documentation, configurations, contacts, passwords, and flexible assets attach to. Covers organization types, statuses, parent/child relationships, PSA sync fields, and quick notes.

IT Glue passwords: secure, organization-scoped credential storage with categories, folders, restricted-access flags, OTP secrets, and embedding into documents and flexible assets. Covers access-control and rotation practices for handling sensitive credentials.

Kaseya BMS PSA REST API v2 fundamentals: tenant subdomain routing, API-token bearer auth, Kaseya One SSO bridging, ticket and account workflows, and OData-style pagination.

Kaseya VSA REST API fundamentals: two-step token-based authentication, the /api/v1.0 surface, pagination ($skip/$top) and filtering ($filter), the request/response envelope, error codes, and Kaseya One SSO bearer-token auth for unified-login tenants.

RocketCyber agent (RocketAgent) deployment, communication status, health monitoring, and troubleshooting: agent installation, online/offline status, agent-to-account mapping, and platform support.

RocketCyber REST API v3 fundamentals: Bearer token authentication, regional base URL selection, pagination, rate limiting, error handling, and account hierarchy navigation.

RocketCyber security incident lifecycle: severity levels, verdicts (Malicious/Suspicious/Benign), status transitions, SOC analyst triage patterns, and cross-vendor PSA ticket correlation.

Spanning Cloud Backup REST API fundamentals: admin-email + API-token auth, the per-platform endpoint surface (M365, Google Workspace, Salesforce), the user/license model, backup status queries, and restore operations.

Unitrends Backup REST API fundamentals: session-token login exchange, the appliance-vs-asset hierarchy, backup job status queries, recovery point listing, and replication state.

The Keeper Secrets Manager tool surface as exposed through Conduit: the nine read-only tools and their access tiers, the ten blocked tools and whether each is withheld by policy or broken upstream, the arguments stripped from `generate_password`, how the KSM application bounds everything the connection can see, the `configBase64` credential, and the error vocabulary.

Building the Keeper Secrets Manager application that a Conduit connection authenticates as: what an application, a share and a client device are, how folder and record grants bound everything the connection can ever see, read-only vs editable shares, generating the base64 device configuration in the Vault UI or Keeper Commander, verifying the realised scope from the client side, and rotating or revoking a device.

Locating the right Keeper record without reading any of them: the metadata returned by `list_secrets`, `search_secrets` and `list_folders`, how record UIDs, titles and folders relate, what `search_secrets` actually matches on (and what it silently does not), the query strings its validator rejects, and why an empty result set usually means scope rather than absence.

The KSM notation string grammar accepted by `get_field`: the three-part `<record>/<type>/<field-path>` shape, the four field-path forms (plain, indexed, property, indexed-property), `field` vs `custom_field` vs `file` selectors, how the record segment is classified as a UID or a title, which characters the validator rejects outright, and how the returned value is masked.

Reading credential material out of Keeper safely: what `get_secret` returns and exactly which parts of it masking covers, the `fields` parameter, `unmask` semantics under a container deployment with no confirmation prompt, why a record's field list is not guaranteed complete, `get_totp_code` versus unmasking a TOTP seed, and the handling rules for secret material once it is in an agent transcript.

How the KPN tool surface behaves through Conduit: the X-KPN-* credential headers and the two OAuth token realms (API Store vs Mobile Services Management), why a valid key can still fail with 401/403 (product entitlement), quota headers and 429 handling, the write-confirmation flow, and why failed MSM writes are never retried automatically.

KPN business mobile through Mobile Services Management (MSM v11): subscribers, contracts (lines/SIMs), allowed operations per contract, orders and service requests, invoices and invoice PDFs, the customer's organisation tree and usage thresholds; plus the confirmed writes (SIM block, unblock, replace; order authorize and cancel) and PIN/PUK handling.

Address- and number-level lookups against KPN: current and planned outages at a Dutch address (Disturbance Check), available access technology and speeds at an address (Speed Check), and the date of the last SIM swap on a KPN mobile number as a fraud signal.

Microsoft Graph fundamentals shared by every M365 skill: Entra token scopes and the per-request Bearer model, OData query operators and filter syntax, @odata.nextLink pagination, delta queries for incremental sync, 429 throttling and retry behavior, JSON batching, and the common Graph error codes.

Exchange Online mailboxes through Microsoft Graph: the four mailbox types and how they differ, message listing and search, inbox rules, out-of-office and forwarding, mailbox size and quota, shared-mailbox access management, and mail flow diagnostics.

The M365 tenant security checks that distinguish a secure tenant from a vulnerable one: per-user authentication-method inspection for real MFA enrollment, sign-in risk and risky users, suspicious inbox rules, legacy authentication exposure, conditional access coverage, Secure Score, and the indicator set for a compromised account.

The Entra ID user object as M365's central identity: key properties and their MSP relevance, account status values, the license assignment model, Graph patterns for listing/searching/creating/disabling users, MFA status checking, and the onboarding and offboarding sequences.

Sender allow/block rules at all five scopes: downward inheritance (reseller rules apply to everything beneath), the listing that returns only directly-attached rules, create with `rule_type: allow|block` and address-or-domain values, and the flat delete endpoint.

Mailprotector MCP fundamentals: gateway header authentication (`X-Mailprotector-Api-Key` / `X-Mailprotector-Reseller-Id`) and its translation to the upstream Bearer token, the Provider → Reseller → Customer → Domain → User Group → User entity hierarchy, the router-pattern tool surface with `mailprotector_execute_tool` for the long tail, scope/scope_id consolidation, field-based list filtering, `page` pagination (max 50 on messages), and error handling.

Customer lifecycle (create/edit/delete under the reseller), domain creation with the Pending → Active verification flow and verification_token, domain aliases, moving domains between customers, address discovery, and mail routing via email destinations and email sources.

Quarantine triage across all five scopes (reseller/customer/domain/ user_group/user): message fields (`quarantine_type`, `decision`, `score`, scoring `results`), releasing a single message via `/deliver`, bulk release via `/deliver_many` with its silent scope-mismatch skip and the `all_selected` release-everything switch, and the release permission flags in configuration.

User groups as the service container (services get/update with its deactivate-what-you-omit semantics), user CRUD including create_many and find_by_address, user aliases, password resets, and user syncs — LDAP/AD source creation, Entra/Google console-only sources, sync schedules, and comparison-type filters.

Cisco Meraki MCP fundamentals: the full tool catalog, gateway header authentication, Dashboard API v1 structure, Link-header cursor pagination, per-org rate limiting, the read-only / confirm_destructive_action safety model, the meraki_raw_request escape hatch, and error handling.

Cisco Meraki device inventory and lifecycle: serial-based identity, the MX/MS/MR/MV/MG/MT product lines, org inventory vs network assignment, reboot and removal, and device/uplink status via meraki_raw_request.

Cisco Meraki MX security appliance: the L3 outbound firewall rule model and the full-ruleset replacement semantics of meraki_appliance_firewall_l3_update, plus Auto VPN site-to-site peer status via meraki_appliance_vpn_status_get.

Hands-on Cisco Meraki diagnostics: the async live-tools pattern (ping, cable test, throughput, wake-on-LAN, ARP/MAC tables) that rides the meraki_raw_request passthrough because live tools are not curated tools, plus device reboots and uplink/connectivity checks.

Connecting the Microsoft Graph MCP Server for Enterprise (public preview) through the Wyre gateway: BYOC multi-tenant Entra app registration, the tenantId/clientId/clientSecret triple, the delegated MCP.* permissions and the per-tenant admin consent that must be granted out of band, plus the read-only design, the 100 calls/min/user limit, licensing implications, and a symptom-to-cause troubleshooting table.

Mimecast MCP fundamentals: the available tool catalog, OAuth 2.0 client-credentials authentication, regional API endpoints, pagination, rate limiting, and error handling.

N-central MCP fundamentals: User-API Token (JWT) authentication through Conduit, 1-based pagination with the totalItems/totalPages envelope, rate-limit behavior, preview-endpoint caveats, and on-prem server specifics.

N-central device records: listing with saved device filters (filterId), asset and warranty lookups, lifecycle reads and updates, and service-monitor status triage on a single device.

N-central monitoring and automation: active-issue triage per customer or site, job statuses, the scheduled task -> status -> per-device details drill-down, and the safety rules for direct-support task execution.

N-central org units: the service organization -> customer -> site hierarchy, the org-unit vs customer distinction, agent registration tokens (credential-sensitive), and custom properties at both org and device level.

NetSuite MCP fundamentals for this plugin: OAuth 2.0 Client Credentials (JWT-bearer) machine-to-machine auth brokered through Conduit, the per-tenant vendor-hosted MCP endpoint model, generic error handling, and how NetSuite's own role-based permissions — not this plugin — enforce the read-only posture.

Retrieving individual NetSuite records by type and internal ID, and discovering a record type's available fields via record-type metadata. Read-only — retrieving existing records, not creating or updating them.

Running NetSuite's standard and custom reports and saved searches, plus the filter-lookup helpers (accounting books, accounting contexts, nexuses, subsidiaries) many of them need. Read-only — running existing reports and searches, not building or editing them.

Running read-only SuiteQL queries against NetSuite data and discovering queryable fields and joins via SuiteQL metadata. The flexible ad-hoc query surface for questions no existing report or saved search already answers.

NinjaOne alerts and the conditions behind them: retrieving device alerts, dismissing individual alerts and bulk resets, alert summaries, severity and priority levels, common hardware/service/security/connectivity alert types and thresholds, alert webhooks, and triage workflows.

NinjaOne Public API fundamentals shared by every other NinjaOne skill: regional base URLs, OAuth 2.0 client-credentials auth and scopes, request shapes, cursor-based pagination, rate-limit headers and 429 handling, HTTP status codes and error response format, and webhook configuration.

NinjaOne device management: device details and updates, Windows service control, inventory, maintenance windows, reboot modes, and health-check workflows for Windows, Mac, and Linux endpoints running the NinjaRMM agent.

NinjaOne organizations — the top-level container for devices, representing MSP clients: creation and listing, locations, node approval modes, policy mappings and node role IDs, custom fields, tags, cursor pagination, and error codes.