How to connect a CLI tool to an LLM using MCP

Many founders build useful internal tools in the command line. From a script that generates reports to a command that pulls customer data, the command line interface (CLI) is one of the fastest ways to run repeatable tasks. You type a command and right away something happens.

Large language models (LLMs) are also useful for internal workflows, especially as they’ve become more proficient with reasoning, summarizing, and identifying what actions may be relevant next. But they’re still limited — they can suggest actions, but can’t take them. That’s starting to change as the tech landscape is evolving from AI that answers questions to AI that can help coordinate workflows.

Now, there’s a way to combine the capabilities of a CLI and LLM: Model Context Protocol (MCP) acts as the bridge between your existing CLI tools and an LLM that can decide when and how to use them. In this guide, we’ll walk through how to connect a CLI tool to an LLM using MCP, so you can turn your scripts from one-off tools into part of a system that can support actions.

Before getting into the MCP, it helps to cover the basics.

A CLI is a way to communicate with your computer’s applications through text commands typed into a terminal or console. It’s predictable: If you run the same command with the same inputs, you get the same output. 

An LLM works differently. It interprets intent, identifies relevant actions, and generates responses based on context. 

These differences create a mismatch: 

• CLI tools require a human to trigger them.
• LLMs can help determine what actions may be relevant, but can’t determine when they may be used.

To bridge the gap, you need MCP.

Model Context Protocol (or MCP) exposes your tools in a format that an LLM can understand and use. At a high level, it translates a CLI command into a structured and callable tool. 

Instead of raw commands, the LLM sees tools with names, defined inputs, and expected outputs. The key idea is simple: An MCP server is the layer that makes your tools usable by AI. It wraps your existing CLI commands and presents them in a structured way. The LLM can then discover those tools, determine when and how they may be used, and call them with the right inputs. As a result, your tools become more accessible. Instead of one person owning a process because they know which commands to run, the workflow becomes accessible to anyone who can describe the outcome they want. That reduces bottlenecks and makes it easier to scale internal processes, without adding more overhead.

Once everything is wired together, a flow might look like this: 

1. A user asks the LLM for something. 
2. A client (such as Claude Code or Cursor) brokers the request.
3. The LLM interprets the request.
4. It sees available tools through the MCP server. It selects an appropriate tool and prepares inputs.
5. The client routes the request through the MCP server.
6. The CLI command runs.
7. The output returns to the LLM.
8. The LLM formats a response for the user. 

In simpler terms: 

User → Client → LLM → Client → MCP Server → CLI tool.

This changes how work actually gets done because the LLM is now helping to manage the response rather than just answering questions.

To get started, you just need one well-defined command. 

Step 1: Start with a clear CLI command

Pick a command that already works and has clear inputs. 

Here’s an example: 

generate-report --month march

This command works well because it does one thing, has a clear input, and produces a predictable output.

Step 2: Define the tool schema

Now, translate that command into something that the LLM can understand.

You’ll need to define the:

• Tool name
• Inputs
• Output format

For example, you could define it like this:

• Tool: generate_report
• Inputs: month (string)
• Output format: report_summary (string)

Now, your tool will be understandable to the LLM.

Step 3: Wrap it in an MCP server

Next, expose the tool through an MCP server.

MCP is the protocol that defines how LLMs interact with tools, and you have a few options for how to implement it:

• modelcontextprotocol/python-sdk: the official Python SDK, good if you want fine-grained control
• modelcontextprotocol/typescript-sdk: the official TypeScript/Node.js SDK, good if your CLI tooling is JS-based
• FastMCP: a Python framework that wraps the official SDK and removes most of the boilerplate; a good default for getting started quickly

For local CLI tools, stdio is the right transport choice. It means the MCP server communicates over standard inputs and outputs, which integrates with clients like Claude Code or Cursor without needing to expose a port or manage a network connection.

The MCP server:

• Registers your tool
• Handles calls from the LLM
• Runs the CLI command
• Returns structured output

Here’s a simple example using Python and FastMCP:

# server.py

from fastmcp import FastMCP

import subprocess

mcp = FastMCP("tools")

@mcp.tool()

