Claude Skills by WYRE-AI

3CX's native PBX MCP server: the per-PBX endpoint shape (every PBX is its own FQDN and its own OAuth authorization server — there is no shared mcp.3cx.com), the Admin Console + client setup flow, the permission model (fully inherited from the 3CX account that approved the connection), and how to discover the live tool surface since 3CX has not published exact tool-name strings.

3CX's live-operations surface: read-only visibility into active calls, recordings, voicemail, department and queue membership, and forwarding/presence profiles, plus the write actions that change live call routing — dropping a call, switching a profile, and logging a queue agent in or out.

3CX's read-only directory surface: resolving a caller by email or by exact extension, searching the PBX's own phonebooks, searching contacts synced from an integrated CRM, and listing PBX users/extensions.

3CX's system-and-configuration surface: server time, PBX event log and application log search, service status, database schema and the read-only SELECT-only Query tool, DIDs, IP and phone blocklists, SIP trunks, call flow apps, and the configuration write/delete actions that change what calls the PBX accepts or how they route.

[What this skill covers — the domain knowledge inside: entities, API surface, workflows, gotchas. One clear statement of coverage; do not restate the trigger conditions from when_to_use.]

Abnormal Security REST API fundamentals: Bearer token authentication, base URLs, rate limiting, pagination, OData filtering, request/response formats, and error handling.

Abnormal Security abuse mailbox cases: user-reported email submissions, case statuses and judgments, the case lifecycle, bulk and remediation actions, and phishing simulation handling.

Abnormal Security message analysis: message retrieval, email header inspection, attachments, sender reputation, delivery context, and SPF/DKIM/DMARC authentication results.

Abnormal Security threat detection: threat types (BEC, phishing, malware, socially-engineered attacks, spam, graymail, credential theft), attack vectors, severity assessment, remediation actions, and investigation workflows.

Alternative Payments API fundamentals: OAuth2 client-credentials token minting and bearer auth, scopes, REST endpoint structure, cursor pagination, the 5 req/sec rate limit, idempotency, error handling, and the read + safe-write capability posture that deliberately excludes direct payment creation.

Alternative Payments customers and their users: customer fields and status, the customer/user relationship, MSP client onboarding, and the destructive archive operation that requires confirmation.

Alternative Payments invoices and hosted payment requests: invoice status and line-item fields, hosted payment links and signed PDF links, archiving, and payment-request creation and retrieval. Hosted links let the customer choose to pay; the integration never moves money on the customer's behalf.

Alternative Payments transactions and payouts: transaction types, statuses, and the customer/invoice/payment-method filters; payout objects and the transactions that compose them for reconciliation. A read-only surface -- there is no create-payment or direct-charge operation.

End-of-life versus end-of-support risk for devices, OS versions, and firmware: combining RMM inventory (make, model, OS version, firmware) with general lifecycle knowledge, the mandatory verify-against-vendor-lifecycle caveat, what qualifies as a finding versus merely "old", and criticality-first prioritization of the resulting risk list.

Forward-looking hardware refresh planning: combining warranty expiration, EOL/EOS timing, and device age from whatever RMM and documentation platforms are connected into replace-now / plan-this-year / monitor tiers, laying those tiers onto a dated calendar, surfacing replacement clusters, and keeping an explicit insufficient-data bucket. Planning only — not quoting or procurement.

Endpoint hardware warranty status across whatever RMM platforms (Datto RMM, NinjaOne, N-central, Kaseya VSA, ConnectWise Automate, Atera, SuperOps, Syncro, Action1, ImmyBot) and documentation tools (IT Glue, Hudu) are connected: the reliability spread between OEM-resolved and hand-entered warranty fields, serial/asset-tag cross-referencing when RMM data is missing or stale, and the expired / expiring-soon / covered / unknown bucketing.

Atera RMM agents: agent records and fields, online/offline status, endpoint search and monitoring, PowerShell and script execution, and agent lifecycle.

Atera alerts: alert types, severity levels, alert sources, the acknowledge/resolve lifecycle, and alert-to-ticket conversion.

Atera REST API fundamentals: X-API-KEY header authentication, OData-style pagination, the 700 requests/minute rate limit, endpoint conventions, and error handling.

Atera customers and contacts: customer records and fields, contact management, custom fields, and customer lifecycle operations.

Atera device monitors: HTTP, SNMP, and TCP monitor types for network devices, services, and applications, plus monitor configuration, thresholds, and polling behavior.

Atera service desk tickets: ticket fields, statuses, priorities, comments, work hours, and billing duration.

Auvik alerts: severity tiers, status lifecycle, dismissal semantics, and the common alertName patterns that show up in MSP NOC queues.

Auvik MCP fundamentals: the JSON:API envelope shape, basic-auth credential model, region routing, cursor-based pagination, rate-limit handling, and the v1 vs v2 device API distinction.

Auvik device records: device types, manageStatus and onlineStatus, lifecycle and warranty fields, and choosing between the v1 list endpoint and the detailed device endpoints.

Auvik network and interface entities: the network entity model, IP-range scoping, interface-to-device relationships, and adminStatus vs operStatus.

Phishing-simulation campaign analysis: click-rate trend direction across campaigns, repeat-clicker identification with remedial-training cross-reference, and optional enrichment that correlates simulated failures with real-world phishing incidents from a connected email-security tool as a compounding risk signal.

Explainable per-user and per-org human risk scoring from training-completion status, phishing-simulation failure history, and optional real-world click/attack-targeting signal: the weighted factor table, three-tier bucketing, per-org rollup as a distribution rather than a blended number, and graceful degradation when only some inputs are connected.

Security-awareness training completion across whatever training/awareness platform is connected: assignment-overdue versus cadence-overdue detection, per-campaign and per-org completion-rate calculation, ranking clients that have fallen behind a contracted cadence, and the unmeasured-versus-0% distinction.

Axcient x360Recover API and MCP fundamentals: x-api-key header authentication, the single production base URL, the full 20-tool MCP catalog by domain, why most list endpoints return bare arrays with no pagination, and the five distinct error response shapes the upstream API actually returns.

Axcient x360Recover appliances: the physical/virtual hardware running local backups, its device roster, and the org-wide vs client-scoped list tools.

Axcient x360Recover clients: the health_status model, client_code, the three-way protected-system counter breakdown (appliance_based, d2c, cloud_archive), and minting direct-to-cloud agent enrollment tokens.

Axcient x360Recover protected devices (servers and workstations): SERVER/WORKSTATION typing, the current/previous health-status model, local vs vault vs cloud usage and recovery-point timestamps, AutoVerify screenshot verification, and restore points.

Axcient x360Recover backup jobs: the BRC vs Replibit job-type split, per-job protection thresholds, and job run history with its starttime_begin pagination floor.

Axcient x360Recover vaults: Private vs Cloud vault types, storage capacity, and the connectivity-loss alert threshold — including axcient_set_vault_threshold, the one tool in this plugin that changes alerting configuration rather than just reading it.

Onboarding the azure-mcp connector in the WYRE MCP Gateway: Azure service-principal registration, the tenantId/clientId/clientSecret triple, least-privilege Reader-tier RBAC assignments, the gateway's read-only namespace allowlist, and connection verification and failure modes (expired secret, missing role assignment).

The read-only cost and capacity half of the azure-mcp connector — the pricing, quota, subscription, and group namespaces: retail meter-rate lookups, quota and usage headroom, subscription and resource-group inventory, and the retail-versus- actual-billing distinction that shapes every estimate.

The read-only observability half of the azure-mcp connector — the monitor, resourcehealth, applens, and advisor namespaces: Azure Monitor metrics, Log Analytics KQL, alert-rule state, platform health states, AppLens detectors, and Advisor recommendation categories, plus the degraded-resource investigation order.

Portfolio-wide backup job health across whatever BCDR and SaaS-backup tools are connected: the two structurally different job models (image-based appliance backup vs. SaaS-data snapshot backup) and how to normalize them into one health record per protected unit, why a live consecutive-failure streak matters more than a trailing success rate, the missed-versus-failed distinction and its different root causes, and the two storage-trending risk patterns (approaching capacity, anomalous growth).

Whether a backup is actually recoverable rather than merely present: the ranked hierarchy of restore evidence (actual restore performed, full boot/virtualization verification, screenshot verification, spot-check restore drill, no evidence at all), adequate test cadence per data-criticality tier, and why a never-tested backup is the highest-priority finding — outranking even an actively failing job.

Comparing configured backup retention and cadence against contracted retention windows and RPO (recovery point objective) targets: the two distinct retention gap types (configured-shorter-than-contracted vs. storage-forced truncation), why achievable RPO must be derived from actual job success history rather than the nominal schedule, where the contracted side of the comparison actually lives, and why "no documented requirement" is its own finding rather than an automatic pass.

Better Stack MCP and API surface across Uptime, Telemetry (Logtail), and Error Tracking: available tools, Bearer token authentication, API structure, cursor-based pagination, rate limiting, and error handling.

Better Stack incidents: incident records raised by uptime monitors or reported manually, and the triage, acknowledgment, and resolution lifecycle.

Better Stack log management (Logtail): log sources, structured log search and query syntax, log-based alerting, and log analysis workflows.

Better Stack uptime monitors: check types, monitor fields, heartbeat monitors, monitor groups, and create/update/pause/delete operations.

Better Stack on-call: on-call calendars and rotations, escalation and notification policies, alert routing, and determining who is currently on call.

Better Stack status pages: status page configuration, resources and components, maintenance windows, and public service-status communication.

Blackpoint Cyber (CompassOne) MCP fundamentals: API-token header auth and its internal Bearer forwarding, the partner-tenant-asset hierarchy, navigation tools, which tool domains are functional versus stubbed, pagination, and HTTP error causes.

Blackpoint Cyber (CompassOne) asset data: the six asset classes, listing and paginating assets per class, cross-class search, asset detail, and walking parent/child/sibling relationships to build a blast-radius or topology view.

Blackpoint Cyber (CompassOne) detection investigation: the read-only tool surface across tenants, assets, detections, and vulnerabilities, the tenant → asset → detection → vulnerability drill-down, asset relationship maps, dark-web and external-exposure cross-references, and which tool domains are stubs.