Ollama MCP Setup 2026: Connect Local Models to Files, Databases and APIs

Quick Facts

• Protocol: JSON-RPC 2.0 over stdio (local subprocess) or Streamable HTTP (remote). The older HTTP+SSE transport is deprecated. Local agents use stdio almost exclusively. The current specification revision is 2026-07-28.
• Origin: created by Anthropic as an open specification (modelcontextprotocol.io). Only a few reference servers are still maintained in modelcontextprotocol/servers (filesystem, git, fetch, memory, and others); SQLite, PostgreSQL, Puppeteer and GitHub moved to servers-archived. Vendors now ship their own servers.
• Local clients: Goose (open source, repo aaif-goose/goose), Cline (VS Code extension), Continue.dev (VS Code/JetBrains), LM Studio (desktop app), plus several CLI tools.
• Compatible Ollama models: any model with native tool-call training, for example Gemma 4 31B, GLM-4.7 Flash, Qwen3.6 27B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• Server transport defaults: stdio for local processes; Streamable HTTP only when you need to share a server across machines or agents.
• Configuration lives in the client: Goose reads an extensions block in ~/.config/goose/config.yaml (or goose configure); Cline and Continue.dev have their own MCP settings. The fields are the same idea everywhere: server name, command, args, env vars.
• No Claude Desktop required. The protocol is open and independent of Claude Desktop; the servers used here are open source (check each licence) and run against any compliant client.

What MCP Actually Unlocks for a Local Model

• "Find every TODO in this repo, group them by file, and write a Markdown summary to notes/todos.md." — filesystem server reads, the model groups, the same server writes. One round trip end-to-end.
• "Show me the top 10 customers by revenue this quarter, then chart it." — postgres server runs the SQL (read-only role), the model summarises, the model writes a CSV via filesystem for your charting tool.
• "Open the Hacker News front page, find the top three AI stories, summarise them, and append to my reading list." — playwright server drives a browser, the model extracts and summarises, filesystem appends.
• "Open a draft PR titled chore: bump deps against my fork and link the failing CI run." — the github server creates the PR, fetches the run, and writes the link in the description.
• "Look at the last 100 rows of events.db and tell me which user IDs are responsible for the new error spike." — a database server queries a copy of the data; the model reasons; you read the answer in the chat panel.
• Each of these is a sentence-to-action workflow that previously required either a cloud model with hosted tools or a hand-rolled script. MCP is the layer that lets you reuse the same servers across clients and the same model across servers.

How the Four Most-Used MCP Servers Compare

How the Pieces Fit Together

• Ollama runs as a background service on 127.0.0.1:11434 and serves the model through an OpenAI-compatible API. It does not know what MCP is — it just answers chat completions and emits tool calls when the model asks for them.
• MCP client (Goose, Cline, Continue.dev, LM Studio) is the bridge. It talks to Ollama for the model and to MCP servers for tools. When the model emits a tool call, the client routes it to the right server, gets the result, and feeds it back into the conversation.
• MCP servers are independent subprocesses, one per capability. They speak JSON-RPC 2.0 over stdio. Each server advertises a list of Tools, Resources, and Prompts; the client merges them into the tool surface presented to the model.
• Stdio transport keeps everything local. A server is launched by the client, communicates over its stdin/stdout, and exits when the client exits. Nothing routes through the network unless the server itself opens a connection (the browser server does; filesystem and database servers do not).
• The model sees one flat tool list. From the model's perspective there are no servers — just a list of tool names like filesystem.read_file, playwright.browser_navigate, github.create_pull_request. The client handles routing.

Setup: Ollama + Goose in 15 Minutes

• Step 1 — install Ollama. Download from ollama.com/download (macOS/Windows/Linux). Confirm the service is running with curl http://127.0.0.1:11434/api/tags.
• Step 2 — pull a tool-calling model. Pick from Gemma 4 31B (gemma4:31b), GLM-4.7 Flash (glm-4.7-flash), Qwen3.6 27B (qwen3.6:27b), Qwen3 32B (qwen3:32b), or Llama 3.3 70B (llama3.3:70b). 32 GB unified memory or 24 GB VRAM handles 26B–32B at Q4_K_M comfortably.
• Step 3 — install Goose. On macOS or Linux run curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash (or brew install block-goose-cli). On Windows use the PowerShell installer from the Goose docs, or WSL. The CLI installs as goose.
• Step 4 — configure Ollama as the provider. Run goose configure, pick ollama as the provider, set the model to the one you pulled, and set the host to http://127.0.0.1:11434 (blank also means localhost:11434). Goose writes this to ~/.config/goose/config.yaml. Ollama's default context window can be small (the Goose docs mention 4096 tokens), which can make Goose ignore its extensions — start Ollama with OLLAMA_CONTEXT_LENGTH=32768 (or higher).
• Step 5 — add the filesystem MCP server. Run goose configure, choose Add Extension, then Command-line Extension, or add an extensions block to ~/.config/goose/config.yaml (example below). For a one-off test, goose session --with-extension "npx -y @modelcontextprotocol/server-filesystem /path/to/workspace" enables it for that session only. Start goose session and ask it to list files in your test directory. The first turn confirms the server is wired up.
• Step 6 — verify with a real task. Try goose session and ask "Make a list of every Markdown file in notes/, with title and word count, and write the result to notes/index.md." If the agent reads, summarises, and writes back, the loop works.

