Using IconVectors with Cline

The Cline VS Code extension and the Cline CLI can both work on the icon that is open in IconVectors, rather than on SVG markup pasted into a chat. Cline launches IconVectorsMcp.exe as a local stdio MCP server; that sidecar forwards each call over loopback to the IconVectors 2.0+ application you already have running. Through it, Cline reads the live document and selection, browses Icon Explorer, edits geometry, renders previews, exports files, and runs the Explorer batch tools.

This guide is for IconVectors 2.0+ on Windows. The macOS and Linux 2.00 builds are coming soon, so every path and command below is Windows only for now. Two Cline quirks shape the setup: the CLI auto-approves tool calls by default, and it doesn't find a project .cline\mcp.json on its own. Step 3 deals with both.

1. Start IconVectors

Start IconVectors the normal way and leave it running. Cline starts the sidecar, never the application. From PowerShell:

& 'C:\Program Files\Axialis\IconVectors\IconVectors.exe'

IconVectorsMcp.exe is installed beside IconVectors.exe. Check that it's there, because that is the executable Cline will launch; don't start it yourself or run it as a background service. The application listens on 127.0.0.1:61337 by default. If you changed Options/McpPort, note the value, since every port setting below has to match it. With more than one IconVectors instance open, only the one that owns the configured port receives calls; there's no instance selector.

Everything here stays on the local machine. IconVectors publishes no remote HTTP endpoint, so a Cline process running in a container, in WSL, or in a cloud workspace can't reach the desktop application by connecting to its own localhost.

2. Add the server in the Cline extension

In VS Code, open the Cline panel and go to MCP Servers -> Configure -> Configure MCP Servers. Add this entry under mcpServers:

{
  "mcpServers": {
    "iconvectors": {
      "command": "C:\\Program Files\\Axialis\\IconVectors\\IconVectorsMcp.exe",
      "args": ["--port", "61337"],
      "disabled": false,
      "autoApprove": []
    }
  }
}

The command is the normal installed-product path. Change it if IconVectors is installed elsewhere, and change the port if you changed Options/McpPort. The backslashes are doubled because this is JSON. "disabled": false makes the server active. "autoApprove": [] means every IconVectors call asks you first; leave it empty for now, and see the Approvals section below before narrowing it.

3. Set up Cline CLI

The CLI keeps its own settings, separate from the extension's. Run the wizard, then inspect what it produced:

cline mcp
cline config mcp
cline config mcp --json

cline mcp is the supported wizard, and it's the route to prefer. cline config mcp shows the resulting configuration; the --json form shows the raw entries, which is the quickest way to check that the command path and port came through intact.

Where those settings live is the awkward part. Cline's documentation describes both user and project configuration, but the current first-party CLI code resolves settings from %USERPROFILE%\.cline\data\settings\cline_mcp_settings.json by default, or from the file named in CLINE_MCP_SETTINGS_PATH when that variable is set. So if you want a project-level .cline\mcp.json to be used, don't count on the CLI discovering it. Set the variable to the file's absolute path before launching the CLI, then confirm the server is listed:

$env:CLINE_MCP_SETTINGS_PATH = 'C:\projects\icons\.cline\mcp.json'
cline config mcp

Then approvals. The CLI currently defaults to auto-approval, which is the wrong default while a tool can replace a document or write to disk. For IconVectors work, start it like this:

cline --auto-approve false

That puts the CLI on the same footing as the extension with an empty autoApprove list: calls wait for you.

4. Verify the connection

With IconVectors running and the server saved, check that Cline can see it. In the extension, the MCP Servers view shows each server's connection status and the tools it discovered. In the CLI, run cline config mcp. Then ask Cline to call these four tools, in this order:

• app_ping
• app_getInfo
• app_getCapabilities
• app_get_workspace

A prompt like Use the iconvectors MCP server to call app_ping, app_getInfo, app_getCapabilities and app_get_workspace, and summarize what came back. is enough. app_ping proves the sidecar reaches the application. app_getInfo identifies the instance that answered, which is the thing to check when more than one IconVectors is open. app_getCapabilities and app_get_workspace report what this build supports and whether Editor or Explorer is active.

Before any change, inspect the state you're about to touch as well: in Editor, the current document and selection (document_getInfo and selection_get); in Explorer, explorer_get_state and explorer_list_entries. Editor and Explorer are distinct states. Switch between them deliberately with app_set_workspace, then inspect again.

5. Install the skill

The iconvectors-mcp skill distributed with IconVectors 2.0+ carries the shared inspect, mutate, recover and verify workflow, plus a references directory the instructions point at. If your Cline setup requires Skills to be enabled, enable them first. Then copy the complete skill folder, references included, so that SKILL.md lands at one of these paths:

• workspace: .cline/skills/iconvectors-mcp/SKILL.md
• user: %USERPROFILE%\.cline\skills\iconvectors-mcp\SKILL.md

