api-patterns
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),…
Drafting tool-verified answers to cyber-insurance renewal, new-business, and underwriter security questionnaires: the standard recurring question set (MFA everywhere including privileged accounts, EDR coverage ratio, tested and immutable backups, documented and tested IR plan,
$ npx -y skills add wyre-technology/msp-claude-plugins --skill insurance-questionnaires --agent claude-codeHow it fires
How this skill gets triggered: by you, by Claude, or both.
/insurance-questionnairesContext preview
The summary Claude sees to decide when to auto-load this skill.
Drafting tool-verified answers to cyber-insurance renewal, new-business, and underwriter security questionnaires: the standard recurring question set (MFA everywhere including privileged accounts, EDR coverage ratio, tested and immutable backups, documented and tested IR plan,
name: "Cyber Insurance Questionnaires" description: > Drafting tool-verified answers to cyber-insurance renewal, new-business, and underwriter security questionnaires: the standard recurring question set (MFA everywhere including privileged accounts, EDR coverage ratio, tested and immutable backups, documented and tested IR plan, security awareness training), which connected tools actually answer each one, and the evidence-backed / documented-only / unable-to-verify labeling discipline that keeps an answer defensible during a claim investigation. when_to_use: >- When answering or drafting responses to a cyber-insurance questionnaire, renewal application, or underwriter security questionnaire for a client. Use when: insurance questionnaire, cyber insurance form, security questionnaire, underwriter questions, insurance renewal, fill out insurance application, cyber policy renewal, what's our MFA coverage for insurance.
Cyber-insurance underwriters ask a fairly repetitive set of questions across carriers, because the same handful of controls (MFA, EDR, backup integrity, incident response readiness, security awareness training) drive the overwhelming majority of claims. The recurring failure mode in how these get answered is not malice — it's that whoever fills out the form is often answering from general impression ("yeah, we've got MFA everywhere") rather than a live query, and a policy gets bound or renewed on an answer that turns out to be wrong when a claim is filed. A wrong answer on a bound policy can be grounds for denial of a claim. This skill exists to replace impression-based answers with tool-verified ones, and to make "we can't verify this" a normal, expected answer rather than something to paper over.
Pull `cipp__list_mfa_users` for per-user registration/enforcement state and `cipp__list_conditional_access_policies` for policy-level enforcement (conditional access scoped to "All users" is a stronger answer than per-user MFA alone — say which mechanism is in place). Cross-check privileged accounts specifically via `cipp__list_gdap_roles` / admin role assignments — underwriters increasingly ask about admin/privileged accounts as a distinct sub-question. Answer with the actual coverage percentage and any known exceptions (service accounts, break-glass accounts), not a flat yes/no.
Pull agent/device counts from whichever EDR/MDR connector is present (Huntress, SentinelOne, RocketCyber, or similar — check via `conduit__search_tools`). Compare deployment count against the client's known device inventory (RMM device count, or Liongard `liongard__inventory_devices` if RMM isn't connected) to state coverage as a fraction, not just "yes, deployed." A vendor being "connected" is not the same as 100% of endpoints having an active agent — report the actual ratio.
This is the hardest question in the standard set to answer with high confidence from this pack's core grounding (CIPP/Liongard/IT Glue), because backup platforms are not always gateway-connected as a distinct vendor. Approach in this order: (1) check `conduit__search_tools` for a connected backup or RMM-integrated backup tool and pull job/test-restore history directly if one exists; (2) if Liongard has an inspector configured against the client's backup platform, `liongard__systems_list` / `liongard__inspections_run` may surface job status as part of its general system inspection — check before assuming it's unavailable; (3) fall back to IT Glue/Hudu documentation (`itglue__search_documents` for a backup/DR runbook or test-restore log) — but label this as documented evidence only, not verified testing, per the evidence-mapping skill's configured-vs-documented distinction. If none of these resolve it, flag the question as unable to verify and recommend the MSP confirm manually before the form is submitted.
Two sub-claims here, answer them separately. "Documented": search IT Glue/Hudu for an incident response plan document (`itglue__search_documents`) — if found, cite it with last-updated date (a plan last touched three years ago is a weaker answer than one updated this year, say so). "Tested": this pack has no direct evidence source for tabletop exercises or IR drills unless they're logged as a document or PSA ticket — treat "tested" as unable to verify unless explicit evidence exists, and do not infer testing from the plan's mere existence.
There is no security-awareness-training vendor connector grounded in this pack's core tool surface (CIPP/Liongard/IT Glue do not carry this data). Check `conduit__search_tools` in case a training platform is connected for this client; if not, this question should be flagged as unable to verify from tool evidence, with a note to check IT Glue for a training-program document as documented-only evidence, and a recommendation that the MSP confirm the current state directly with whatever training platform (if any) is actually in use.
One command to supercharge Claude Code for MSP workflows. Then restart Claude Code. That's it. Documentation: mcp.wyre.ai
Repo: wyre-technology/msp-claude-plugins
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),…
3CX's live-operations surface: read-only visibility into active calls, recordings, voicemail, department and queue membership, and forwarding/presence…
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…
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…
Abnormal Security abuse mailbox cases: user-reported email submissions, case statuses and judgments, the case lifecycle, bulk and remediation actions, and…
Abnormal Security message analysis: message retrieval, email header inspection, attachments, sender reputation, delivery context, and SPF/DKIM/DMARC…