Skip to main content
Glama
segalz

cline-local mcp for Cline CLI

by segalz
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

Local Cline MCP Bridge

This is a local stdio MCP server that exposes one tool, ask_cline. It launches the authenticated Cline CLI and returns only the terminal text response plus model, duration, and usage/cost when Cline supplies them.

Requirements

  • Node.js 20 or newer

  • The Cline CLI already installed and authenticated (cline.exe on Windows)

Related MCP server: Workbench MCP Server

Install, build, and launch

npm install
npm run build
npm test
npm start

npm start runs a stdio server, so it will appear idle until an MCP client connects. Do not type prompts into that terminal.

MCP client configuration

Build first, then add this server to an MCP client that supports stdio servers:

{
  "mcpServers": {
    "cline-local": {
      "command": "node",
      "args": ["C:\\Develop\\ClineMcp\\dist\\index.js"]
    }
  }
}

Tool

ask_cline({
  prompt: string,
  cwd?: string,
  thinking?: "none" | "low" | "medium" | "high" | "xhigh",
  timeoutSeconds?: number,
  systemPrompt?: string
})

  • timeoutSeconds defaults to 180 and is limited to 300.

  • thinking defaults to none.

  • On Windows, prompt is limited to 20,000 characters and systemPrompt to 8,000. Together they may not exceed 24,000 characters, leaving a safe margin below the Windows command-line limit.

  • The bridge always invokes cline --json --auto-approve false and uses an argument array, never a shell command.

  • It passes --system only when systemPrompt is supplied and --cwd only when cwd is supplied.

  • Cline streamed content and reasoning are ignored. Only a terminal run_result-style event is returned.

  • With --auto-approve false, Cline cannot obtain automatic approval for file-changing operations. Use this bridge only for analysis/chat prompts.

Manual test

After configuring the MCP client, call:

{
  "prompt": "Reply with exactly: Cline bridge test successful.",
  "thinking": "none",
  "timeoutSeconds": 180
}

The returned text should be Cline bridge test successful.

Isolated workspace analysis

ask_cline_workspace is a separate tool for repository-wide analysis. It requires a cwd inside a Git repository with at least one commit. The bridge creates a detached Git worktree in the system temporary directory, runs Cline there with a mandatory analysis-only instruction, and removes the worktree in a finally block after success, failure, timeout, or cancellation.

{
  "prompt": "Review this repository for reliability and security issues. Do not modify files.",
  "cwd": "C:\\Develop\\your-repository",
  "thinking": "high",
  "timeoutSeconds": 300
}

This tool uses Cline with automatic tool approval only inside the disposable worktree so it can inspect the repository. The prompt prohibits writes and external side effects, but this is not an operating-system sandbox; use it only for repositories you trust. The original ask_cline tool remains the stricter no-workspace-access option.

Run a live isolated-workspace check with:

npm run verify:workspace

Security notes

The bridge does not read or return Cline configuration, credentials, API keys, tokens, stderr, or streamed reasoning. Process launch, non-zero exit, timeout, cancellation, malformed JSONL, and a missing final result are returned as generic MCP tool errors.

Available Tools

2 tools
ask_clineC

Ask the locally installed Cline CLI for an analysis/chat response. File edits are not approved.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdNo
promptYes
thinkingNo
systemPromptNo
timeoutSecondsNo

TDQS

C2.9/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description must carry the behavioral disclosure burden. It does disclose one important trait: file edits are not approved. However, it leaves other behaviors unstated, such as how the CLI is invoked, whether commands can be executed, what side effects may occur, and how errors or partial responses are handled.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two short sentences with no filler. The purpose is front-loaded, and the safety constraint earns its place. It is concise without sacrificing the key message.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The tool has five parameters and no annotations or output schema, yet the description only covers the high-level action and a single safety note. It omits any explanation of cwd, thinking levels, system prompt, timeout settings, or return value shape, making it incomplete for reliable invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for the schema's silence. It does not mention or explain any of the five parameters (prompt, cwd, thinking, systemPrompt, timeoutSeconds), providing no semantic value beyond what the plain parameter names suggest.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a clear verb and resource: 'Ask the locally installed Cline CLI for an analysis/chat response.' This makes the basic purpose evident. It does not explicitly contrast with the sibling ask_cline_workspace, though the 'locally installed' phrasing hints at a distinction.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus ask_cline_workspace, nor are any exclusions or prerequisites mentioned. The sentence 'File edits are not approved' is a constraint, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

ask_cline_workspaceB

Analyze a Git workspace through Cline in a disposable worktree. The worktree is always removed after the request.

ParametersJSON Schema
NameRequiredDescriptionDefault
cwdYes
promptYes
thinkingNo
timeoutSecondsNo

TDQS

B3.4/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With no annotations, the description carries the full burden. It discloses the key non-obvious behavior: 'The worktree is always removed after the request.' This clarifies that side effects are contained in a disposable environment, which is valuable. It does not mention other potential behaviors like network access or code execution, but the lifecycle disclosure is strong.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two tightly written sentences, with the core purpose first and the essential disposal behavior second. Every word earns its place; there is no fluff or repetition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

The description covers purpose and one behavioral trait, but with four undocumented parameters, no output schema, and no annotations, an agent is left without guidance on parameter meaning, expected return value, or how this differs from ask_cline. Too much is left to inference for a complete tool definition.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, and the description does not explicitly define any of the four parameters. It indirectly hints that cwd refers to the Git workspace and prompt is the Cline request, but thinking and timeoutSeconds are completely unexplained. The description fails to compensate for the schema's silence.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb ('Analyze') and resource ('a Git workspace'), and adds a mechanism ('through Cline in a disposable worktree') that distinguishes it from the sibling ask_cline. It is clear but not as explicit as naming the alternative or describing the exact outcome.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage for analyzing a Git workspace in a safe, throwaway context, but it does not explicitly say when to prefer this tool over ask_cline or when not to use it. No exclusion criteria or alternative routing is provided.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv1.0.0
    • First observedask_cline
    • First observedask_cline_workspace
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.6/5.0

Scored across 2 tools

Disambiguation5/5

The two tools are completely distinct: one is for general chat/analysis, and the other specifically analyzes a Git workspace in a disposable worktree. There is no ambiguity in their purposes.

Naming Consistency5/5

Both tools share the 'ask_cline' prefix with one using a descriptive '_workspace' suffix. The naming pattern is clear, consistent, and easy to predict.

Tool Count4/5

Two tools is slightly below the typical range, but each tool has a distinct and necessary role for the server's stated purpose. The set is minimal yet not underdeveloped.

Completeness5/5

For an analysis-only interface to the Cline CLI, the two tools cover all stated use cases: general chat and workspace analysis. No obvious missing operations or dead ends exist within this narrow domain.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers