Build the custom tool
Outcomes
The job the platform does not already do
Gutter cleaning happens outside, and a booking made during a storm helps nobody. The platform does not know this client cares about weather; that judgment is yours to add, and it is exactly the kind of job a custom tool exists for.
- Pick a weather service with a public API and open its documentation to the forecast endpoint. Many are free, and several need no account at all.
- Copy the example request from the docs. Most API documentation shows one as a cURL command, and that single line is all you need to bring with you.
- In AI Workforce, open your AI Employee's Configure view, go to the Capabilities tab, scroll to Custom Capabilities, and click Add a capability.
- Name it something a teammate would understand at a glance, like
WeatherCheck. No spaces. - In the Prompt field, type
TBDfor now. The prompt gets its own section, once the tool exists for it to talk about. - Click Add Tool and choose Import from cURL. Paste the example you copied. The import fills in the method, URL, headers, and parameter names for you.
- Give the tool an ID like
GetForecastand a description that says when to reach for it: "Use before booking outdoor appointments to check the weather conditions." - Write each parameter description so the AI knows where the value comes from: "The date the visitor wants, from their message. Convert phrases like next Tuesday to a date formatted YYYY-MM-DD. If no date is given, ask for one." Mark what the API requires as Required.
- The business location never changes with the conversation, so for the location parameter turn Set by AI off and set the value once. The AI should only fill in what actually comes from the visitor.
- Click Save.
Confirm it: the tool is saved with the method, URL, and headers matching the docs you copied from, and every parameter has a description you would trust a new hire to follow.
Write the capability prompt
The tool is the hands; the prompt is the judgment. A reliable capability prompt answers four questions, in order: when to act, what to collect first, how to respond, and what to do when something goes wrong.
Replace the TBD with a prompt built on those four parts:
# Check the weather before outdoor bookings
## When to use
- ONLY use GetForecast when the visitor is booking an outdoor service:
gutter cleaning, lawn care, exterior work.
- Do NOT use it for indoor services or general questions.
## What you need first
- The day the visitor wants, and the service they are booking.
## How to respond
- If the forecast is clear, continue the booking as normal. Do not
mention the check.
- If rain or high wind is forecast, say so and offer the nearest
clear day instead.
## When something goes wrong
- If no forecast comes back, continue the booking and let the visitor
know a team member will confirm the day before.
Write yours in your own words, but keep all four parts. Almost every capability that misfires in testing is missing one of them: no clear trigger, so it fires at the wrong moment, or no error path, so an empty response becomes an awkward answer.
Confirm it: your prompt names the trigger, the required information, the response shape, and the error path. Save it.
Read your prompt back as if you were briefing a new hire on their first day. Any sentence that would not change what they do is noise; cut it before you test.
Knowledge Check
Two quick questions on parameter descriptions and the four-part prompt.