[FEATURE] Pass through model from client/agent (no model endpoint config)

[dewdad]

I'm wondering how easy it would be to integrate the MCP client model interface with Archon, like https://github.com/vinayak-mehta/mcp-browser-use implemented.

This way you can use the model you're already paying for in your client app Cursor/Windsurf/ClaudeDesktop etc...

[coleam00]

Could you share more what exactly the MCP Browser Use implemented? Sounds great but I guess it isn't quite clicking with me what you mean.

[dewdad]

This MCP server acts as a browser automation bridge that delegates all reasoning tasks to the client agent (like Claude/GPT) while handling low-level browser operations. Here's the detailed breakdown of how it works:

---

1. No Independent Model Access

The server has zero LLM integration - no model initialization or API calls. Instead:

• All reasoning (e.g., "Which button to click next?") is handled by the client agent.
• The server only exposes browser automation tools (like click_element(), search_google()) via MCP protocol.

---

2. Client-Server Workflow

Phase 1: Initialization

• Client sends a task (e.g., "Book a flight to Paris") → Triggers initialize_browser().
• The server returns a system prompt with available actions (lines 44-56):

  "Available actions: initialize_browser, close_browser, search_google, ..."

  This guides the client agent on what tools it can use.

Phase 2: Execution Loop

1. Client Decides Actions: Uses its LLM to choose tools (e.g., search_google("flights to Paris")).
2. Server Executes: Runs the tool and returns results (e.g., "Searched for 'flights to Paris'").
3. Client Validates: May call inspect_page() to get DOM state (lines 231-239) for further decisions.

Phase 3: Completion

• Client calls done() when task is finished (lines 395-399).

---

3. Key Design Patterns

a. Stateful Browser Context

• Maintains global Browser and BrowserContext objects (lines 22-24) across tool calls.
• All tools interact with this shared state (e.g., browser_context.get_current_page()).

b. Tool-Centric Design

Each tool:

1. Takes simple inputs (e.g., index: int for click_element()).
2. Returns human-readable status messages (e.g., "Clicked button with index 3").
3. Handles errors gracefully (e.g., retries failed clicks in lines 142-169).

c. Client Guidance

• inspect_page() returns structured DOM info (lines 231-239) to help the client choose next actions.
• Tools include validation (e.g., validate_page()) for client-side verification.

---

4. Why No Model is Needed

1. Decision Offloading: The client agent handles all reasoning ("What to do next?").
2. Tool Simplicity: Each tool does one deterministic thing (e.g., go_to_url(url)).
3. MCP Protocol: Standardized JSON communication allows any client to use the tools.