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.