# 1. Pull a tool-calling model
ollama pull gemma4:31b

# 2. Install Goose (macOS / Linux)
curl -fsSL https://github.com/aaif-goose/goose/releases/download/stable/download_cli.sh | bash

# 3. Configure Ollama as the provider
goose configure
# Provider: ollama
# Model:    gemma4:31b
# Host:     http://127.0.0.1:11434

# 4. Give Ollama a context window big enough for tool use, then start a session
OLLAMA_CONTEXT_LENGTH=32768 ollama serve   # in a separate terminal
goose session

Filesystem Server: Read and Write a Sandboxed Directory

• Install: the reference server is @modelcontextprotocol/server-filesystem, run via npx -y (no global install needed; Node.js required). It is one of the reference servers that is still maintained. Goose, Cline, and Continue.dev all spawn it from their config.
• Allow-list paths: the server takes one or more directory arguments and refuses operations outside them. Always pass an explicit, narrow path — never ~ or /.
• Tools exposed: read_file, read_multiple_files, write_file, edit_file (line-based replacements), list_directory, search_files, move_file, create_directory, directory_tree. The model sees this as filesystem.read_file and so on.
• Quality-of-life: directory_tree returns a JSON tree; ideal for the model to orient itself before reading specific files. search_files does grep-like recursive search.
• Risk surface: the server respects the allow-list, but inside that list it has full read/write. Treat the allow-list as the only barrier and pick a dedicated workspace directory rather than your home folder.

# ~/.config/goose/config.yaml
extensions:
  filesystem:
    type: stdio
    name: filesystem
    enabled: true
    cmd: npx
    args: ["-y", "@modelcontextprotocol/server-filesystem", "/Users/you/agent-workspace"]
    envs: {}
    timeout: 300

Database Servers: Query Postgres (and SQLite) Safely

