4 min lesson
Custom tools: let Max and your agents call the APIs you already use
Build Frontline custom tools from an API. Arguments, headers, testing, and how Max writes a tool from documentation.
A custom tool is an API call your account owns. You name it, you describe when to use it, you point it at an endpoint, and you decide which arguments the model fills in. Then you assign it to Max, to an agent, to a playbook, or to a task.
Frontline already talks to your CRM and to connected integrations. A custom tool is the door to everything else. Harrington’s portfolio system. The custodian. The billing portal. A KYC vendor. If it has an HTTP API, it can be a tool.
The description is the part the model reads when it decides to call the tool. “Fetch the latest statement PDF for a household by account number” will get used on statement questions. “Internal endpoint 4b” will sit unused. Write the description the way you would brief a new hire.
What goes into a custom tool?
Start with the request.
Method and URL. GET, POST, PUT, PATCH, or DELETE. The URL can include placeholders, such as a path that takes {accountNumber}.
Arguments are the inputs the model supplies at run time. Each one has a name, a description, a type (text, number, or true/false), whether it is required, and an optional default. The name you declare is the name you drop into the URL, the headers, the query string, or the body as {accountNumber}.
Headers carry auth and content type. A bearer token, an API key, Content-Type: application/json.
Query params are the extras on a GET. Include related objects. Filter by date.
Body is the JSON for POST, PUT, and PATCH. Same placeholders. {householdName} in the body becomes the value the model chose.
You can test a tool with real values before anyone uses it. The test returns the status, how long it took, and the response. That is the moment you find a wrong header or a path that still has a placeholder in it.
Tools can be active or paused. Pause one when the vendor is in maintenance. Turn it back on when the endpoint is healthy.
Where do custom tools get used?
Anywhere a model is allowed to act.
On an agent, the tool is in the agent’s toolkit. The WhatsApp qualifier can check whether James already has a household in the portfolio system before it creates a Deal.
On Max, the tool is available in chat and in the work Max does for you. “Pull last month’s statement for the Harrington household” becomes a tool call, then an answer.
On an agent playbook, the tool is scoped to that procedure. The “Send statement” playbook can call the portal. The “Qualify mandate” playbook never sees it.
On a Max task, the same idea. A Monday pipeline review can call the portfolio API for AUM before it writes the brief.
How does Max write a custom tool from API docs?
This is one of the fastest ways to get a tool into production.
Paste the vendor documentation into Max, or point it at the public docs URL. Say what you want in plain language. “Create a tool that fetches the latest statement for a household. The docs are here. Auth is a bearer token. I need account number as the input.”
Max reads the path, the method, the arguments, and the headers, then creates the tool. You test it with a known Harrington account number. If the response looks right, assign it to Max, to the agent, or to the playbook that should own it.
A coding agent on the CLI can do the same loop. Create the tool, test it with values, read the response, fix the body or the header, test again. The CLI is useful when the definition should live in a repo next to the rest of the account setup.
What does a good first tool look like?
Keep the first one to a single job.
Harrington’s first custom tool is “Get household snapshot.” GET, account number in the path, bearer token in the header, description that says it returns AUM, custodian, and last statement date. Test it on James’s account. Assign it to Max and to the qualifying agent.
The second tool can create a service ticket in the ops system when onboarding starts. POST, household name and mandate size in the body. Put that one on the onboarding playbook, not on every agent.
Name the tool for the outcome. Describe the arguments the way a person would ask for them. Then let the model fill them in.