Skip to main content
Glama

Wizcom Limited

Check cyber insurance readiness

check_cyber_insurance_readiness
Read-onlyIdempotent

Score how ready a small business is for a cyber insurance application, from 12 yes/partly/no/unsure answers about MFA, EDR, updates, backups, training, payment call-backs, and incident planning. Returns a 0-100 readiness score, a band, and a prioritized list of gaps with fixes. Same scoring as https://wizcomltd.com/tools/cyber-insurance-readiness. Educational only: not insurance or legal advice, and Wizcom is not an insurance agency.

Input Schema

NameRequiredDescriptionDefault
edrYesDoes every computer and server have modern security software that watches for attacks and alerts someone?
eolYesIs everything still supported by its maker, with no old computers or software that no longer get security fixes?
irpYesDo you have a written plan for what to do if you're hacked, including who to call?
patchYesDo computers, software, and network equipment get security updates automatically or on a regular schedule?
backupYesDo you have a backup copy that hackers couldn't reach or delete, such as one kept offline or locked in the cloud?
restoreYesHave you actually restored files from your backup in the past year to prove it works?
paymentsYesBefore sending a wire or changing someone's bank details, do you call them at a phone number you already have? Use "na" if not applicable.
trainingYesDoes your team get cybersecurity training at least once a year, including practice phishing emails?
email_secYesDoes your email system screen out scam and phishing emails before they reach people?
mfa_adminYesDo your admin accounts, the ones that can add users or change settings, also need the second step?
mfa_emailYesDoes everyone need a second step, like a code or a tap on their phone, to log in to work email?
mfa_remoteYesWhen anyone logs in to your systems from outside the office, is that second step required? Use "na" if nobody logs in remotely.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish that this is a safe, read-only, idempotent, closed-world operation. The description adds meaningful context beyond them: the scoring is based on 12 answers, returns a 0-100 score, a band, and prioritized gaps with fixes, mirrors a public web tool, and is educational only. It stops short of covering minor behavioral details such as whether inputs are validated or how ties are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two compact sentences that front-load the action, inputs, and output, followed by a necessary disclaimer. Every sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

There is no output schema, but the description explains what is returned: a 0-100 score, a band, and a prioritized gap list. All 12 inputs are fully documented in the schema, and the safety profile is covered by annotations. Nothing essential is missing for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every one of the 12 parameters already has a clear question and enum. The description adds only a summary of the topic areas and the yes/partly/no/unsure answer scale, without explaining the meaning of each parameter beyond the schema. Baseline 3 is appropriate when the schema carries the detail.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Score how ready') and resource ('cyber insurance application'), and enumerates the 12 assessment areas. An agent can immediately distinguish it from estimate_downtime_cost, get_wizcom_info, and scan_ai_visibility.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives clear context that this is for small businesses preparing a cyber insurance application and sets the educational-use boundary. It does not explicitly name alternatives or exclusion cases, but the sibling tools serve unrelated purposes, so the intended use is unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources