Zoom Manager
v0.1.0Manage Zoom meetings via OAuth API. Create, list, delete, and update events.
⭐ 1· 1.9k·1 current·1 all-time
byVladimir@vnagin
MIT-0
Download zip
LicenseMIT-0 · Free to use, modify, and redistribute. No attribution required.
Security Scan
OpenClaw
Suspicious
medium confidencePurpose & Capability
The stated purpose (manage Zoom via Server-to-Server OAuth) matches the code which calls Zoom REST endpoints. Requesting Zoom client ID/secret/account ID is reasonable for that purpose. However, metadata and runtime behavior are inconsistent: SKILL.md metadata lists required Node binary and secrets, the registry shows no required env vars, and many scripts expect a local config.json rather than environment variables. The inclusion of both Node and Python scripts (and differing config approaches) is over-broad for a single, simple CLI skill and suggests packaging/maintenance issues.
Instruction Scope
SKILL.md instructs setting ZOOM_CLIENT_ID, ZOOM_CLIENT_SECRET, and ZOOM_ACCOUNT_ID env vars and running node zoom-cli.js. Many provided scripts (JS and Python) instead read a config.json in the repository parent directory for client_id/client_secret/account_id/user_id. That mismatch means agents or users following the SKILL.md instructions may have credentials ignored or duplicated into disk files. All network calls are to Zoom's API endpoints (no obvious exfiltration), but the instructions are inconsistent about where secrets live and which scripts are canonical.
Install Mechanism
No install spec — the skill is instruction/code-only, so nothing is downloaded at install time. That lowers supply-chain risk. All code is bundled in the skill payload rather than fetched from external URLs.
Credentials
Requesting Zoom OAuth credentials is appropriate for a Zoom manager. But the skill inconsistently documents and implements credential handling: SKILL.md metadata declares secrets (ZOOM_CLIENT_ID, ZOOM_CLIENT_SECRET, ZOOM_ACCOUNT_ID) while registry metadata lists none; zoom-cli.js reads env vars, while many other scripts require config.json with client_id/client_secret/account_id/user_id. This encourages storing sensitive credentials in a file (config.json) in the repository, increasing exposure risk. There is also an optional ZOOM_USER_ID in code not documented consistently. Verify where credentials will actually be stored and used before providing them.
Persistence & Privilege
always is false and the skill does not request any platform-wide persistence or special privileges. It does not attempt to modify other skills or agent settings.
What to consider before installing
This skill likely does what it claims (talks to Zoom's REST API) but has packaging and documentation mismatches that could expose credentials or cause runtime errors. Before installing or running it: 1) Ask the publisher which script is canonical (zoom-cli.js vs the per-action scripts) and whether credentials should be provided via environment variables or a config.json. 2) Prefer keeping secrets in environment variables (not stored in config.json on disk); if a config file is required, store it securely and restrict file permissions. 3) Review and fix the JS bugs (e.g., delete_meeting.js tries to use a fetch 'auth' option instead of an Authorization header). 4) Run the code in an isolated environment with least-privilege Zoom credentials (create a dedicated Server-to-Server OAuth app with only required scopes and use a non-production account). 5) Because the skill owner/source is unknown, treat credentials cautiously — do not reuse high-privilege production credentials until you confirm the packaging and credential storage behavior.Like a lobster shell, security has layers — review code before you run it.
latestvk97farnkckdskv680wewr2cjxd804hn8meetingvk97farnkckdskv680wewr2cjxd804hn8zoomvk97farnkckdskv680wewr2cjxd804hn8
License
MIT-0
Free to use, modify, and redistribute. No attribution required.
Runtime requirements
📹 Clawdis
Binsnode