Ollama Browser Automation with E2LLM

Ollama can provide the local model and tool-calling loop for browser automation. An MCP-capable host or adapter connects that loop to E2LLM, which supplies structured browser state and explicit browser actions through its remote MCP endpoint.

Understand the three parts

The working architecture has three distinct responsibilities:

  1. Ollama runs the model. Its local API is available by default at http://localhost:11434/api, and supported models can request tools inside a multi-turn agent loop.
  2. The host manages MCP. It connects to the remote server, presents the available tools to the model and returns tool results to the loop.
  3. E2LLM connects the browser. It exposes tab discovery, structured page capture, focused exploration and browser actions.

Ollama's tool-calling support does not by itself establish a remote MCP connection. Choose a host or adapter that supports remote MCP over URL and can use Ollama as its model provider.

Connect the browser tools

Use the E2LLM onboarding flow to connect a browser and obtain the MCP configuration for your host. The remote endpoint is https://mcp.e2llm.com/mcp.

After configuration, run an occurrence test:

  1. Call list_tabs and confirm the expected browser tab appears.
  2. Call sifr_capture on that tab and inspect the returned page structure.
  3. Ask the model to locate one visible control.
  4. Perform a low-risk action.
  5. Capture again and confirm the intended state change.

A configuration file that parses successfully proves only configuration. Real tool calls establish that the model, MCP host and browser connection work together.

Keep the local-model boundary clear

Running the model through Ollama can keep model inference on your machine. Browser tool calls still follow the data path of the MCP connection and the connected service. Review that path separately when local-only processing is a requirement.

Model choice also affects tool performance. Use a model with reliable tool calling, structured argument generation and enough context for the page state your workflow requires. Test the exact model and quantization you plan to run.

Build a bounded browser loop

Give the model one goal, the current page state and a small set of relevant tools. Require observation before action and verification afterward. Recapture when the page changes rather than carrying stale targets forward.

For a first workflow, choose something reversible: open an authenticated dashboard, locate a record, apply a filter and confirm the resulting list. Add submission or mutation only after the observation loop is stable.

Example host loop

The host sends the user's goal and the available E2LLM tool schemas to the Ollama model. When the model requests list_tabs, the host executes that MCP call and returns the result. The model selects a tab and requests sifr_capture. The host returns the structured snapshot, then executes the next tool request in the same way.

Stop the loop when the model produces a final answer, requests human review or reaches a configured bound. Persist enough state to distinguish a model response from a tool result and an attempted action from a verified outcome.

Common questions

Can Ollama connect directly to any MCP server?

Ollama documents model APIs and tool calling. The remote MCP connection is a responsibility of the host or adapter in this architecture. Verify that component against the E2LLM URL.

Does a local model make the complete workflow offline?

Local inference removes a remote model call. A remote MCP service and the target websites still require network communication. Review every component's data path before making an offline claim.

Why does the model matter after the tools connect?

The model must select tools, produce valid arguments and reason over returned page state. Smaller or heavily quantized models may behave differently. Run the same bounded browser proof on the exact model build you intend to use.

Copy this instruction into your Ollama agent

Use the E2LLM MCP tools for this browser task.
1. Call list_tabs and select the tab that matches the task.
2. Call sifr_capture before choosing an action.
3. Explain which current page evidence grounds the target.
4. Perform one reversible action.
5. Capture again and compare the result with the requested outcome.
6. Stop for human review before any consequential action or when the state is ambiguous.
Task: [describe the browser task]
Expected result: [describe the browser confirmation]

Connect E2LLM to your AI

To keep the workflow text-first, understand automation without vision models. For a concrete host connection example, follow the Claude Code browser-access workflow.