TL;DR: Making a CLI tool usable by an AI assistant normally means writing a bespoke integration for each assistant. It doesn’t have to. Every tool built on go-tool-base ships an mcp command that exposes the whole command tree over the Model Context Protocol: command names become tool names, descriptions become tool descriptions, flags become JSON Schema parameters. You already wrote all of that. MCP just lets an AI read it.
You already described your capabilities
Stop and think about what a well-built CLI tool actually is. It’s a set of named operations, each with a human-readable description, each taking a set of typed, named, documented parameters. You wrote all of that already, because a CLI without it is unusable by people.
Now look at what an AI assistant needs in order to call a tool. A set of named operations. A description of each, so it knows when to reach for them. A typed parameter schema for each, so it knows how to call them.
It’s the same list. A good CLI is already, structurally, a description of a set of capabilities. The information an AI agent needs is not extra work you have to do. It’s work you finished the moment your --help output was any good.
The only thing missing is a translator. Something that takes “this is a CLI” and presents it as “this is a set of tools an AI can call.”
MCP is that translator, and it’s a standard
The temptation, when you want your tool to be AI-usable, is to write an integration. A little adapter for Claude Desktop. Another for Cursor. Another for whatever comes next. Each one a bespoke wrapper, each one a thing to maintain, and the list never stops growing because new assistants keep appearing.
The Model Context Protocol exists to kill that list. MCP is an open standard for how an AI model discovers and calls local tools. Implement it once and your tool works with every assistant that speaks it. Write once, not once-per-client.
So go-tool-base implements it once, in the framework, for everyone.
The mcp command, and the mapping it does for free
Every tool built on go-tool-base inherits a built-in mcp command. Run it:
mytool mcp
and the tool starts a JSON-RPC server over standard I/O, speaking MCP. That’s the whole user-facing surface. One command.
Behind it, the framework walks your Cobra command tree and maps it straight onto MCP tool definitions:
- Each command becomes a tool.
- Each command’s short description becomes the tool’s description — the text the AI reads to decide whether this is the tool it wants.
- Each command’s flags and arguments become the tool’s JSON Schema parameters.
There is no second schema to write and keep in sync. The command tree is the schema. Add a new command to your CLI and it’s a new tool for the agent, automatically, with the description and flags you already gave it. Nobody has to remember to update an MCP manifest, because there is no separate MCP manifest to forget.
Configuring an assistant to use it
On the assistant’s side it’s equally undramatic. You tell your AI client (Claude Desktop, Cursor, anything MCP-aware) to launch mytool mcp. From then on the assistant:
- Starts your tool in MCP mode when it boots.
- Discovers every command as a callable tool.
- Calls the right one, with the right parameters, when a user’s request needs it.
Your CLI tool has become something the AI can pick up and use, mid-conversation, on its own initiative.
The safety property worth noticing
There’s a quietly important constraint in this design. The AI can only call what you defined. The tools it sees are exactly the commands in your tree, and the parameters it can pass are exactly the flags and arguments you declared, validated against the JSON Schema generated from them.
It cannot invent a command. It cannot pass a parameter you didn’t define. The boundary of what the agent can do is the boundary of what your CLI does, and you drew that boundary already when you built the tool. Exposing the CLI over MCP doesn’t widen the surface. It just makes the existing surface reachable.
That matters, because “let an AI run things on my machine” is rightly a sentence that makes people nervous. The answer here is that the AI isn’t running things. It’s running your commands, the ones you wrote, tested and shipped, and nothing else.
In short
A CLI tool, built properly, is already a structured description of a set of capabilities: named operations, descriptions, typed parameters. That’s also exactly what an AI agent needs to call a tool. The gap is only a translator, and writing a bespoke one per assistant is a treadmill.
go-tool-base puts the translator in the framework. Every tool gets an mcp command that serves the command tree over the Model Context Protocol — commands become tools, descriptions become descriptions, flags become JSON Schema parameters, with no second schema to maintain. Point any MCP-aware assistant at it and your CLI is an agent-callable tool, bounded to exactly the commands you shipped.
You did the hard part when you built a good CLI. MCP just opens the door you already framed.