Copy the whole folder, not just SKILL.md; on its own it's missing the references it relies on. Cline loads the skill's metadata first and pulls in the instructions and resources on demand, when a task calls for them. That is the right place for the tool catalog to live. Don't reproduce the 155-tool list in your rules files, which are always on whether or not the task involves icons; a rule that points at the skill is enough.

6. Make a first bounded edit

Keep the first real task small and give it the shape every task should have: inspect, change one thing, verify.

Start with capabilities and workspace (step 4), then the state you're about to touch: the active document and selection in Editor, or the current folder in Explorer. Then ask for one bounded mutation. Recolor the selected path, or rename one file; not "tidy up all my icons". Approval is still on, so a call that would write to the document or the disk shows you the tool and its arguments first. Approve the one you asked for.

Then have Cline read the result back: the changed element and its geometry, the selection, or the Explorer listing. "Done" in prose isn't verification. If the result is wrong and the operation is documented as undoable, use one Undo and inspect again. Element ordinals are live document identities, not permanent IDs, so a structural edit (create, delete, reparent, reorder, compound-path work, or a whole-document replacement) can make an ordinal you saw earlier stale. Reinspect instead of reusing old targets.

For several related edits to the active document, use a history transaction: history_beginTransaction returns a txId, the compatible edits follow, and history_commitTransaction takes that exact ID (history_rollbackTransaction if a step fails). Don't leave a transaction open, and don't mix unrelated work into it. Transactions and document Undo don't cover everything. document_new, document_open and document_setSvg replace state and clear the Undo history. Save, Save As, export, preferences, palette files, view state and selection changes aren't Undo operations either. And Explorer create, rename, delete, paste, duplicate, grouping and batch apply change the filesystem, which document history can't roll back. Explorer Paste and Duplicate support a dry run. The Explorer batch tools use a plan then apply protocol: review the plan's summary, diagnostics and plan_id, then apply only that unchanged plan. A rejected apply consumes the plan, so make a new one instead of retrying the old ID.

155 tools and model providers

Cline's MCP client layer is naming-compatible with all 155 production IconVectors tools. The camelCase suffixes in names like app_getInfo pass through Cline's MCP runtime as they are, so no tool needs renaming or aliasing.

Cline supports many model providers, including private OpenAI-compatible endpoints, and that is where the statement above needs a boundary. It's a statement about the Cline MCP client layer. An individual provider or model can have its own limits on tool count, names, schemas, or context, so it doesn't imply that every model you can point Cline at will handle a 155-tool catalog.

Cline currently documents no MCP Tool Search and no per-server include or exclude filter, so there's no client-side way to trim the catalog down to a task. Three habits make up for it. Keep the iconvectors server disabled ("disabled": true) when you aren't working on icons, so the catalog stays out of context on unrelated work. Prompt precisely, naming the tool or the exact outcome you want. And prefer bounded results: a DOM query for one element rather than the full SVG, minified SVG rather than pretty-printed, and no preview PNG or base64 payload unless you need one.

Approvals

In the extension, the Auto Approve settings include a Use MCP servers option, which applies across servers. The autoApprove array in the server entry can be narrower than that global switch, approving only the tools it lists. Leave it empty at first, and keep prompts on for document replacement (document_new, document_open, document_setSvg), save and export, Explorer filesystem operations, and batch apply. In the CLI, --auto-approve false is the equivalent.

Approval isn't an Undo guarantee. Auto-approval, allowlists and trust settings are client policy; they don't change what IconVectors does once a call arrives. So reinspect after structural edits, and if Cline finds a dirty document it doesn't know, don't let it force a replacement. Have it ask for the intent instead.

Troubleshooting

Server or tools are missing

Check the surface you're actually using. In the extension that's the MCP Servers panel; in the CLI it's cline config mcp. Then confirm the server isn't disabled, the command path is absolute and points at IconVectorsMcp.exe, the port matches, and, for the CLI, the settings file being read is the one you edited (see CLINE_MCP_SETTINGS_PATH in step 3).

Bridge is unavailable

The sidecar starts but nothing answers. Start IconVectors, match the port to 61337 or your Options/McpPort value, then verify with app_getInfo that the application, workspace and document are the ones you expect.

A call times out

Restart the server from the MCP panel. Then work out which timeout fired. Cline has its own request timeout; separately, the sidecar's application-bridge send and receive timeout is 10 seconds. If IconVectors is busy or unresponsive, it's the second one, and checking application responsiveness comes before adjusting anything on the Cline side.

Wrong state

Inspect again before mutating. Don't fabricate a selection to get a call to run, and don't force a document replacement. With several IconVectors instances open, give each its own port and confirm identity with app_getInfo before any change.

Path or output fails

Use native absolute Windows paths: quote executable paths in shell commands and escape the backslashes in JSON. A path inside a client sandbox, a container or WSL isn't a path the desktop application can see. For output, ask for bounded DOM, SVG or preview results instead of the whole document.

For the current setup controls in Cline itself, see the official Cline MCP documentation.

If you don't have IconVectors yet, download the free trial and start at step 1.