• Postgres: postgres-mcp (Crystal DBA, MIT licence) is the option with a read-only mode (the latest PyPI release is from May 2025, so check the repository's activity before you rely on it). Run it with uvx postgres-mcp --access-mode=restricted (or pipx install postgres-mcp, or its Docker image) and pass the connection URI in the DATABASE_URI environment variable. Restricted mode allows read-only transactions and a query time limit; unrestricted mode is for development only.
• Use a dedicated read-only role as well. Restricted mode is one barrier, the database role is another. Create an agent_ro role with SELECT-only grants and use that role's connection string.
• SQLite: the reference server is archived. It is the Python package mcp-server-sqlite (not an npm package; last release April 2025), it may still run, but it gets no fixes. Point it only at a copy of the file, never at your only copy, or load the data into Postgres instead. Read the code of any community SQLite server before you give it a file.
• Schema awareness: ask the agent "list the tables and describe the most-used five" before asking analytical questions — the model is much more accurate when it has inspected the schema than when it guesses column names.
• Cost: queries hit your database directly. A poorly-formed SELECT * from a 100 M row table is the same accident here as it would be from a human — keep the role on a separate connection pool with a statement timeout.

# ~/.config/goose/config.yaml
extensions:
  postgres:
    type: stdio
    name: postgres
    enabled: true
    cmd: uvx
    args: ["postgres-mcp", "--access-mode=restricted"]
    envs:
      DATABASE_URI: "postgresql://agent_ro:${PG_AGENT_PASSWORD}@127.0.0.1:5432/analytics"
    timeout: 300

Browser Server: Drive a Browser With Playwright MCP

• Which server: use Microsoft's @playwright/mcp (npx @playwright/mcp@latest). The old @modelcontextprotocol/server-puppeteer is marked "no longer supported", and no @modelcontextprotocol/server-playwright package exists on npm.
• Tools exposed: browser_navigate, browser_snapshot, browser_click, browser_type, browser_fill_form, browser_evaluate (run JavaScript), browser_take_screenshot, browser_tabs, browser_wait_for. The model reads the page through browser_snapshot (an accessibility snapshot, which Playwright MCP recommends over screenshots for taking actions) and uses screenshots only to look.
• Latency: real browser sessions take 1–5 seconds per action. A multi-step browse easily consumes 30–60 seconds and tens of thousands of tokens because page content is large. Use a 32K+ context window.
• Element references: the model clicks elements by the references in the snapshot. Smaller models pick the wrong one often; a 27B+ tool-calling model handles common patterns reliably. Keep tasks scoped — "extract the title and first paragraph of this URL" is much more reliable than "navigate the site and find the contact page".
• The right use cases: research (open the page, summarise it, append to notes), regression testing (navigate, click, screenshot), and form-filling on pages you control. The wrong use cases: anything where a misclick on the live web has consequences.

# ~/.config/goose/config.yaml
extensions:
  playwright:
    type: stdio
    name: playwright
    enabled: true
    cmd: npx
    args: ["@playwright/mcp@latest"]
    envs: {}
    timeout: 300
# Block obviously dangerous endpoints at the OS firewall level
# rather than relying on the agent to refuse them.

GitHub Server: Repos, Issues, and PRs From a Local Model

• Install: use GitHub's official github/github-mcp-server, run from its Docker image (ghcr.io/github/github-mcp-server) with a PAT in the GITHUB_PERSONAL_ACCESS_TOKEN env var. The old @modelcontextprotocol/server-github npm package is marked "no longer supported"; do not use it for new setups.
• Tools exposed: search_repositories, get_file_contents, create_or_update_file, create_pull_request, list_issues, create_issue, add_issue_comment, merge_pull_request, plus many more. The full surface is large; most tasks use 5–10 tools.
• Scope the PAT. Use a fine-grained PAT scoped to specific repos with the minimum permissions required (Read for browsing, Write for PR/issue creation). Do not use a classic PAT with repo for an experimental agent.
• Real workflows: triage ("read the last 20 open issues, group them, draft labels"), drafting ("read the README and open a PR fixing typos"), reporting ("which PRs are stale this week").
• Risk surface: the agent can create issues and PRs, comment on them, and (with write permissions) push commits. Disable merge tools unless you trust both the model and the workflow — a misclicked merge in a fine-grained-PAT repo is recoverable, but only if you notice quickly.

# ~/.config/goose/config.yaml
extensions:
  github:
    type: stdio
    name: github
    enabled: true
    cmd: docker
    args: ["run", "-i", "--rm", "-e", "GITHUB_PERSONAL_ACCESS_TOKEN", "ghcr.io/github/github-mcp-server"]
    envs:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
    timeout: 300
# Fine-grained PAT scoped to one or two test repos,
# not your personal account-wide classic token.

A Security Model That Does Not Trust the Model

• Sandbox the filesystem server to one directory. Never ~ or /. Pick a agent-workspace/ folder and put copies of the files the agent needs to touch in there. If the agent goes wrong, the worst case is one folder.
• Run database servers read-only by default. A dedicated agent_ro role with SELECT-only grants and a 30-second statement timeout removes a class of incidents entirely.
• Gate every write or shell tool behind explicit approval. Goose, Cline, and Continue.dev each support per-tool approval rules. Allow read tools by default; require approval for write_file, edit_file, execute_command, create_pull_request, and any browser action that submits forms.
• Use the audit log. Every MCP client logs tool calls and results. After a long session, scan the log: you will catch the model trying things you did not expect (sometimes harmless, sometimes worth a permission tighten).
• Token-scope third-party access narrowly. GitHub PATs scoped to two test repos. Postgres roles read-only. Browser sessions without credentials. The model will eventually try things you did not anticipate; the limits on what it can do should not depend on the model getting it right.
• Air-gap the agent for sensitive data work. Disable network access on the host while running the agent (or use a network namespace) when working with private data. The local stack already has nothing leaving the machine, but defense-in-depth catches mistakes in third-party servers.
• Treat MCP server selection like any dependency choice. The reference servers are well-maintained; many third-party servers are not. Read the server's code before installing one that needs credentials.

Local MCP vs Claude Desktop: What Changes, What Stays

Picking a Tool-Calling Model for Local MCP

• Gemma 4 31B (gemma4:31b) — Google's tool-call training is best-in-class for the size. Fits in 16 GB unified memory or 24 GB VRAM at Q4_K_M. Good general reasoning; somewhat conservative on chained tool calls.
• GLM-4.7 Flash (glm-4.7-flash) — Zhipu's model has very strong tool-call reliability and a 128K context window out of the box. Slightly heavier than Gemma 4; fits comfortably on a 24 GB GPU.
• Qwen3.6 27B (qwen3.6:27b) — the newer Qwen option on Ollama (about 18–19 GB, 256K context, tool calling supported). Qwen3 32B (qwen3:32b) — well-rounded; the dense 32B handles MCP cleanly and is happy in a long agent loop. Qwen3-Coder 30B (qwen3-coder:30b) is the best pick if your agent work is code-shaped.
• Llama 3.3 70B (llama3.3:70b) — the highest ceiling but the heaviest. 48 GB+ unified memory or 2× 24 GB GPUs at Q4_K_M. Use only if your hardware accommodates it; the smaller models are usually enough.
• Avoid for MCP work: anything under 7B and any general-purpose model without explicit tool-call training. They will emit malformed calls, the loop will stall, and you will blame the harness — but the harness is fine.
• For structured prompting techniques that improve tool-call quality on any model, see chain-of-thought prompting.
• For the head-to-head data, see Best Local Models for Tool Calling in 2026.

MCP vs Plain Function Calling: What Is the Difference

• Function calling is the LLM-side capability: the model emits a structured JSON object describing the tool name and arguments. OpenAI tools, Anthropic tools, and Ollama's tool-call API all use the same idea with slightly different wire formats.
• MCP sits on top: it standardises how tools are described, discovered, invoked, and returned, across processes. A function-calling model on its own knows nothing about your filesystem; an MCP server makes filesystem operations available, the client maps them to the model's function-calling API, and the model can now call them.
• The benefit is interop. Write the filesystem server once; Claude Desktop, Goose, Cline, Continue.dev, and LM Studio all use it unchanged. Switch the model from Claude to Gemma 4; the server does not change.
• You can do agents with raw function calling. You will reimplement filesystem, database, and browser handlers per project. With MCP, those are out-of-the-box dependencies.
• For one-off scripts, raw function calling is simpler. For anything you want to reuse across projects or models, MCP is the lower-effort path within a few days.

Common Mistakes Setting Up Local MCP

• Mistake 1: using a small general-purpose model. Models under 7B (and most 7B–13B general-purpose models without tool-call fine-tuning) emit malformed tool calls. Use a 27B+ tool-call-tuned model and stop fighting the harness.
• Mistake 2: allow-listing your home directory. "Just for testing" allow-listings of ~ survive into routine use. Create a dedicated agent-workspace from the start.
• Mistake 3: leaving the database server in read/write mode. A DELETE query authored by a confident agent on a real table is exactly the incident this avoids. Make agent_ro your default; spin up a separate writable role only for tasks that explicitly need it, and only for the duration of those tasks.
• Mistake 4: auto-approving every tool. The "approve all" toggle is convenient and dangerous. Auto-approve read tools (read_file, list_directory, query); always require approval for write/shell/PR tools.
• Mistake 5: running a 32K-context model on multi-step browser work. Page content is large; an agent that browses three pages can blow through 32K tokens before reasoning. Use a 128K-context model for browser-heavy tasks.
• Mistake 6: assuming the agent has judgment. It does not. The model has no concept of "this is the production database" or "this PR will deploy". Permissions are your only barrier.
• Mistake 7: installing every reference server up front. More tools = larger system prompt = slower and less reliable tool selection. Start with filesystem. Add the others only when you have a workflow that needs them.
• Mistake 8: installing archived reference servers from old tutorials. The npm packages @modelcontextprotocol/server-postgres, -puppeteer and -github are marked "no longer supported" and the SQLite server is archived. Some older guides also name npm packages that do not exist (server-sqlite, server-playwright). Use the maintained servers named above.
• Mistake 9: putting MCP config into Ollama. Ollama has no MCP settings. Servers are configured in the client (Goose extensions, Cline or Continue.dev MCP settings).

Sources

• Model Context Protocol Specification — Official spec, JSON-RPC schema, transport and lifecycle definitions, including the 2026-07-28 changelog.
• modelcontextprotocol/servers GitHub repository — The maintained reference servers (filesystem, git, fetch, memory and others) and the list of archived servers.
• github/github-mcp-server — GitHub's official MCP server, Docker and binary setup.
• microsoft/playwright-mcp — Playwright MCP server and its browser tools.
• crystaldba/postgres-mcp — Postgres MCP server with restricted (read-only) access mode.
• Goose Documentation — CLI install, Ollama provider configuration, extension (MCP server) config syntax.
• Ollama Model Library — Available local models, tool-call support flags, and quantization levels referenced in this guide.
• Cline GitHub Repository — VS Code MCP client implementation, MCP servers panel.
• Continue.dev Documentation — mcpServers config block reference for the Continue.dev client.

Frequently Asked Questions

Related Reading

• Best Local Models for Tool Calling in 2026 — head-to-head benchmarks for the models recommended above (Gemma 4, GLM-4.7, Qwen3, Llama 3.3).
• Autonomous Local Agents Actually Work — a reality check on what a local MCP agent can and cannot reliably do over a long-running task.
• Continue.dev vs Cline vs Aider: Best Local Coding Agent in 2026 — adjacent agent context for coding-shaped work; Cline and Continue.dev are also MCP clients.
• Best Local LLMs in 2026 — model authority for the broader open-weights landscape.
• Replace Zapier With Local AI Agents — workflow-automation framing for the same MCP stack.
• Power Local LLM Hub — full guide library.