Menu
Agent Skill for calling MCP servers through MCPorter. Use when need to call MCP tools.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
Agent Skill for planning implementation work into comprehensive, testable steps. Use before implementation to create a clear roadmap for execution.
Agent Skill for writing and reviewing durable design specs. Use when the user asks to write, formalize, save, review, or approve a spec, design document, RFC, or implementation-ready proposal. If the direction is still vague or unsettled, use `brainstorming` first before producing the spec. If the direction is already clear and no spec is needed, use `plan`.
Agent Skill for spawning new AI agents with interactive TUI in tmux. Use when work can be offloaded to new or existing AI agents (exploration, code review, second opinions, parallel work, etc.). Can also be used if spawning new agents with different model families (e.g. Spawn GPT models when you are Claude Code, Spawn Claude models when you are Codex, Or spawn any other models (e.g. DeepSeek, Gemini) with Pi). Prefer harness's own subagent tools when no need for a different model.
Agent Skill for OpenCLI. Use when the user wants to control websites through the `opencli` CLI, run or inspect OpenCLI site/app/external adapters, use the OpenCLI browser bridge/CDP automation
Agent Skill for collaborative brainstorming and design exploration. Use when the user wants to think through an idea, compare options, clarify trade-offs, or get a quick recommendation, without forcing a written artifact. If the user wants a saved, reviewed design spec, use `design-spec`.
Agent Skill for working with Python. Use when writing, editing, or reviewing Python code and scripts.
| name | mcporter |
| description | Agent Skill for calling MCP servers through MCPorter. Use when need to call MCP tools. |
Use MCPorter as a config-free bridge from shell commands to MCP tools.
The caller must provide:
--name <slug> for the MCP target.--http-url <url> for HTTP MCP servers.--stdio "<command>" for STDIO MCP servers.Do not rely on local configured MCP server names. Do not generate or use checked-in MCPorter CLIs.
--name and explicit transport target for list, call, and auth commands.mcporter auth with the same --name and transport target, then retry the original list or call.HTTP target:
pnpm dlx mcporter list \
--http-url https://mcp.example.com/mcp \
--name example \
--schema
STDIO target:
pnpm dlx mcporter list \
--stdio "bun run ./server.ts" \
--name example \
--schema
If optional fields are hidden or the task needs a less common parameter, inspect again with --all-parameters.
Prefer named function-call syntax. Quote the whole expression with single quotes so the shell preserves parentheses, commas, and nested structures.
HTTP target:
pnpm dlx mcporter call \
--http-url https://mcp.example.com/mcp \
--name example \
'tool_name(requiredParam: "value")'
STDIO target:
pnpm dlx mcporter call \
--stdio "bun run ./server.ts" \
--name example \
'tool_name(requiredParam: "value")'
For simple flat arguments, key/value syntax is acceptable when it is clearer:
pnpm dlx mcporter call \
--http-url https://mcp.example.com/mcp \
--name example \
tool_name requiredParam=value
Use --args '{...}' when the caller already has a JSON payload or shell quoting would make a nested call expression fragile.
Use the same explicit target and name for setup:
pnpm dlx mcporter auth \
--http-url https://mcp.example.com/mcp \
--name example
For STDIO, replace --http-url with the same --stdio command used for listing and calls.
mcporter list output or label them as caller-provided assumptions.server.tool; require explicit --http-url or --stdio plus --name.--persist or write MCPorter configuration unless the caller explicitly requests persistence.generate-cli for this skill. Live inspection keeps MCP server updates simple and avoids checked-in generated artifacts.