[Feature] Provide Custom Tools.

[ParisMolver]

Current I have to hijack /tool/built-in/index.ts to create the following

export const BUILT_IN_TOOLS: ToolDefinition<any>[] = [
  bashTool,
  fileReadTool,
  fileWriteTool,
  fileEditTool,
  grepTool,
  customTools.runTestsTool,
  customTools.buildTestsTool,
  customTools.getProjectTreeTool,
  customTools.readLogTool,
]

Whilst I could get the AI to use bash and execute the commands to run the test, i don't like giving an agent bash unless it requires it as it often does things such as recursive scan of directories which just blows up the model.

I wrote my custom tools and spent many days trying to get things working then i injected them into the built-in tools for use in 'registerBuiltInTools' and found that for the first time it actually works. I will still continue to use the built in tools when required but I think it's a bit jank having to edit the source file to allow for custom tools.

Ideally I would like to have the built in tools registered as usual, then at the start of my code i can either pop a built in tool out, or add in a custom tool.

Is there a better way of using custom tools as I haven't seen any of the examples mentioning it. Having taken a deeper look it seems that the orchestrator would need some changes such that

function buildAgent(config: AgentConfig): Agent {
  const registry = new ToolRegistry()
  registerBuiltInTools(registry)

  const executor = new ToolExecutor(registry)
  return new Agent(config, registry, executor)
}

allows for the pop / append of customTools to registry when the buildAgent is called

[JackChen-me]

Removing built-in tools already works today. AgentConfig has disallowedTools (blacklist) and tools (whitelist):

// block bash specifically
{ disallowedTools: ['bash'] }

// or whitelist only what you need
{ tools: ['file_read', 'grep'] }

Injecting custom ToolDefinitions through the orchestrator is the part that's genuinely missing. Will add a customTools field to AgentConfig so buildAgent() registers them alongside built-ins.

[JackChen-me]

Shipped in #109.

btw saw you have runTests, buildTests, getProjectTree, readLog as custom tools. What are you building with this? Curious how the multi-agent part fits in.

[ParisMolver]

Hi Jack, thanks for getting back to me.

I have CPP code for ESP32, I have built the project and haven't touched it in a year due to hard to trace bugs and the fact that there is a hardware and a web site which either could be buggy or receive bad data so it is a tricky problem to solve.

My current workflow is

Create a short prompt saying "I want to create tests for this part of the logic in this function"

• (Local Gemma 4) - Do initial research on relevant file names
• Unpack file names into string
• (Gemini Pro) - Take original prompt and files and give me the answer of the tests
• Save output

In a separate team I have code which essentially just says "I was trying to implement this, what happens when i build and run the tests". This team excludes the gemini pro agent and runs local LLM which is great.

• Read Gemini prompt
• Designer: You will be given some code to implement or the console logs to diagnose and fix.
• TestRunner: Run the implemented tests using 'verify_tests'. Only fail if compilation fails.
• ConsoleReader: If the tester fails due to compilation errors, trigger the agent to analyze logs and provide a fix plan
• Editor: You will be provided console output that you will need to debug.

So far I have been able to get a high quality output from gemini, i've also had success with multiple files been edited correctly.
Now I've got tools working I'm finding that it's pretty hard to wrangle on a 16GB card, sometimes i get lots of loops and i find that the agents aren't as capable as chat mode is, so thats why for the file name research i use 1 shot via chat mode and get reliable results.

I still find that there is a different kind of intelligence when used in agentic mode, you just have to be able to limit what context is shown to your model. For example, exit code 1, output of the command is in the /home/pc/builds/smart/log/idf_py_stderr_output_111800 is a hot potato and if an agent tries to read that file it will tank. I think it's much safer to just have a tool that says 'if you see an exit code' then it runs the tool that prints out a file at most 20% of the maximum context allowed.

I'm not sure how granular to make agents at the moment, for example is it better to have an agent that has 'build & run` system prompt, or two agents dedicated to the job of building and another for running.

[JackChen-me]

Cool setup. On the granularity question: start coarse (one agent for build+run), split only when you hit a specific failure that splitting would fix. More agents = more complex coordination prompts and more context passing between them, which local models struggle with.

For build log blowup, truncating in the tool's execute before returning is the right call. We also have contextStrategy on AgentConfig (sliding-window or summarize) if the conversation itself gets too long.