[FEATURE] Declarative CLI-to-tool mapping (structured tools without MCP server)

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Currently, the only way to get deferred tool loading and per-tool permissions is through MCP servers. But many integrations (Obsidian, Docker, Terraform, etc.) are just thin wrappers around CLI commands — the MCP server exists solely to shell out to a CLI.

The alternatives each have gaps:

• Bash tool: No discoverability, no structured inputs, all-or-nothing permissions
• Skills/agents: Always loaded into context (no deferred loading), no per-tool permission control
• MCP server: Gets everything right, but requires writing and maintaining a server process just to wrap CLI calls

There's no way to get structured, discoverable, permission-scoped tools from a CLI without running a server.

Proposed Solution

Allow declaring CLI commands as first-class tools in settings, with the same benefits MCP tools get:

  {
    "cli-tools": {
      "obsidian_read": {
        "exec": "obsidian read path={path}",
        "description": "Read a file from the vault",
        "params": { "path": { "type": "string", "required": true } },
        "permission": "auto"
      },
      "obsidian_append": {
        "exec": "obsidian append path={path} content={content}",
        "description": "Append content to a file",
        "params": {
          "path": { "type": "string", "required": true },
          "content": { "type": "string", "required": true }
        },
        "permission": "ask"
      }
    }
  }

Claude Code would treat these like MCP tools — deferred loading, structured inputs, per-tool permissions — but execute them as shell commands with parameter substitution. No server process needed.

Alternative Solutions

• MCP servers wrapping CLIs — works but adds unnecessary complexity (a server process just to call a CLI)
• Hooks on Bash commands — can restrict commands but no structured inputs or deferred loading
• Skills — teaches Claude the CLI but always consumes context tokens and has no permission scoping

Priority

Medium - Would be very helpful

Feature Category

Configuration and settings

Use Case Example

Use Case Example:

1. I use Obsidian for notes and want Claude Code to read/search/append to my vault
2. Obsidian has an official CLI (obsidian read, obsidian search, obsidian append, etc.)
3. Today I run a community MCP server just to wrap these CLI calls — it's a whole Node.js/Python process
4. With this feature, I'd declare each CLI command as a tool in settings
5. Read tools get "permission": "auto", write tools get "permission": "ask"
6. Tools are deferred-loaded (no context cost until used), structured (typed params), and permission-scoped
7. No server process to install, configure, or maintain

Additional Context

This would turn any CLI into a first-class Claude Code integration with zero code. It bridges the gap between MCP (powerful but requires a server) and Bash (simple but no guardrails).