powmcp.com

Use caption_check when the user supplies one caption file (WebVTT .vtt, SRT .srt, or TTML/IMSC .ttml/.xml), attached natively in chat or as a public URL, and asks whether the file is valid, conformant, clean, or ready to deliver, or whether its reading speed passes a platform gate. Use caption_compare only when the user supplies exactly two caption files, attached or as public URLs, and asks how they differ, such as an original versus a translated track or before versus after a fix. Pass an attached file through the file parameter (files for caption_compare); never ask the user to host an attached file publicly. These tools fetch and parse the source file and judge structural conformance, timing, encoding, and CPS against a named profile; they do not judge translation quality, transcription accuracy, or synchronization against the actual video. The app detects format by content, so an arbitrary XML or text file that is not a caption track returns an explicit unsupported-format error. Calls fetch and parse a live file and can take up to 60 seconds on a full-length track; tell the user before the call. Lead with the file-check pass/fail result and the named profile, detected format and encoding, and the most severe evidenced issue (for example an overlapping cue or a CPS breach), then summarize spec errors, timing findings, line length, the named reading-speed profile used, and truncation. Distinguish specification errors from readability thresholds: under an advisory profile, a failed readability threshold is not a specification violation or a platform rejection. Never repeat any query string from the file URL in narration.

Use ebook_check when the user supplies one EPUB (a publicly fetchable URL or a file attached in the conversation) and asks whether the EPUB has specification problems, including problems that may explain a store-upload rejection. A rejection citing accessibility, WCAG or accessibility metadata belongs to Ebook Accessibility Check; EPUBCheck does not predict bookstore acceptance. Use ebook_compare only when the user supplies exactly two EPUB builds (two public URLs or two attached files) and asks what changed between builds, whether a re-export regressed, or which build has fewer machine-checkable problems. Pass attachments through the file parameter (files for ebook_compare), never as URLs, give each tool exactly one source kind per call, and never ask the user to host an attached file publicly. These tools fetch the source artifact and run the official EPUBCheck engine; they do not render the book in a reading system, judge accessibility (that is the sibling Ebook Accessibility Check), or predict a specific distributor's extra metadata rules. A single check or two-build comparison can take up to 110 seconds, bounded by the existing call deadline; tell the user before the call. Lead with pass/fail, EPUB version, and the most severe rule finding, then summarize error/warning counts, structural inventory, and truncation. When ebook_compare reports no evidenced winner, say that plainly instead of naming a better build, and when it reports that the two files declare different titles, surface that before any regression talk. Never repeat EPUB URL query strings, attachment download-URL tokens, or credentials in narration.

Give ssl_check a URL and it opens its own TLS handshakes to that host at the URL's explicit port, or port 443 when none is named. It never loads the page. An http-scheme input reports only that the caller submitted HTTP and whether TLS answers on the probed port; it does not establish whether plain HTTP is served or redirected. Measured wall time is 0.05-1.5 seconds against real hosts, and a stalling server is cut off at 12 seconds per probe. Route here for the padlock and the certificate: 'is my SSL working', 'why does the browser say Not Secure', an expired or soon-to-expire certificate, a warning that names the wrong hostname, a renewal someone wants confirmed, or a question about which TLS versions a server still accepts. Be precise about what comes back. The probe establishes two things and only two: the protocol versions the server agrees to speak, and the certificate it serves (subject, issuer, the hostnames it covers, and the dates it was issued and expires). The grade in the result is this app's own reading of protocol support alone; it is not a Qualys SSL Labs grade. The probe does not build or verify the full chain of trust, does not check revocation, and does not inspect cipher suites, so a clean reading here is not a promise that every browser will trust the site. One more limit worth stating when it bites: the probe opens handshakes to one resolved endpoint, so on an anycast or load-balanced host it reports the certificate that one node served. A renewal that has only partially rolled out can still read clean. Say so whenever the user's question turns on trust rather than configuration. This app knows nothing about the rest of the site. Send protection-header questions (Content-Security-Policy, HSTS, X-Frame-Options) to Security Headers Check, JavaScript libraries carrying known published vulnerabilities to JS Vulnerability Check, third-party trackers and cookies to Site Privacy Scan, and page load time to Website Speed Test. Nothing in this suite builds a trust chain or checks revocation, so when that is the real question, say plainly that it is outside what these tools measure. Lead the answer with whether anything is wrong, then the certificate (who issued it, what it covers, when it was issued and when it expires), then the protocol list.