Spending an entire day experimenting with integrating a local Ollama model into Cline installed in VS Code, initially driven by curiosity about whether it could perform internet searches autonomously, eventually involved setting up and then removing an MCP web search server.
Organized the Cline configuration file.
I first inquired about how to integrate the pre-prepared clinerules.md (for company use) and clinerules-personal.md (personal use) files into Cline. It was confirmed that Cline automatically reads files named .clinerules without extensions or those located in a .clinerules/ folder at the project root. The personal rules were copied to ~/Documents/Cline/Rules/personal.md for global application on macOS, ensuring consistency with a diff check against the original. Workspace-specific rules were deferred to be added later via a .clinerules/ folder, pending current project needs.
Did you include internet search functionality as well?" Curious, I investigated further.
I confirmed that the websearch functionality within Cline operates exclusively when utilizing Cline’s own paid provider. Due to using a local Ollama model variant qwen2.5-coder:7b, the default web search feature remained inactive. Additionally, I was pre-warned that integrating an MCP server might be necessary and that relying on a 7B local model for tool calls could compromise reliability.
A model touted as exclusively tool-oriented turned out to be merely superficial.
I investigated whether the alternative hhao/qwen2.5-coder-tools truly addressed the issue. Upon examining the system prompt file directly, it appeared to be merely a ModelFile wrapper around the base qwen2.5-coder weights with an additional instruction to respond in JSON format during tool usage, rather than a proper fine-tuned model. Furthermore, reports from the community indicated compatibility issues when integrated with Cline, lacking official Ollama tools, vision, and thinking badges. Fortunately, qwen3.5:9b was already installed locally, equipped with all official badges, making it an immediate replacement choice.
I have directly integrated the Web Search MCP server.
Located the configuration file path for Cline extension (~/Library/Application Support/Code/User/globalStorage/saoudrizwan.claude-dev/settings/cline_mcp_settings.json) and registered duckduckgo-mcp-server without an API key. Immediately after registration, an unfamiliar message, "Cannot use checkpoints in Desktop directory," appeared, causing initial confusion. However, it was discovered that macOS TCC privacy policies were preventing Cline from enabling checkpoint functionality (automatic snapshots) due to the working directory being under ~/Desktop. Despite this, there was no disruption to actual file editing or tool execution, so the issue was disregarded.
In the initial test, the model scraped news using terminal commands curl and grep without utilizing the registered MCP tools, encountering recurring "Invalid API Response" errors intermittently. Upon checking the MCP panel, although the server was powered on, its status indicated a red dot (disconnected). Clicking the "Restart Server" button resolved this, transitioning to a green dot, after which the duckduckgo_web_search tool prompted for approval appeared correctly on subsequent attempts.
Immediately after, an error message stating "DDG detected an anomaly in the request" appeared. Since DuckDuckGo lacks an official search API, this MCP was actually scraping HTML pages directly, leading to detection and blocking as a bot when requests were repeated.
Ultimately, all MCP components were removed.
We briefly considered alternative official APIs as well. Brave Search API was excluded due to the elimination of its free tier starting February 2026 and mandatory card registration upon sign-up, while Tavily offered a free tier of 1,000 credits per month without card requirements and included official MCP (tavily-mcp), prompting initial registration. However, it became evident that dividing responsibilities rather than consistently pursuing MCP reliability with a local 9B model was more efficient. Local Cline will now be utilized exclusively for draft creation and mechanical editing tasks devoid of external knowledge demands, delegating search and judgment tasks to Claude Code instead. Consequently, all registered MCP servers (duckduckgo-search, tavily-mcp) were decommissioned.
Considered exploring its use as an unmanned agent akin to Hermes for development purposes.
Additionally, I explored whether Cline could serve as an unattended agent, akin to Hermes News Automation Pipeline already running in the background. Cline CLI 2.0 offered headless operation (-y/--yolo flags) and cron integration, along with methods to embed agent loops directly into scripts using the @cline/core/@cline/agents SDK. However, the reliability issues encountered with tool invocation could escalate significantly in a fully automated environment without human oversight, and given that Cline CLI/SDK is still relatively new, there wasn't sufficient evidence to justify replacing the established Hermes system just yet. Consequently, implementation was put on hold, maintaining the current Hermes setup.
Trouble Shooting
| Symptoms | Cause | Solution method |
|---|---|---|
| Expected hhao/qwen2.5-coder-tools to resolve tool-calling issues. | Not actual fine-tuned, just a Model file wrapper with added system prompts; lacks official tool badge. | Replace with qwen3.5:9b featuring official tools badge |
| Error message: Cannot use checkpoints in Desktop directory | Due to macOS TCC policies, checkpointing is defensively disabled for projects located under ~/Desktop. | No impact on actual tasks confirmed, proceed as is |
| Using Terminal Workaround Without MCP Tool + Repeated Invalid API Responses | Edited the configuration file directly while running, resulting in server registration only without connection (red dot) status. | Click "Restart Server" on the MCP panel → reconnect with green dots |
| DDG detected an anomaly repeatedly even after connection recovery | Lack of official API means scraping, structurally limiting bot detection by DuckDuckGo. | Following official API review by Tavily et al., MCP was ultimately decided to be removed from local Cline setup. |
Reflections / Next Steps
Today was a day where firsthand experience confirmed the significant gap in reliability when calling tools between local LLMs, which are free and fast, and cloud models. Moving forward, we plan to clearly delineate roles: using local LLMs for initial drafts and leveraging cloud models for judgment and search tasks. Hermes automation still requires cron trigger setup completion, which we aim to finalize in the next session.
Comments
Post a Comment