Mcporter Skill Builder
PassAudited by VirusTotal on May 13, 2026.
Overview
Type: OpenClaw Skill Name: mcporter-skill-builder Version: 1.0.0 The mcporter-skill-builder bundle is a legitimate scaffolding tool designed to help an AI agent generate MCP (Model Context Protocol) skill bundles. It provides structured instructions in SKILL.md and various reference files for different authentication modes (OAuth, Bearer, etc.). The included shell scripts, such as init-mcporter.sh and verify-bundle.sh, are used for local credential management and bundle integrity checks. While the tool handles sensitive tokens and executes shell commands, its behavior is transparent, well-documented, and strictly aligned with the purpose of configuring the mcporter utility. No evidence of data exfiltration, malicious prompt injection, or unauthorized persistence was found.
Findings (0)
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.
If this is a real embedded secret, generated OAuth skills could expose or reuse credential material that does not belong in a public scaffold.
The static scan reports this line as an apparent hardcoded API secret or token inside the OAuth initialization template that is copied into generated OAuth skills.
client_secret: [REDACTED],
Inspect scripts/templates/init-mcporter.sh before installing or using this skill. Remove any literal secret, source client secrets only from declared env vars or secure provisioning, and rotate the exposed secret if it was real.
A compromised or untrusted MCP server could publish instructions that try to steer the agent beyond the user’s intended task.
Generated MCP wrapper skills tell the agent to rely on instructions returned by the live MCP server. This is normal MCP behavior, but those instructions come from a remote service and may be outside the user’s direct control.
The output includes the server's `Instructions:` field (read it) and a JSON Schema for every tool's parameters. Treat this as the authoritative reference for the rest of the session.
Use generated wrappers only with trusted MCP servers, and treat server-published instructions as subordinate to the user’s request and platform safety rules.
If the upstream MCP exposes write or administrative tools, the agent may be able to mutate third-party data using the configured credentials.
Generated skills expose the upstream MCP tool surface through mcporter. That is the point of the wrapper, but the actual tools and their side effects are determined by the upstream MCP.
This skill is a thin pass-through to the hosted MCP server at `<BASE_URL>`... `bash {baseDir}/scripts/invoke.sh call <SLUG>.<tool> <arg>=<value> ...`Review the live tool catalog with `list --schema`, understand which tools can change data, and require explicit user approval for high-impact calls.
A generated stdio wrapper can execute local MCP server code with the host user’s filesystem and network permissions.
Stdio-mode generated skills intentionally run local subprocess MCP servers, including package-runner commands.
mcporter spawns it as a subprocess on each call... Command `npx -y @vendor/foo` → `requires.bins: ["mcporter", "npx"]`.
Only scaffold stdio wrappers for trusted commands or packages, pin or verify package sources where possible, and avoid exposing unreviewed local MCP servers to the agent.
OAuth access relies on local persistent state; stale or improperly protected local state could affect future agent sessions.
OAuth-mode generated skills persist credential-related state in mcporter’s vault and a provisioning marker/hash under the skill directory.
The wrapper seeds mcporter's vault as needed before each call... Detects credential rotation by hashing the env-supplied OAuth client/refresh credential material and comparing against `${SKILL_DIR}/.provisioned`.Store generated OAuth skills in a protected workspace, limit access to the agent runtime environment, and document how to clear the mcporter vault and `.provisioned` state when revoking access.
A future package update or typosquatted MCP package could change what code runs locally.
Generated stdio wrappers may rely on package-runner installation paths for upstream MCP servers. This is disclosed and purpose-aligned, but package provenance and version pinning are left to the generated skill author.
For `npx -y <pkg>` and `uvx <pkg>` patterns, the package is identifiable from args.
Prefer trusted upstream packages, pin versions where practical, and include clear install metadata for generated stdio skills.