def generate_report(month: str) -> str:

    """Generate a financial report for the given month."""

    result = subprocess.check_output(

        ["generate-report", "--month", month],

        text=True

    )

    return result

if __name__ == "__main__":

    mcp.run(transport="stdio")

Step 4: Let the LLM call it

Once the tool is registered, the LLM can decide when to use it.

For example, you could use this prompt: “Generate a March financial report.”

Then, the LLM will:

• Map the request to generate_report
• Extract the input (March)
• Call the tool through MCP

No manual command execution is needed.

Step 5: Handle output and errors

Your CLI output should be structured, consistent, and easy to read. If outputs are messy, the LLM will struggle to use them.

Clear outputs make the system more reliable. So, make your error messages clear. Instead of vague failures, return something like, “No data found for the selected month.”

Ready to automate financial workflows? Let’s make this more practical. Say you have a CLI tool that pulls transaction data. Through MCP, you expose it as something like: 

get_transactions(date_range=...)

This allows the LLM to now use it. 

A founder might ask the LLM to summarize March spend and flag anything unusual. The system then: 

1. Calls the transaction tool
2. Gets the data
3. Analyzes spending
4. Flags anomalies
5. Returns a summary

What used to take multiple steps can now be completed in one flow. For founders, that means less manual reporting, faster insights, and repeatable workflows. Over time, this can change how your team operates.

Most early teams probably already have useful internal tools. The problem is that they depend on manual execution. Connecting CLI tools to an LLM changes how those tools get used, and it can materially improve how your business operates.

This setup can unlock:

• Multi-step workflows without extra orchestration
• Faster internal operations
• The ability to iterate without rebuilding systems

Instead of thinking about the commands to run, you can think about the outcome you want and allow the system to coordinate the remaining steps. For instance, instead of running a command, exporting data, and writing a quick summary, you ask for the result directly.

Or, take an activity like pulling customer data, for example. Instead of remembering which command to run, filtering it, and formatting it into something readable, you can ask for a list of your top customers this month, and the system can pull, organize, and present the data for you.

These are just a couple of examples of how CLI commands can be connected to LLMs through MCP, and how that connection can turn recurring, manual tasks into simpler workflows.

This approach works best for workflows that are repetitive, data-driven, and slightly tedious to run manually. Some helpful starting points include:

• Financial reporting and operations: You could pull data, summarize performance, and generate reports.
• Growth analytics workflows: You could query metrics, compare periods, and surface insights.
• Internal dashboards and data pulls: You could turn raw queries into usable answers.
• Dev and deployment pipelines: You could trigger builds, check statuses, and summarize logs.

If your team already relies on CLI commands in any of these areas, you’re well-positioned.

This set-up only works if your foundations are solid. Here are a few things to keep in mind:

• Your CLI tools need to be structured and reliable.
• The ecosystem is still early.
• Error handling is critical.
• Clear inputs and outputs matter more than complexity.

When it’s done right, it feels simple, but getting there requires some intention.

You don’t need to convert everything at once. Start small with one workflow: 

1. Pick something high-value.
2. Identify the CLI command. 
3. Define clean inputs and outputs.
4. Expose it through MCP. 
5. Test it with real prompts.

Focus on clarity first, and then iterate.

Tools used to be capabilities that humans operated. MCP turns them into something a model can pick up and use.

CLI tools are a natural starting point because they’re already structured and reliable. MCP connects them to something that can decide and act. The result is a system where your operations are programmable at a higher level.

If you’re already building internal tools, you don’t need to start from scratch to make them more powerful. Connecting a CLI tool to an LLM using MCP is one of the simplest ways to upgrade how your systems work and give your tool a new interface that can interpret intent, initiate actions, and support workflows end to end.

Start with one workflow, make it callable, let the model use it, and test it with real prompts. For example, you could ask for last month’s burn — and get a clean, actionable answer back (rather than a messy Slack thread full of CSV exports). From there, you’ll start to see more opportunities. With the right set-up, reporting will getfaster, insights get surfaced without digging, and workflows that used to be one-off become repeatable.

If you’re ready to take the next step, start by understanding how MCP works in practice with Mercury’s guide to MCP.

AI-generated insights and actions may vary and are not guaranteed. Please review outputs before taking action.