Feat/web search

[Justxd22]

This pull request adds support for a virtual "web-search" model that uses Gemini 2.5 Flash to perform Google searches via a new MCP tool, and integrates the results into the system in a user-friendly way. It introduces a new Python script for handling search requests, updates the API to recognize and route "web-search" requests, and enhances the response formatting to display search results clearly.

• Added a new Python script web_search_mcp.py that implements a minimal MCP server to handle Google Search requests using the Antigravity Proxy and returns results in a structured format.
• Updated the README.md with instructions for connecting the new Google Search tool and using it as a replacement for Claude's built-in search.
• Updated proxy files to support new model web-search

[Justxd22]

#275 #27

[Justxd22]

ss

[vedanth-jadhav]

this is awesome!

[Justxd22]

this is awesome!

Thanks! Hopefully it gets merged

[badrisnarayanan]

Thanks for this, taking a look now

[badrisnarayanan]

PR Review (by Claude Code)

Summary

This PR adds a virtual web-search model that routes to Gemini 2.5 Flash with Google Search grounding, plus a Python MCP server that Claude Code can use as a replacement for its built-in web search (which requires direct Anthropic API access).

---

Issues

Bugs

1. Overly broad model match (src/cloudcode/request-builder.js):

   if (model === 'web-search' || model.includes('web-search')) {

   The model.includes('web-search') is redundant (already covered by ===) and dangerously broad — any future model containing that substring would match. Should just be model === 'web-search'.

2. MCP protocol framing mismatch — The Python script uses newline-delimited JSON (readline()), but Claude Code's MCP client expects the standard MCP stdio transport with Content-Length headers. This script likely won't work as-is with claude mcp add.

3. No null check on query — In web_search_mcp.py, args.get("query") could be None, which would be passed directly to search() and sent as the message content.

Code Quality

4. Fragile search result injection — The logic in response-converter.js that appends search results to the first text block using anthropicContent.length === 0 && !part.thought is clever but hard to follow. A simpler approach: collect all text, then append search results at the end.

5. File placement — web_search_mcp.py is at the repo root. Should live in tools/ or scripts/.

6. Missing dependency documentation — The Python requests library needs to be installed, but there's no requirements.txt or install instruction.

7. No tests — No test coverage for the new model routing, grounding metadata parsing, or MCP server.

README

8. Multiple typos in the README addition:
   • "build-in" → "built-in"
   • "Antropic" → "Anthropic"
   • "preform" → "perform"
   • "reversed-enginnered" → "reverse-engineered"

---

Verdict

The idea is solid — providing web search for users who can't access Anthropic's native search — but the implementation needs work before merging. The MCP protocol framing issue (#4) is likely a showstopper that would prevent it from working at all. The missing model family registration (#2) and lack of streaming support (#3) would cause runtime errors or silent data loss.

[Justxd22]

https://ai.google.dev/gemini-api/docs/google-search

[badrisnarayanan]

@Justxd22 what do you mean by that link?

[Justxd22]

@badrisnarayanan i think this link is documenting the same workflow "ground search" that i copied from gemini-cli

[badrisnarayanan]

Okay, do you mind addressing the suggestions claude mentioned (in my previous comment)

[Justxd22]

sure, but for bugs:

• Overly broad model match: there's no web-search models so it wont conflict
• MCP protocol framing mismatch: not sure why it's complaining i tested it personally it worked fine, even posted a screenshot

i will push the rest

[Justxd22]

@badrisnarayanan done

[badrisnarayanan]

Thanks for the PR! The approach is solid. A few issues to address:

1. Byte-length bug in MCP server (web_search_mcp.py)

write_message() uses len(body) for Content-Length, but this counts characters, not bytes. Non-ASCII characters in search results (common with international queries) will cause framing errors.

# Bug:
header = f"Content-Length: {len(body)}\r\n\r\n"

# Fix:
body_bytes = body.encode('utf-8')
header = f"Content-Length: {len(body_bytes)}\r\n\r\n"
sys.stdout.buffer.write(header.encode('utf-8'))
sys.stdout.buffer.write(body_bytes)
sys.stdout.buffer.flush()

2. Hardcoded proxy URL and API key

Instead of hardcoding PROXY_URL and API_KEY, the MCP script can read directly from ~/.claude/settings.json — it already has apiBaseUrl and apiKey configured:

import os, json

def get_proxy_config():
    config_path = os.path.join(os.path.expanduser("~"), ".claude", "settings.json")
    with open(config_path) as f:
        config = json.load(f)
    base_url = config.get("apiBaseUrl", "http://localhost:8080")
    api_key = config.get("apiKey", "test")
    return f"{base_url}/v1/messages", api_key

Zero configuration needed — the MCP server reads the same config Claude Code uses.

3. No tests

There's no test coverage for the web-search model routing or grounding metadata conversion. At minimum, a test that sends a request with model: "web-search" and verifies the response contains search results would be good (similar to the existing tests in tests/).

[ayuuuvauuu]

great work ❤️

[Justxd22]

great work ❤️

Thanks!

[Justxd22]

@badrisnarayanan will fix