MCP connects an application to capabilities exposed by servers. A local language model can participate in that application without becoming an MCP server itself. Keeping those responsibilities separate makes the first integration easier to understand.
The original experiment used Ollama, Qwen 2.5 7B, and mcp-cli to work with filesystem, search, and fetch capabilities. It explored the practical connection between a local model and external tools.
Put the model in the host application
The host manages the user interaction and model workflow. Its MCP client connects to a server. The server exposes tools or other capabilities and performs the work requested through that connection.
The model can propose a tool call, but application code handles its execution and returns the result. See the MCP architecture documentation for the protocol’s separation of responsibilities.
Begin with one narrow capability
The historical setup used a filesystem server configured with a specific directory. That is a useful place to start because you can compare the returned file list with the directory yourself.
Confirm that the client can list the server’s tools before involving the model. Then ask for a simple read operation and inspect both the arguments and returned data. A missing tool connection and a model choosing the wrong tool are different failures.
Tool-calling compatibility depends on the model, runtime, and client. The original article’s broad exclusion of reasoning models is not a reliable rule for selecting a current implementation.
Add remote services deliberately
The experiment then added Brave Search and a fetch server. Those tools communicate over the network even when inference runs locally. Search also introduces a provider credential and its own service requirements.
Adding servers expands the application’s reach. It does not prove that the model will select the correct operation or that every available tool should be exposed in every conversation. Keep credentials outside committed configuration and expose only the capabilities the task needs.
The original client code lives in mcp-cli. For a larger example, the REST API integration series follows the same pattern through a warehouse service, a local model, and a Python agent.