Http connectivity verification
Curated, evidence-grounded skill and software-tool collections for scientific AI agents, generated by the AgenticScienceBuilder
npx -y skills add HolobiomicsLab/asb-skill-collections --skill http-connectivity-verificationAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 14 stars14 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Use when you need to confirm that a documented web service URL is live and reachable before attempting to submit analysis jobs, download results, or integrate the service into an automated pipeline. Use it as a prerequisite check when the service documentation claims academic or public availability.
The file declares its own license as CC-BY-4.0. That is the author’s claim about this one file, and it is not the same thing as the license GitHub reports for the repository, which is listed with the other numbers below.
SKILL.md
5.4 KB, 935 tokens by cl100k_base, as published. Nobody here has run it
http-connectivity-verification
Summary
Verify that a scientific web service or API endpoint is deployed, accessible, and responding with expected HTTP status codes. This skill validates service availability before downstream analysis tasks depend on it.
When to use
Apply this skill when you need to confirm that a documented web service URL is live and reachable before attempting to submit analysis jobs, download results, or integrate the service into an automated pipeline. Use it as a prerequisite check when the service documentation claims academic or public availability.
When NOT to use
- The service URL is not yet documented or is under embargo — verify publication status first.
- You only need to check whether a static file (e.g., GitHub README, published dataset) exists — use standard file-based checks instead.
- The endpoint requires authentication and you do not have valid credentials — extend the skill to include credential submission before status validation.
Inputs
- Service URL (string; e.g., https://metabologenomic.cbd.cs.cmu.edu/)
- HTTP method (GET; optional timeout threshold in seconds)
Outputs
- HTTP status code (integer; 2xx/3xx/4xx/5xx)
- Response headers (dictionary)
- Request latency (milliseconds)
- Timestamp of check (ISO 8601)
- Deployment-check report (structured log or JSON)
How to apply
Send an HTTP GET request to the documented service URL using a standard HTTP client (curl, requests library, etc.). Capture the HTTP response status code, response headers, and request latency. Verify that the status code falls in the 2xx success range (typically 200 OK). Log the response metadata (timestamp, latency, content-type) and compare against known-good baseline responses to detect degradation. Document the results in a deployment-check report for audit and troubleshooting.
Related tools
- molDiscovery (Academic web service for metabologenomic analysis whose availability and response status is being verified) — https://github.com/mohimanilab/molDiscovery
Examples
curl -w '\nStatus: %{http_code}\nLatency: %{time_total}s\n' -o /dev/null -s https://metabologenomic.cbd.cs.cmu.edu/
Evaluation signals
- HTTP status code is 200 or other 2xx success code; non-2xx codes (4xx, 5xx) indicate service unavailable or misconfigured endpoint.
- Response latency is below documented or expected threshold (e.g., <5 seconds); unusually high latency may signal network or server degradation.
- Content-Type header is present and matches expected type (e.g., 'text/html', 'application/json'); missing or unexpected content-type may indicate server misconfiguration.
- Repeated checks over time show consistent 2xx responses; sporadic 5xx responses may indicate transient outages.
- Deployment-check report is generated with timestamp and logged to persistent storage for audit trail and trend analysis.
Limitations
- HTTP GET checks only verify basic reachability; they do not validate that the service's functional endpoints or computational methods are working correctly.
- A 200 status code does not guarantee the service will accept job submissions or return correct results; functional testing requires end-to-end workflow validation.
- Network timeouts, DNS failures, or firewalls may block access from specific geographic regions or networks, limiting the generalizability of a single check.
- Some services may require specific headers or authentication tokens; a bare GET may succeed but masked API endpoints may require additional verification.
Evidence
- [other] Is the molDiscovery academic web service deployed and accessible at the documented URL?: "Is the molDiscovery academic web service deployed and accessible at the documented URL?"
- [other] Send HTTP GET request to https://metabologenomic.cbd.cs.cmu.edu/ using curl or standard HTTP client. Capture HTTP response status code and response headers. Verify HTTP status code is 200 or other success code (2xx range). Log response metadata (timestamp, latency, content-type) and save to deployment-check report.: "Send HTTP GET request to https://metabologenomic.cbd.cs.cmu.edu/ using curl or standard HTTP client. Capture HTTP response status code and response headers. Verify HTTP status code is 200 or other"
- [readme] To test molDiscovery for academic users, please visit : https://metabologenomic.cbd.cs.cmu.edu/: "To test molDiscovery for academic users, please visit : https://metabologenomic.cbd.cs.cmu.edu/"
What ships with it
Read from the repository
Just SKILL.md. No reference files, no scripts.