Adguard

v0.1.0

Control AdGuard Home DNS filtering via HTTP API. Use when managing blocklists/allowlists, checking domain filtering status, toggling protection, or clearing DNS cache. Supports blocking/allowing domains, viewing statistics, and protecting/disabling DNS filtering.

5· 2.6k·6 current·6 all-time
byAlex Buchan@rowbotik
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
VirusTotalVirusTotal
Benign
View report →
OpenClawOpenClaw
Suspicious
medium confidence
!
Purpose & Capability
The name/description (AdGuard Home controller) align with the code and SKILL.md: the script talks to AdGuard's HTTP API and performs expected actions (check, block, allow, status, toggle, clear cache). However, the registry metadata declares no required environment variables or primary credential, while both SKILL.md and scripts clearly require ADGUARD_PASSWORD (and optionally ADGUARD_URL and ADGUARD_USERNAME). This mismatch is an inconsistency in the package metadata.
Instruction Scope
SKILL.md instructs the agent/user to authenticate to a local AdGuard Home instance and to use curl and the provided script; runtime actions (login, set_rules, status, cache_clear) are within scope. It suggests network discovery methods (nmap, router admin) which are optional guidance but not required by the script itself. The instructions do direct storage of ADGUARD_PASSWORD in an env var and advise adding it to shell rc — this is expected for the tool but has security implications the user should consider.
Install Mechanism
No install spec; this is an instruction-only skill with an included shell script. Nothing is downloaded from external URLs and no archive extraction occurs, which is lower risk.
!
Credentials
The tool legitimately requires an admin password and optionally URL/username to contact AdGuard Home. Those credentials are proportionate to the stated functionality. However, the registry claims no required env vars/credentials while the script enforces ADGUARD_PASSWORD — a metadata omission. The script stores a session cookie in /tmp (ephemeral) and does not transmit credentials to external hosts beyond the configured ADGUARD_URL; still, ADGUARD_PASSWORD is sensitive and the SKILL.md recommends putting it in shell rc which may expose it in some setups.
Persistence & Privilege
The skill does not request permanent/global agent privileges: always is false, it does not modify other skills, and it only writes a temporary cookie file in /tmp which is cleaned up on exit. No evidence of elevated or persistent system-wide changes.
What to consider before installing
This skill appears to implement an AdGuard Home controller and the shell script performs expected API calls (login, get status, set rules). However, the registry metadata omits required environment variables (ADGUARD_PASSWORD, ADGUARD_URL, ADGUARD_USERNAME) which the script actually needs — confirm this discrepancy before installing. Review the included scripts yourself (scripts/adguard.sh) to verify there is no network endpoint besides your configured ADGUARD_URL and to ensure credentials are only sent to your local AdGuard instance. Avoid storing the admin password in plain text in shell rc if possible; consider using the suggested ~/.adguard/config.json for non-password fields and provide the password interactively or via a secure secret store. If you don't control the AdGuard host or you cannot verify the source of this skill, test it on an isolated machine or device first. If you want higher assurance, ask the publisher to update the registry metadata to declare required env vars and to explain why any network-scanning suggestions (nmap) are present.

Like a lobster shell, security has layers — review code before you run it.

latestvk97bgnbyj0k83bz7e2b6tq77s18084m5

License

MIT-0
Free to use, modify, and redistribute. No attribution required.

Comments