←back to thread

Tools: Code Is All You Need

(lucumr.pocoo.org)
313 points Bogdanp | 2 comments | | HN request time: 0.001s | source
Show context
JyB ◴[] No.44455663[source]
> It demands too much context.

This is solved trivially by having default initial prompts. All majors tools like Claude Code or Gemini CLI have ways to set them up.

> You pass all your tools to an LLM and ask it to filter it down based on the task at hand. So far, there hasn't been much better approaches proposed.

Why is a "better" approach needed? If modern LLMs can properly figure it out? It's not like LLMs don't keep getting better with larger and larger context length. I never had a problem with an LLM struggling to use the appropriate MCP function on it's own.

> But you run into three problems: cost, speed, and general reliability

- cost: They keep getting cheaper and cheaper. It's ridiculously inexpensive for what those tools provide.

- speed: That seem extremely short sighted. No one is sitting idle looking at Claude Code in their terminal. And you can have more than one working on unrelated topics. That defeats the purpose. No matter how long it takes the time spent is purely bonus. You don't have to spend time in the loop when asking well defined tasks.

- reliability: Seem very prompt correlated ATM. I guess some people don't know what to ask which is the main issue.

Having LLMS being able to complete tedious tasks involving so many external tools at once is simply amazing thanks to MCP. Anecdotal but just today it did a task flawlessly involving: Notion pages, Linear Ticket, git, GitHub PR, GitHub CI logs. Being in the loop was just submitting one review on the PR. All the while I was busy doing something else. And for what, ~1$?

replies(2): >>44455696 #>>44455713 #
the_mitsuhiko ◴[] No.44455696[source]
> This is solved trivially by having default initial prompts. All majors tools like Claude Code or Gemini CLI have ways to set them up.

That only makes it worse. The MCP tools available all add to the initial context. The more tools, the more of the context is populated by MCP tool definitions.

replies(1): >>44455784 #
JyB ◴[] No.44455784[source]
Do you mean that some tools (MCP clients) pass all functions of all configured MCP servers in the initial prompt?

If that's the case: I understand the knee-jerk reaction but if it works? Also what theoretically prevents altering the prompt chaining logic in these tools to only expose a condensed list of MCP servers, not their whole capabilities, and only inject details based on LLM outputs? Doesn't seem like an insurmountable problem.

replies(1): >>44456334 #
1. the_mitsuhiko ◴[] No.44456334{3}[source]
> Do you mean that some tools (MCP clients) pass all functions of all configured MCP servers in the initial prompt?

Not just some, all. That's just how MCP works.

> If that's the case: I understand the knee-jerk reaction but if it works?

I would not be writing about this if it worked well. The data indicates that it worse significantly worse than not using MCP because of the context rot, and the low too utilization.

replies(1): >>44456533 #
2. JyB ◴[] No.44456533[source]
I guess I don't see the technical limitation. Seem like a protocol update issue.