Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

MCP doesn't need tools, it needs code

lucumr.pocoo.org

Post reply on HN
Print view View original

101–110 of 146 posts

Re: MCP doesn't need tools, it needs code

#101

Post by pegasus »

juanviera23 wrote: post #15

I agree MCP has these flaws, idk why we need MCP servers when LLMs can just connect to the existing API endpoint Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut... even connects to MCP servers if you take a loo…

What you're building makes a lot of sense to me. The communication indirection MCP use frequently introduces bothers me, as well as the duplication of effort when it comes to e.g. the OpenAPI spec. I'll keep an eye on this repo and plan to give it a spin sometime (though I wish there was a typescript version too).

Re: MCP doesn't need tools, it needs code

#102

Post by cgriswald »

mdaniel wrote: post #87
cgriswald wrote: post #33

Earlier quoted context omitted.

Just so folks who want to do this know, the proper way to introduce an initialism is to use the full term on first use and put the initialism in parentheses. Thereafter just use the initialism. Always consider your audience, but for most non-casual writing it’s a good default for a variety of reasons.

You're welcome to do that in print media, but on the web the proper way is the abbr element with its title attribute https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... >. Related to the distinction, I'd bet $1 there's some fancy CSS that would actually expand the definition under @media print I can attest the abbr is also mobile friendly, although I am for sure open to each browser doing its own UI hinti…

From your source:

> Spelling out the acronym or abbreviation in full the first time it is used on a page is beneficial for helping people understand it, especially if the content is technical or industry jargon.

> Only include a title if expanding the abbreviation or acronym in the text is not possible. Having a difference between the announced word or phrase and what is displayed on the screen, especially if it's technical jargon the reader may not be familiar with, can be jarring.

Re: MCP doesn't need tools, it needs code

#103

Post by dragonwriter »

throwmeaway222 wrote: post #98
dragonwriter wrote: post #92

Earlier quoted context omitted.

> problem with MCP right now is that LLMs don't natively know what it is Most models that it is used with natively know what tools are (they are trained with particular prompt formats for the use of arbitrary tools), and the model never sees MCP at all, it just sees tool definitions, or tool responses, in the format it expects in prompts. MCPs are a way to communicate information about tools to the toolchain running…

No that's not what I'm saying. If you tell an LLM that you need a report on a specific member of congress and provide a prompt saying you can use bash tools like grep/curl/ping/git/etc... just return bash then a formatted code block Or you can use fetch_record followed by a formatted code block of the name of a google search you want to perform. The LLM will likely use bash and curl because it NATIVELY knows what it…

It's possible that its not about "native knowledge" but about how the descriptions (which get mapped into the prompt) for each of the tools are setup (or even their order; LLM behavior can be very sensitive to not-obviously-important prompt differences.)

I'd be cautious inferring generalizations about behavior and then explanations of those generalizations from observation of a particular LLM used via a particular toolchain.

That said, that it does that in that environment is still an interesting observation.

Re: MCP doesn't need tools, it needs code

#104

Post by lkjdsklf »

sam0x17 wrote: post #73

Yeah I quite agree with this take. I don't understand why editors aren't utilizing language servers more for making changes. Crazy to see agents running grep and sed and awk and stuff, all of that should be provided through a very efficient cursor-based interface by the editor itself. And for most languages, they shouldn't even be operating on strings, they should be operating on token streams and ASTs

There's a few agents that integrate with LSP servers

opencode comes to mind off the top of my head

it still tends to do a lot of grep and sed though.

Re: MCP doesn't need tools, it needs code

#105

Post by crazygringo »

mdaniel wrote: post #87
cgriswald wrote: post #33

Earlier quoted context omitted.

Just so folks who want to do this know, the proper way to introduce an initialism is to use the full term on first use and put the initialism in parentheses. Thereafter just use the initialism. Always consider your audience, but for most non-casual writing it’s a good default for a variety of reasons.

You're welcome to do that in print media, but on the web the proper way is the abbr element with its title attribute https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... >. Related to the distinction, I'd bet $1 there's some fancy CSS that would actually expand the definition under @media print I can attest the abbr is also mobile friendly, although I am for sure open to each browser doing its own UI hinti…

Please read your own link. It literally says to put the definition in parentheses (same as print) on first use. Second paragraph.

is not what you seem to think it is. But the "typical use cases" section of your link does explain what it's actually for.

Re: MCP doesn't need tools, it needs code

#106

Post by jethack »

mdaniel wrote: post #87
cgriswald wrote: post #33

Earlier quoted context omitted.

Just so folks who want to do this know, the proper way to introduce an initialism is to use the full term on first use and put the initialism in parentheses. Thereafter just use the initialism. Always consider your audience, but for most non-casual writing it’s a good default for a variety of reasons.

You're welcome to do that in print media, but on the web the proper way is the abbr element with its title attribute https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/... >. Related to the distinction, I'd bet $1 there's some fancy CSS that would actually expand the definition under @media print I can attest the abbr is also mobile friendly, although I am for sure open to each browser doing its own UI hinti…

Sadly abbr with title doesn't work at all on mobile Chrome [1] or Firefox [2]. Probably not Safari either, since long press on mobile means "select text" so you'd have to do some CSS trickery (and trying to hit a word-sized target with a finger is quite annoying).

[1] https://issues.chromium.org/issues/337222647 -> https://issues.chromium.org/issues/41130053

[2] https://bugzilla.mozilla.org/show_bug.cgi?id=1468007

Re: MCP doesn't need tools, it needs code

#107

Post by juanviera23 »

pegasus wrote: post #101
juanviera23 wrote: post #15

I agree MCP has these flaws, idk why we need MCP servers when LLMs can just connect to the existing API endpoint Started on working on an alternative protocol, which lets agents call native endpoints directly (HTTP/CLI/WebSocket) via “manuals” and “providers,” instead of spinning up a bespoke wrapper server: https://github.com/universal-tool-calling-protocol/python-ut... even connects to MCP servers if you take a loo…

What you're building makes a lot of sense to me. The communication indirection MCP use frequently introduces bothers me, as well as the duplication of effort when it comes to e.g. the OpenAPI spec. I'll keep an eye on this repo and plan to give it a spin sometime (though I wish there was a typescript version too).

there is a TS version actually, all the SDKs are here: https://github.com/universal-tool-calling-protocol

Re: MCP doesn't need tools, it needs code

#108

Post by starkparker »

turnsout wrote: post #84

> One surprisingly useful way of running an MCP server is to make it an MCP server with a single tool (the ubertool) which is just a Python interpreter that runs eval() with retained state. Wow, you better be sure you have that Python environment locked down.

yeah, check out the article's "Security is a Sham" heading that explicitly covers why the author doesn't really give a shit

Re: MCP doesn't need tools, it needs code

#109

Post by CharlieDigital »

mdaniel wrote: post #94
CharlieDigital wrote: post #19

A few weeks back, I actually started working on an MCP server that is designed to let the LLM generate and execute JavaScript in a safe, sandboxed C# runtime with Jint as the interpreter. https://github.com/CharlieDigital/runjs Lets the LLM safely generate and execute whatever code it needs. Bounded by statement count, memory limits, and runtime limits. It has a built in secrets manager API (so generated code can mak…

I don't meant to throw shade on your toy, but trying to get a prediction model to use a language that actively hates developers is a real roll-the-dice outcome

Which language? C# or JS? OpenAI and Claude are quite good at JS. The runtime is C# to sandbox the execution so it is not being generated.

Re: MCP doesn't need tools, it needs code

#110

Post by skybrian »

fny wrote: post #99
sam0x17 wrote: post #73

Yeah I quite agree with this take. I don't understand why editors aren't utilizing language servers more for making changes. Crazy to see agents running grep and sed and awk and stuff, all of that should be provided through a very efficient cursor-based interface by the editor itself. And for most languages, they shouldn't even be operating on strings, they should be operating on token streams and ASTs

Strings are a universal interface with no dependencies. You can do anything in any language across any number of files. Any other abstraction heavily restricts what you can accomplish. Also, LLMs aren't trained on ASTs, they're trained on strings -- just like programmers.

No, it’s not really “any string.” Most strings sent to an interpreter will result in a syntax error. Many Unix commands will report an error if you pass in an unknown flag.

In theory, there is a type that describes what will parse, but it’s implicit.

Post reply on HN