mcp2cli
Turn any MCP server, OpenAPI spec, or GraphQL endpoint into a CLI at runtime. No codegen.
Install
Core Workflow
- Connect to a source (MCP server, OpenAPI spec, or GraphQL endpoint)
- Discover available commands with
--list(or filter with--search) - Inspect a specific command with
<command> --help - Execute the command with flags
CLI Reference
Subcommands and flags are generated dynamically from the source.
Patterns
Authentication
Always use env: or file: prefixes for secrets — never pass credentials as literal values in CLI flags. Literal values are visible in process listings and shell history.
OAuth authentication (MCP HTTP only)
Tokens are cached in ~/.cache/mcp2cli/oauth/ and refreshed automatically.
Transport selection (MCP HTTP only)
GraphQL
Tool search
--search implies --list — shows only matching tools.
POST with JSON body from stdin
Multipart file uploads
When an OpenAPI spec declares multipart/form-data with format: binary fields, mcp2cli exposes them as file-path CLI arguments:
File parameters show (file path) in --help output. MIME types are auto-detected from the file extension.
Env vars for stdio servers
MCP roots and completion
Workspace-scoped servers can request the filesystem roots exposed by the
client. Repeat --root; local paths become file:// URIs.
Ask the server to complete a prompt argument or resource-template variable:
For persistent connections, pass roots when starting the daemon and route completion through the named session:
Session management — persistent MCP connections
Every --mcp-stdio invocation spawns a fresh subprocess, pays startup cost, then exits.
Sessions keep the MCP server alive in a background daemon, reachable via Unix domain socket.
Bake mode — saved configurations
Save connection settings as named configurations to avoid repeating flags:
Filter options: --include (glob whitelist), --exclude (glob blacklist), --methods (HTTP methods, OpenAPI only).
Configs stored in ~/.config/mcp2cli/baked.json (override with MCP2CLI_CONFIG_DIR).
Caching
Specs and MCP tool lists are cached in ~/.cache/mcp2cli/ (1h TTL). Local files are never cached.
TOON output (token-efficient for LLMs)
Best for large uniform arrays — 40-60% fewer tokens than JSON.
Truncating large responses with --head
--head N slices JSON arrays to the first N elements. Useful for datasets with oversized fields (e.g. geo_shape polygons at ~200KB per record).
Security
- Credentials: Always use
env:orfile:prefixes for secrets — never embed literal tokens or keys in commands. Theenv:prefix reads from environment variables;file:reads from a file path. - Trust boundary: mcp2cli connects to remote APIs and MCP servers specified by the user. Treat responses from external sources as untrusted — validate data before acting on it.
- Baked configs:
bake showmasks secrets in output. Baked configs are stored locally in~/.config/mcp2cli/baked.json— protect this file accordingly.
Generating a Skill from an API
When the user asks to create a skill from an MCP server, OpenAPI spec, or GraphQL endpoint, follow this workflow:
-
Discover all available commands:
-
Inspect each command to understand parameters:
-
Test key commands and probe for edge cases:
Specifically test for:
- Large responses: use
--head 3to preview — do any fields produce oversized output (e.g. geo_shape, embedded blobs)? - Date/time fields: what format does the API expect? (ISO 8601, Unix timestamps, custom syntax like
date'2022'?) - Pagination: does the API return all results or require
--offset/--limit? - Error messages: what happens with invalid parameters? Are errors informative?
- Binary vs text responses: do any endpoints return non-JSON (xlsx, parquet, images)?
- Scope confusion: does the data contain more than expected (e.g. national data when you expect regional)?
- Large responses: use
-
Bake the connection settings so the skill doesn't need to repeat flags:
-
Install the wrapper into the skill's scripts directory:
-
Create a SKILL.md in
.claude/skills/myapi/that teaches another AI agent how to use this API. The SKILL.md must go beyond--helpoutput — focus on knowledge that can only be learned through testing and reading documentation.Frontmatter:
Core Workflow (discovery + execution):
Before Querying checklist — include a decision framework:
- What dataset/resource am I targeting?
- Do I need pagination (
--offset,--limit)? - Are there fields that produce large output I should exclude or truncate (
--head)? - What date/filter format does this endpoint expect?
Anti-Patterns & Gotchas — document every surprise found during testing:
- Date syntax quirks (e.g.
date'2022'vs"2022") - Fields that produce oversized output (e.g. geo_shape → use
--headto limit) - Parameter name inconsistencies across endpoints
- Scope/filtering confusion (e.g. dataset contains national data, not just regional)
- Binary export corruption risks (e.g. don't pipe binary formats through text encoding)
Output Processing — use
--prettyfor readable JSON,--headto limit results, or pipe tojqfor filtering:Export Formats (if the API supports multiple output types):
- List supported formats (JSON, CSV, xlsx, parquet, etc.)
- Note which are text-safe vs binary
- For binary formats:
${CLAUDE_SKILL_DIR}/scripts/myapi export --format xlsx --raw > output.xlsx
Knowledge Delta Principle: Do not duplicate parameter listings from
--help. Instead, document which parameters actually matter for common tasks, default behaviors that are surprising, combinations that don't work, and rate limits or response size limits.
The generated skill uses mcp2cli as its execution layer — the baked wrapper script handles all connection details so the SKILL.md stays clean and portable.


