Smart API Connector
Security checks across static analysis, malware telemetry, and agentic risk
Overview
This is a transparent instruction-only API helper, but it can use user-provided API keys and make approved write/delete API calls.
This skill appears reasonable if you need a generic API helper. Before use, provide only scoped credentials, check every request preview, and require explicit approval for POST, PUT, DELETE, or any curl fallback.
Static analysis
No static analysis findings were reported for this release.
VirusTotal
VirusTotal engine telemetry is currently stale for this artifact.
Risk analysis
Artifact-based informational review of SKILL.md, metadata, install specs, static scan signals, and capability signals. ClawScan does not execute the skill or run runtime probes.
An API key could let the agent read or change data in the connected service if the user authorizes those requests.
The skill is designed to use API keys or authentication headers supplied by the user, so it may act with those account privileges.
web_fetch url --headers '{"Authorization": "Bearer KEY", "X-API-Key": "KEY"}'Use scoped or test keys where possible, avoid production/admin tokens unless needed, and verify the request before sharing credentials.
If approved against a real service, API requests may modify or remove remote data.
The documented methods include operations that can create, update, or delete data on external services; the same document also requires confirmation for POST/PUT/DELETE.
| POST | Create data / send JSON body | | PUT | Update data | | DELETE | Remove data |
Review the URL, method, headers, and JSON body before approving non-GET calls; prefer test environments for destructive operations.
A fallback request may run a local command and rely on local shell/curl behavior instead of only the built-in fetch tool.
Although the skill is presented as using built-in tools, it documents a possible local exec/curl fallback for API calls. This is purpose-aligned but should not be treated as purely web_fetch-only.
2. **Fall back to exec/curl** only if web_fetch can't handle the request
Prefer web_fetch; only allow exec/curl fallback when necessary and after reviewing the command, especially if it includes credentials.
