I've been using the DevTools MCP for months now, but it's extremely token heavy. Is there an alternative that provides the same amount of detail when it comes to reading back network requests?

▲

nerdsniper 11 hours ago | parent | next [-]

It's probably not fully optimized and could be compacted more with just some effort, and further with clever techniques, but browser state/session data will always use up a ton of tokens because it's a ton of data. There's not really a way around that. AI's have a surprising "intuition" about problems that often help them guess at solutions based on insufficient information (and they guess correctly more often than I expect they should). But when their intuition isn't enough and you need to feed them the real logs/data...it's always gonna use a bunch of tokens.

This is one place where human intuition helps a ton today. If you can find the most relevant snippets and give the AI just the right context, it does a much better job.

▲

11 hours ago | parent | prev | next [-]

[deleted]

▲

Torn 11 hours ago | parent | prev | next [-]

https://github.com/microsoft/playwright-cli and https://agent-browser.dev/

▲

DimitriBouriez 11 hours ago | parent | prev | next [-]

i'm experimenting with a different approach (no CDP/ARIA trees, just Chrome extension messaging that returns a numbered list of interactive elements). Way lighter on tokens and undetectable but still very experimental : https://github.com/DimitriBouriez/navagent-mcp

▲

mmaunder 11 hours ago | parent | prev [-]

Yes. CLI. Always CLI. Never MCP. Ever. You’re welcome.

▲

flash_us0101 4 hours ago | parent | next [-]

CLI is great when you know what command to run. MCP is great when the agent decides what to run - it discovers tools without you scripting the interaction.

The real problem isn't MCP vs CLI, it's that MCP originally loaded every tool definition into context upfront. A typical multi-server setup (GitHub, Slack, Sentry, Grafana, Splunk) consumes ~55K tokens in definitions before Claude does any work. Tool selection accuracy also degrades past 30-50 tools.

Anthropic's Tool Search fixes this with per-tool lazy loading - tools are defined with defer_loading: true, Claude only sees a search index, and full schemas load on demand for the 3-5 tools actually needed. 85% token reduction. The original "everything upfront" design was wrong, but the protocol is catching up.

▲

nerdsniper 11 hours ago | parent | prev [-]

That doesn't solve the issue here because the amount of data in the browser state dwarfs the MCP overhead.

	▲	bartek_gdn 10 hours ago \| parent \| next [-]
		Can't we just iteratively inspect the network traces then? We don't need to consume the whole 2mb of data, maybe just dump the network trace and use jq to get the fields to keep the context minimal. I haven't added this in https://news.ycombinator.com/item?id=47207790 , but I feel it would be a good addition. Then prompt it with instructions to gradually discover the necessary data. But then I wonder, where the balance is between a bunch of small tool calls, vs one larger one. I recall some recent discussion here on hn on big data analysis
	▲	cheema33 11 hours ago \| parent \| prev [-]
		> That doesn't solve the issue here because the amount of data in the browser state dwarfs the MCP overhead. The problem with MCP is that you are paying the price in token usage, even if you are not using the MCP server. Why would anybody want that? And no, the tool search function recently introduced by Anthropic does not completely solve this problem.