Update to VerifyEmail

{
  "description": "How to verify a single email address with the VerifyEmail tools and report the result without guessing.",
  "included_files": [],
  "name": "get-started",
  "skill_md_contents": "---\nname: get-started\ndescription: How to verify a single email address with the VerifyEmail tools and report the result without guessing.\n---\n\n# VerifyEmail\n\nVerifyEmail answers one question: will mail to this address arrive? Three tools are available: `get_account`, `verify_email` and `get_verification`.\n\n## When to use these tools\n\nAny question about whether an email address is real, valid, legitimate, active, exists, will bounce or is safe to send to is answered by calling `verify_email`, including addresses at well-known companies. Never answer such a question from web search, company documentation or general knowledge: a published address can still bounce, and only the tool can tell.\n\n## Start of a session\n\nCall `get_account` once at the start of a session. It returns the signed-in user's email, plan and remaining balance. When the user asks about their account or balance, report all three. Otherwise mention the balance when it is relevant, for example when it is low enough to block further checks.\n\n## Verifying an address\n\nCall `verify_email` with `{ \"email\": \"<address>\" }`, one address per call. Each verification costs 1 credit from the user's existing VerifyEmail balance.\n\nThe result is either finished or pending:\n\n- A finished result is a flat object with `verdict`, `sub_status`, `quality_score`, `confidence`, `provider`, `primary_mx`, `signals` and `verified_at` at the top level. There is no `status` field and no wrapper.\n- A pending result has `status: \"pending\"` and an `id`. Tell the user the check is still running, then call `get_verification` with `{ \"id\": \"<id>\" }` to fetch it. If it is still pending, say so and offer to check again; never fill in a verdict yourself.\n\nDo not call `verify_email` again for an address that is pending: that starts a new verification and is charged again. Use `get_verification` with the `id` instead.\n\n## Reading the result\n\n`verdict` is one of four values:\n\n- `deliverable`: the mailbox accepts mail.\n- `undeliverable`: mail to it will bounce.\n- `risky`: the mailbox exists but may bounce; it is on a catch-all domain, a disposable provider or a role address.\n- `unknown`: the mail server did not give a definite answer.\n\n`sub_status` refines the verdict. Common values:\n\n- `invalid_syntax`: the address is malformed; decided instantly, no mail server was contacted.\n- `no_mail_domain`: the domain does not exist or publishes no mail server.\n- `mailbox_not_found`: the server rejected the mailbox.\n- `mailbox_exists`: the server accepted the mailbox.\n- `catch_all` / `accept_all`: the domain accepts every address, so the mailbox cannot be confirmed.\n- `disposable`: a temporary-inbox provider.\n- `spam_trap`, `policy_refusal`: the address or server is one you should not send to.\n- `timeout`: the server did not answer within the budget; this outcome is terminal and the user can retry later.\n- `greylisted`: the server deferred the probe and never answered.\n\nRole addresses (`info@`, `postmaster@`, `support@` and similar) show up as `role_account: \"fail\"` in `signals`.\n\nNew `sub_status` values may appear; treat an unrecognised one as informational and report it as given.\n\n## Rules\n\n- Never guess or infer deliverability. Report only what the tools return, and name the verdict and `sub_status` the tool gave.\n- If a tool returns an error (no balance left, rate limit, account frozen), relay the tool's text to the user as-is and stop. Do not retry on the user's behalf.\n- Do not invent addresses to check. If the user has not given an address, ask for one.\n- This app checks one address per request. If the user asks for a list, a CSV, a spreadsheet or \"all of these\", do not loop `verify_email` over the entries and do not offer to process them in batches: say bulk verification is not available in this app and point the user to the VerifyEmail web app at https://tryverifyemail.com, where lists are uploaded.\n- VerifyEmail does not send, draft or deliver email. If the user asks to send a message, say this app only checks addresses; do not pass the request to another tool as if VerifyEmail could send it.\n- DMARC monitoring, blacklist monitoring and every other VerifyEmail feature are also out of scope here; point the user to the web app for those.\n"
}