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

Claude Advanced Tool Use

anthropic.com

Post reply on HN
Print view View original

221–230 of 280 posts

Re: Claude Advanced Tool Use

#221

Post by stpedgwdgfhgdd »

theknarf wrote: post #202

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

All for CLI tools, but they have their limits. Another party can update their mcp server and you get the new tools without a sweat.

E.g. with a Jira cli tool I have to write the skill and keep it up to date. With a MCP server I can delegate most of the work.

Re: Claude Advanced Tool Use

#222

Post by stpedgwdgfhgdd »

notpublic wrote: post #199
jimbo808 wrote: post #154

Earlier quoted context omitted.

Claude is pretty good at totally disregarding most of what’s in your CLAUDE.md, so I’m not optimistic. For example a project I work on gives it specific scripts to run when it runs automated tests, because the project is set up in a way that requires some special things to happen before tests will work correctly. I’ve never once seen it actually call those scripts on the first try. It always tries to run them using t…

Instead of including all these instructions in CLAUDE.md, have you considered using custom Skills? I’ve implemented something similar, and Skills works really well. The only downside is that it may consume more tokens.

The matching logic for a skill is pretty strict. I wonder whether mentioning ‘git’ in the front matter and using ‘gitlab’ would give a match for a skill to get triggered.

Re: Claude Advanced Tool Use

#223

Post by notpublic »

taytus wrote: post #218
notpublic wrote: post #199

Earlier quoted context omitted.

Instead of including all these instructions in CLAUDE.md, have you considered using custom Skills? I’ve implemented something similar, and Skills works really well. The only downside is that it may consume more tokens.

Yes, sometimes skills are more reliable, but not always. That is the biggest culprit to me so far. The fact that you cannot reliably trust these LLMs to follow steps or instructions makes them unsuitable for my applications.

Another thing that helps is adding a session hook that triggers on startup|resume|clear|compact to remind Claude about your custom skills. Keeps things consistent, especially when you're using it for a long time without clearing context

Re: Claude Advanced Tool Use

#224

Post by jlouis »

dcre wrote: post #105
jlouis wrote: post #36

Earlier quoted context omitted.

No. It's a way to transmit a program from client to server. It then executes that program on the server side.

That sounds even worse!

It's not. The fragments you can execute are limited if you do it right. A client isn't allowed to just execute anything it wants, because the valid operations are pre-determined. The client sends a reference which executes a specific pre-planned fragment of code.

In development, you let clients roam free, so you have access to the API in a full manner. Deployments then lock-down the API. If you just let a client execute anything it wants in production, you get into performance-trouble very easily once a given client decides to be adventurous.

GraphQL is an execution semantics. It's very close to a lambda calculus, but I don't think that was by design. I think that came about by accident. A client is really sending a small fragment of code to the server, which the server then executes. The closest thing you have is probably SQL queries: the client sends a query to the server, which the server then executes.

It's fundamental to the idea of GraphQL as well. You want to put power into the hands of the client, because that's what allows a top-down approach to UX design. If you always have to manipulate the server-side whenever a client wants to change call structure, you've lost.

Re: Claude Advanced Tool Use

#225

Post by notpublic »

esperent wrote: post #161
falcor84 wrote: post #134

Earlier quoted context omitted.

That's exactly what Claude Skills do [0], and while this tool search appears to be distinct, I do think that they're on the way to integrating MCP and Skills. [0] https://code.claude.com/docs/en/skills

I haven't had much luck with skills being called appropriately. When I have a skill called "X doer", and then I write a prompt like "Open and do X", it almost never loads up the skill. I have to rewrite the prompt as "Open and do X using the X doer skill". Which is basically exactly as much effort as what I was doing previously of having prewritten sub-prompts/agents in files and loading up the file each time I want…

Try adding a session hook that triggers on startup|resume|clear|compact to remind Claude about your custom skills.

Re: Claude Advanced Tool Use

#226

Post by xnorswap »

tomashubelbauer wrote: post #206
theknarf wrote: post #202

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

This would be awesome, but great CLIs would have already been valuable prior to the age of LLMs and yet most services didn't ship one. I think it is because services like Jira and others do not want to be too open. Ultimately, despite the current LLM/MCP craze, I think this won't change and MCP tools will start getting locked down and nerfed somehow, the same way APIs have in not so recent memory after there being a…

I agree with your conclusion that this stuff will get locked down again over time.

I think there's also another major reason people don't like to ship desktop software, and that's the cost of support of dealing with outdated tools, it can be immense.

Ticket as raised, "Why is my broken?"

After several rounds of clarification, it's established they're using a 6-year old version that's hitting API endpoints that were first deprecated 3 years ago and finally now removed...

It's incredibly expensive to support multiple versions of products. On-prem / self host means you have to support several, but at least with web products it's expected they'll phone-home and nag to be updated and that there'll be someone qualified to do that update.

When you add runnable executable tooling, it magnifies the issue of how old that tooling gets.

Even with a support policy of not supporting versions older than , you'll waste a lot of customer support time dealing with issues only for it to emerge it's out-dated software.

Re: Claude Advanced Tool Use

#227

Post by pferde »

xnorswap wrote: post #226
tomashubelbauer wrote: post #206

Earlier quoted context omitted.

This would be awesome, but great CLIs would have already been valuable prior to the age of LLMs and yet most services didn't ship one. I think it is because services like Jira and others do not want to be too open. Ultimately, despite the current LLM/MCP craze, I think this won't change and MCP tools will start getting locked down and nerfed somehow, the same way APIs have in not so recent memory after there being a…

I agree with your conclusion that this stuff will get locked down again over time. I think there's also another major reason people don't like to ship desktop software, and that's the cost of support of dealing with outdated tools, it can be immense. Ticket as raised, "Why is my broken?" After several rounds of clarification, it's established they're using a 6-year old version that's hitting API endpoints that were f…

If that took "several rounds of clarification", then the support they're paying for is worthless. Getting version of the application should be among the first bits of information collected, possibly even required for opening the ticket.

Re: Claude Advanced Tool Use

#228

Post by bradgessler »

theknarf wrote: post #202

We should just build more CLI tools, that way the agentic AI can just run `yourtool --help` to learn how to use it. Instead of needing an MCP-server to access ex. Jira it should just call a cli tool `jira`. Better CLI tools for everything would help both AI and humans alike.

[flagged]

Re: Claude Advanced Tool Use

#229

Post by malnourish »

politelemon wrote: post #160
stingraycharles wrote: post #151

Earlier quoted context omitted.

Reminds me a bit of the problem that GraphQL solves for the frontend, which avoids a lot of round-trips between client and server and enables more processing to be done on the server before returning the result.

And introduce a new set of problems in doing so.

Complexity doesn't go away, it just moves somewhere else.

Re: Claude Advanced Tool Use

#230

Post by gjvc »

ath92 wrote: post #207
tomashubelbauer wrote: post #206

Earlier quoted context omitted.

This would be awesome, but great CLIs would have already been valuable prior to the age of LLMs and yet most services didn't ship one. I think it is because services like Jira and others do not want to be too open. Ultimately, despite the current LLM/MCP craze, I think this won't change and MCP tools will start getting locked down and nerfed somehow, the same way APIs have in not so recent memory after there being a…

Nobody shipped this because previously almost nobody could use CLI tools. Now you can just ask an llm to generate the commands which makes things much more accessible

"almost nobody"
Post reply on HN