Tool calling
A model on its own only writes text. An agent can also do things: open a file, search the repo, run tests, or call a connected app. That loop — decide an action, run it, read the result, continue — is tool calling. You describe the outcome; 4RGE handles the steps and shows you what happened.
What this page is for
Read How AI models work first if models vs agents is new. Pair with Context — every tool result becomes part of what the model sees next.
Who this page is for
What tool calling means
Tool calling is when the model asks the app to run a defined action instead of guessing from memory alone.
You do not pick tools from a menu. You write the goal ("fix this failing test", "find where we validate JWTs"). The agent chooses steps. Many steps run on their own; sensitive ones wait for you — see When you approve.
Think of it like a skilled teammate with hands on the keyboard: they can look things up and run commands, but you still review anything that could break production or leak secrets.
What you see in chat
Tool calling is visible. As the agent works, you typically see:
That transparency is the point — you are not trusting a black box. You follow the loop the same way you would watch a junior dev share their screen.
If output is huge (a long test log), the agent may summarize or narrow the next command. Very long tool output also fills context — another reason to scope tasks clearly.
Kinds of actions
4RGE groups agent capabilities into a few familiar areas. Exact names in the UI may vary; the ideas are what matter:
Plugins and MCP connections add more integration tools your team installs — the agent uses them the same way, with the same approval rules.
For product detail (approvals, extensions, cloud behavior), see Tools.
When you approve
Not every tool call interrupts you. Routine reads and many safe edits often proceed so you can stay in flow. 4RGE pauses when an action crosses a trust boundary, for example:
When a prompt appears:
- Read what was proposed — command, path, or integration
- Approve or deny — deny is fine; the agent can try a safer path
- Allow for session (optional) when you trust a repeat action, like your test suite
Skimming "approve all" on terminal commands is how accidents happen. If you would not run it yourself, deny and restate the constraint.
Org policy may further restrict models, networks, or integrations — Agent security.
Tools and context
Each tool call has two side effects worth remembering:
A multi-step fix (search → read → edit → test → edit again) is normal. It is also why one clear task per run beats an open-ended "refactor everything."
Tool definitions themselves take a slice of context (the agent needs to know what actions exist). Teams with many plugins or MCP servers should expect a slightly heavier baseline — admins tune what is enabled.
Habits that work
- State the outcome — "make
pnpm testpass inpackages/auth" beats "fix tests." - Say what is off limits — "inspect only, no edits" or "do not push."
- Name an integration when you need it — "use our issue tracker" if your org connected one.
- Review diffs and commands — tools make mistakes; you are the final gate.
- Split huge work — planning in one run, implementation in the next keeps tool loops focused.
- Run verification yourself when stakes are high — CI green beats the agent saying "should work."
When something fails repeatedly, check whether the agent lacks real output (tests not run, wrong directory) before switching models.