This config2mcp server currently has no CLI tools configured, so it can only provide help for adding them.
Call config2mcp_help to learn how to add CLI tools to the config.
No actual CLI commands are exposed or executable through this server as configured.
Once tools are added to a YAML config and the server is restarted, those tools would become available as MCP tools with typed parameters.
Exposes ffmpeg/ffprobe command-line tools as MCP tools, enabling agents to probe media files for JSON metadata (format, streams) and perform media conversion.
Provides a deliberately read-only git window, exposing read-only git subcommands as tools so agents can inspect repositories (e.g. log) without mutating them.
Turn any CLI tool into an MCP server. One YAML file. Zero code.
tools:
- name: probe
description: Probe a media file, return JSON metadata
command: ffprobe
args: ["-print_format", "json", "-show_format"]
params:
- name: input
positional: true
type: string
required: truenpx config2mcp serve ./ffmpeg.yamlThat's it — your agent now has a ffmpeg_probe tool it can call with a
typed, validated input parameter.
Agents are only as useful as the tools you give them. There are thousands of
battle-tested CLIs (ffmpeg, kubectl, pdftk, imagemagick, git) that
agents cannot reach, and wrapping each one by hand means writing a full MCP
server every time. config2mcp makes the wrapper a config file instead of a
project.
You keep total control over what gets exposed: the YAML is your security policy — if a command isn't in the file, the agent cannot run it.
Related MCP server: mcp-cli-catalog
# Use directly (recommended)
npx config2mcp serve ./my-tools.yaml
# Or install globally
npm install -g config2mcpRequires Node 18+.
# 1. Describe your tool
cat > ./echo.yaml <<'EOF'
tools:
- name: shout
description: Print a message in upper case
command: tr
args: ["a-z", "A-Z"]
params:
- name: message
positional: true
type: string
required: true
EOF
# 2. Check what the agent will see
npx config2mcp inspect ./echo.yaml
# 3. Validate
npx config2mcp validate ./echo.yamlCopy the block below, paste it to Claude / Cursor / DSH / any MCP-capable agent, and it will set everything up for you — package, config, and client registration. Just tell it which CLI tools you want to expose.
Install the MCP server "config2mcp" for me. Steps:
1. Create a tools config file at ~/.config2mcp/tools.yaml that exposes these CLI tools: <list your commands here, e.g. ffmpeg for media conversion, git for repo status>
2. For each tool write: name (snake_case), a one-line description, the command, its args, and typed params (flag / positional / boolean with trueFlag).
3. Config format reference: https://github.com/linwanwanwa/config2mcp#config-reference — only commands declared in the YAML are reachable (allow-list), keep it read-only if unsure.
4. Validate with: npx -y config2mcp validate ~/.config2mcp/tools.yaml
5. Register the server with your own MCP client config as:
npx -y config2mcp serve ~/.config2mcp/tools.yaml
6. Tell me which tools got registered and how to test one.Add to claude_desktop_config.json:
{
"mcpServers": {
"my-cli-tools": {
"command": "npx",
"args": ["-y", "config2mcp", "serve", "/absolute/path/to/echo.yaml"]
}
}
}Works the same with any MCP client (Claude Code, Cursor, Windsurf, ...).
Field | Type | Default | Description |
| string | — | Tool name prefix, e.g. |
| map | — | Extra env vars for every spawned command |
| array | required | The tools to expose |
Field | Type | Default | Description |
| string | required | snake_case tool name |
| string | required | What the tool does — the agent reads this |
| string | required | Executable to run (resolved from PATH) |
| array |
| Literal argv tokens before any params |
| array |
| Typed parameters (below) |
| string | — | Working directory |
| number |
| Kill the process after this long (max 600000) |
| boolean |
| Parse stdout as JSON into structured content |
| boolean |
| Also return stderr on success |
Field | Type | Default | Description |
| string | required | lowerCamelCase parameter name |
| string | auto | Agent-facing description |
|
|
| Value type |
| boolean |
| Agent must provide it |
| string | — | CLI flag, e.g. |
| boolean |
| Emit |
| string | — | For booleans: token emitted when true |
| boolean |
| Pass value as positional arg (in declaration order) |
|
|
|
|
| array | — | Allowed string values |
| string | — | Used when the agent omits the param |
docker build -t config2mcp .
# mount your own config over the bundled safe default
docker run -i --rm -v $PWD/tools.yaml:/config/tools.yaml:ro config2mcpWant to see exactly what an agent could run before granting anything?
config2mcp serve ./ffmpeg.yaml --dry-runEvery tool call then answers with the exact argv it would have run — nothing is ever executed. Great for reviewing a config before it goes anywhere near a real agent.
config2mcp is deliberately conservative:
No shell, ever. Commands are spawned directly via execve-style APIs —
every value becomes exactly one argv token, so shell injection is
structurally impossible.
The config is the allow-list. Only commands in the YAML can run, with only the flags you declared. Nothing else is reachable.
Bounded by design. Every command has a timeout (default 30 s) and captured output is capped at 256 KiB to protect the agent's context window.
Failures are data, not exceptions. Non-zero exits and timeouts are returned to the agent as readable results, so it can react.
You are still responsible for which commands you expose: an agent with
access to rm can remove files. Expose read-only subcommands (see
examples/git.yaml for a deliberately read-only git set).
examples/ffmpeg.yaml — media probing & conversion
examples/git.yaml — a read-only git window
npx config2mcp inspect examples/ffmpeg.yamlnpm install
npm test # build + unit tests (cross-platform runner)
npm run build # compile src/ → dist/
node scripts/e2e.mjs # full MCP protocol test over stdioCI runs the unit suite on a 3-OS × 4-Node matrix and the E2E protocol test
on all three OSes. Pushing a v* tag runs the full gate then publishes to
npm and creates a GitHub Release.
MIT
List files in a directory (read-only).
| Name | Required | Description | Default |
|---|---|---|---|
| dir | Yes | Absolute directory path. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It discloses the important read-only trait, but says nothing about recursion, hidden files, error handling, or return structure, leaving meaningful behavioral gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no wasted words. It is appropriately sized for a simple tool.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a low-complexity list tool with a fully documented parameter, the description is minimally adequate. However, with no output schema and no description of return values or listing semantics (e.g., recursive vs. flat), an agent lacks full context for interpreting results.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the schema fully documents the single 'dir' parameter as an absolute directory path. The description adds no additional meaning beyond what the schema already provides, matching the baseline of 3 for high coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb ('List') and resource ('files in a directory') and adds the scope qualifier 'read-only'. It is clear what the tool does, but there are no sibling tools to differentiate from, so it falls just short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives no explicit when-to-use guidance, no alternatives, and no exclusions. The parenthetical 'read-only' hints at safe usage but does not constitute usage guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v0.1.2config2mcp_helpfiles_listv0.1.1config2mcp_helpScored across 1 tool
With only a single tool, there is no possibility of overlap or misselection — the agent has exactly one option with a clearly stated purpose. No boundary confusion exists by construction.
The lone tool 'files_list' uses a consistent snake_case style, but the convention is resource_action rather than the more common verb_noun pattern (list_files). With only one tool there is no internal inconsistency to penalize.
A server named 'mcp-config2mcp' implies config-to-MCP conversion work, yet the surface consists of a single read-only directory listing tool. One tool is far too thin for the apparent scope of the server.
There is no tool for reading file contents, writing or generating configs, or performing any conversion — the core purpose implied by the server name is entirely uncovered. Only a peripheral listing operation exists, leaving the domain severely incomplete.
MCP server for Clipkit — gives AI agents a video toolbox via the Clipkit schema.
MCP server for progressive tool usage at any scale (see https://klavis.ai)
