Update to Fraud Blocker

{
  "description": "Use when the user asks to verify, validate, or check whether an email address is deliverable or valid with Fraud Blocker, or asks to interpret a Fraud Blocker email verification result.",
  "included_files": [],
  "name": "email-verification",
  "skill_md_contents": "---\nname: email-verification\ndescription: Use when the user asks to verify, validate, or check whether an email address is deliverable or valid with Fraud Blocker, or asks to interpret a Fraud Blocker email verification result.\n---\n\n# Fraud Blocker email verification\n\nUse the `verify_email` MCP tool when the user explicitly asks to verify or validate an email address.\n\n- Pass only the email address the user asked to verify.\n- Never invent or infer a verification result.\n- Explain the returned `status` and `sub_status` in plain language when useful.\n- Surface `did_you_mean` when present.\n- Mention `free_email`, `domain`, and `mx_found` only when they help answer the user's question.\n- If the response includes `usage`, report it when the user asks about remaining verification capacity or when a monthly-limit error occurs.\n- If the service returns `monthly_limit_reached`, explain that the connected Fraud Blocker account has reached its monthly email verification limit.\n- If authentication is required, ask the user to connect their Fraud Blocker account through the plugin's sign-in flow; never ask them to paste passwords, API keys, access tokens, refresh tokens, or Firebase tokens into chat.\n- Do not call verification merely to illustrate an example. A verification consumes the connected account's allowance.\n"
}