Live data from Hacker News

Claude Advanced Tool Use

anthropic.com

271–280 of 280 posts

Re: Claude Advanced Tool Use

#271

Earlier quoted context omitted.

That's pretty much how I have been using coding agents. I get them to build small cli tools with a --help option and place them in a `./tools` directory. Then I can tell an agent to use the tools to accomplish whatever task I need done. Usually when I mention a `tool --help` for the first time in a prompt I will put it in backticks with the --help argument. It works really well.

im going to try this. it sounds promising. can you provide an example for more context?

Sure,

The agents have a tendency to make the "Examples" section of the help message way too long by stuffing it with redundant examples, so it needs to be manually pruned from time during development if you use an agent for tool development.

`gh-install` is a fish script (using curl and jq), it was made by an agent.

  gh-install -h
  Usage: gh-install [-i] [-q] [-s] [-p PATH] [-n NAME] [-f FILE] [-e EXECUTABLE]  [version]
    -i            - Show info about what would be installed (no install)
    -q            - Quiet mode (suppress all output except -i info line)
    -s            - Install to /usr/local/bin (system-wide)
    -p PATH       - Install to the specified directory (incompatible with -s)
    -n NAME       - Install with custom binary name
    -f FILE       - Select specific file from release assets and use as binary name (unless -n is specified)
    -e EXECUTABLE - Select specific executable from extracted archive (when archive contains multiple executables)
    repo          - GitHub repository in format owner/name
    version       - Optional version tag (defaults to latest)

  Examples:
    gh-install cli/cli v2.40.1
    gh-install cli/cli
    gh-install -i cli/cli (show info only)
    gh-install -i -q cli/cli (show info quietly)
    gh-install -s cli/cli (install system-wide)
    gh-install -p /opt/bin cli/cli (install to /opt/bin)
    gh-install -n gh cli/cli (install as 'gh')
    gh-install -f zed-remote-server zed-industries/zed (install server file)
    gh-install -e server some-org/multi-tool (install 'server' executable from archive)

Prompt:

  Use `gh-install -h` to install asdf, hadolint, ripgrep, fd, delta and bat.

If I need it to do something that uses multiple tools I might just tell it to look in `./tools` for the available tools, so the prompt would be something like this.

  Do x using the tools found in `./tools` (they all have a `-h` option).

I also have several tools that are just js scripts using playwright (webpage as the api) to fetch data and return it in a json format. Then I can tell the agent to use that tool and jq to do data processing.

Re: Claude Advanced Tool Use

#273
post #162

Earlier quoted context omitted.

Thanks, most of the times when I do that people tell me to stop being silly and stop saying nonsense. ¯\_(ツ)_/¯

don't listen to the naysayers! Had a chuckle as well LoL

The humor wasn’t what was nay—sayed.

Someone said it was a creative comment.

I blew air through my nose, too,

but let’s be real.

Re: Claude Advanced Tool Use

#275

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.

And actually I like it that new cli tools are emerging because of this. For example hono cli: https://blog.yusu.ke/hono-cli/

Re: Claude Advanced Tool Use

#276
post #6

I cannot believe all these months and years people have been loading all of the tool JSON schemas upfront. This is such a waste of context window and something that was already solved three years ago.

What is the right pattern? Do you just send a list of tool names & descriptions, and just give the agent an "install" tool that adds a given tool to the schema on the next turn?

- claudes tool search tool - list of skills (markdown files) the agent can grep - claude skills - context compaction - sub-agents - plans

There is no one “right” pattern. But yes it all generalizes to context engineering.

With plans for example, you write out potential distractions for later, to keep (the AI and the Human context) focused on a task at hand.

That pattern solves a distinctly different use case than the skills folder, but plans can also refer to skills in specific ways.

Context engineering is evolving with overlapping complementary patterns, and while certain vendors are branding patterns, i think we will hopefully we see tools converge.

Re: Claude Advanced Tool Use

#277

Earlier quoted context omitted.

im going to try this. it sounds promising. can you provide an example for more context?

Sure, The agents have a tendency to make the "Examples" section of the help message way too long by stuffing it with redundant examples, so it needs to be manually pruned from time during development if you use an agent for tool development. `gh-install` is a fish script (using curl and jq), it was made by an agent. gh-install -h Usage: gh-install [-i] [-q] [-s] [-p PATH] [-n NAME] [-f FILE] [-e EXECUTABLE] [version]…

this is helpful. thank you

Re: Claude Advanced Tool Use

#278
post #72

It feels crazy to me that we are building "tool search" instead of building real tool with interface, state and available actions. Think how would you define a Calculator, a Browser, a Car...? I think, notably, one of the errors has been to name functions calls "tools"...

well the name “function” is already taken - they deprecated it so that we could call functions, tools.

Well, I think they should have kept calling it function... ^^'

Re: Claude Advanced Tool Use

#279
post #224
post #105

Earlier quoted context omitted.

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 exec…

No one exposes SQL to clients though. I think where Gql differs from sql is it’s at a higher level. SQL bleeds performance and data layout (e.g. normalizing, limits), GraphQL does not.

It’s not clear if it’s high enough to abstract knowledge from storage. In the end it’s tension between enabling client to wander around productively vs being a bull in a china shop.

Re: Claude Advanced Tool Use

#280
post #74

Earlier quoted context omitted.

Why exactly do we need a new language? The agents I write get access to a subset of the Python SDK (i.e. non-destructive), packages, and custom functions. All this ceremony around tools and pseudo-RPC seems pointless given LLMs are extremely capable of assembling code by themselves.

I'm imagining something more like Rexx with quite high level commands. But that certainly blurs the line between programming language and shell. The reason for choosing higher level constructs is token use. We certainly reduce the number of tokens by using a shell like command language, But of course that also reduces expressiveness. I've been meaning to get round to Plan 9 style where the LLM reads and writes from f…

Between this:

> In the end I want to drop objects into context with exposed methods and it knows the type and what is callable on they type.

And this:

> I'm imagining something more like Rexx with quite high level commands. But that certainly blurs the line between programming language and shell.

It really sounds like you're trying to reinvent powershell.

A shell A Scripting language Everything is a self describing object Piped on the shell With exposed methods to call

Post reply on HN