Connect Ollama to Databases and APIs With MCP: Local Agent Setup 2026

Quick Facts

• Protocol: JSON-RPC 2.0 over stdio (local subprocess) or HTTP/SSE (remote). Local agents use stdio almost exclusively.
• Maintained by: Anthropic (open-source spec); reference servers maintained in modelcontextprotocol/servers on GitHub plus a growing third-party ecosystem.
• Local clients in 2026: Goose (Block), 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. In May 2026: Gemma 4 27B, GLM-5.1 32B, Qwen3 32B, Qwen3-Coder 30B, Llama 3.3 70B.
• Server transport defaults: stdio for local processes; HTTP/SSE only when you need to share a server across machines or agents.
• Configuration lives in one file: ~/.config/goose/config.yaml (Goose), the MCP block of ~/.continue/config.json (Continue.dev), or mcpServers in Cline's settings UI. Same shape across all of them: server name, command, args, env vars.
• No Claude Desktop required. The protocol predates Claude Desktop's exclusivity stories; every reference server is MIT/Apache-licensed and runs 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." — puppeteer server drives a headless 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."** — 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."** — sqlite server queries; 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, sqlite.query, puppeteer.navigate. 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 27B (gemma4:27b), GLM-5.1 32B (glm5:32b), Qwen3 32B (qwen3:32b), or Llama 3.3 70B (llama3.3:70b). 16 GB unified memory or 12 GB VRAM handles 27B–32B at Q4_K_M comfortably.
• Step 3 — install Goose. pipx install goose-ai (macOS, Linux) or download the installer from the Goose releases page. 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. Goose writes this to ~/.config/goose/config.yaml.
• Step 5 — add the filesystem MCP server. Edit ~/.config/goose/config.yaml to add a mcpServers block (config example below). Restart 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:27b

# 2. Install Goose
pipx install goose-ai

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

# 4. Start a session — Goose reads ~/.config/goose/config.yaml
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). Goose, Cline, and Continue.dev all auto-spawn it from the config block.
• 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
mcpServers:
  filesystem:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-filesystem"
      - "/Users/you/agent-workspace"
    env: {}

SQLite and Postgres Servers: Query Real Data

• **SQLite server (@modelcontextprotocol/server-sqlite)** takes a path to a .db file. Useful for log analysis, prototyping schemas, and exploring exports without spinning up a database.
• **Postgres server (@modelcontextprotocol/server-postgres)** takes a connection string. The recommended pattern is to create a dedicated read-only role for the agent and use that role's connection string.
• Tools exposed: query (SELECT only when configured read-only), list_tables, describe_table. The Postgres server adds list_schemas. Some forks add write_query — leave it disabled unless you trust the model on this database.
• 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 called describe_table 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
mcpServers:
  sqlite:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-sqlite"
      - "--db-path"
      - "/Users/you/data/events.db"
    env: {}

  postgres:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-postgres"
      - "postgresql://agent_ro@127.0.0.1:5432/analytics"
    env:
      PGPASSWORD: "${PG_AGENT_PASSWORD}"

Browser Server: Drive Chromium With Puppeteer or Playwright

• Reference servers: @modelcontextprotocol/server-puppeteer (lighter, headless by default) and @modelcontextprotocol/server-playwright (heavier, supports multiple browsers). For local agents, Puppeteer is enough.
• Tools exposed: navigate, screenshot, click, fill, select, evaluate (run JavaScript), get_page_content. The model uses get_page_content to read structured text and screenshot to confirm visually.
• 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.
• Selectors: the model has to pick CSS selectors. Smaller models guess wrong 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
mcpServers:
  puppeteer:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-puppeteer"
    env:
      PUPPETEER_HEADLESS: "true"
      # 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: @modelcontextprotocol/server-github, run with a PAT in the GITHUB_PERSONAL_ACCESS_TOKEN env var. The token is the only auth — the server itself has no separate config.
• 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 dozens 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
mcpServers:
  github:
    command: npx
    args:
      - "-y"
      - "@modelcontextprotocol/server-github"
    env:
      GITHUB_PERSONAL_ACCESS_TOKEN: "${GH_AGENT_PAT}"
      # 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 27B (gemma4:27b)** — 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-5.1 32B (glm5:32b)** — 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 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.

Sources

• Model Context Protocol Specification — Official spec, JSON-RPC schema, transport and lifecycle definitions.
• modelcontextprotocol/servers GitHub repository — Reference servers (filesystem, sqlite, postgres, github, puppeteer, etc.) and their configuration documentation.
• Goose Project Documentation — CLI install, Ollama provider configuration, 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.

FAQ

Related Reading

• Best Local Models for Tool Calling in 2026 — head-to-head benchmarks for the models recommended above (Gemma 4, GLM-5.1, 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.