Testing Tools
The single fastest way to ship a tool that works is to test it in the dashboard before assigning it to an agent. Bolti's Test panel sends a real HTTP request to your endpoint with mock arguments and shows you exactly what came back — same code path the agent uses live.
If Test passes, the agent will see the same response on a real call. If your endpoint is wrong, you find out here, not on a call with a real customer.
Where to find it
In the dashboard:
- Go to Tools in the left nav.
- Open the tool you want to validate (or click New Tool and fill it out).
- Click Test Tool in the top right of the editor.
A side panel slides in titled Test Tool — Preview and send a live request for this tool.
What the panel shows
The Test sheet is split into four sections, top to bottom:
1. REQUEST
A read-only summary of the resolved request: method, full URL with variables filled in, and the merged headers (your headers, plus auth, plus Content-Type: application/json).
This is what Bolti is about to send. Inspect it before clicking Send.
2. VARIABLES
Bolti scans your URL, headers, auth fields, and body for any {{placeholder}} it can find and lists each one as an editable input.
| State | Meaning |
|---|---|
| Empty list | No variables detected — the request is fully static. |
| List of inputs | Fill each one with a value the LLM might plausibly produce. |
These values are the mock equivalent of the arguments the LLM provides on a real call. The same templating rules apply — a missing variable becomes an empty string.
If your real callers send phone numbers as +14155551212, test with +14155551212. If your API rejects values without a leading +, you want to see that error here, not in production.
3. REQUEST BODY
A read-only JSON preview of the body that will be sent (after templates are resolved). For GET and DELETE calls this section is omitted.
4. RESPONSE
Empty until you click Send. After the request runs, this fills with:
- Status code —
200,4xx,5xx, etc. Non-2xx responses do not raise an error in the test panel; they're displayed so you can see how your endpoint behaves. - Response headers — the headers your server returned.
- Response body — parsed as JSON when possible, otherwise shown as text.
This is the full response. Bolti's runtime hands the same body to the LLM on live calls.
The Send button
At the bottom of the panel: Send <METHOD> Request (where <METHOD> is GET, POST, etc.). Click it to fire the actual HTTP call. While in flight it shows Sending request….
The request goes from Bolti's API to your endpoint, with your real authorization headers attached. There is no sandbox or proxy — your endpoint sees a genuine request.
Test calls hit your real endpoint with your real credentials. If the tool creates or updates data (POST, PUT, PATCH, DELETE), your test will create or update real data. Use a staging environment or test IDs when you can.
What gets validated
Testing checks the things that fail in production:
| Failure | Surfaced in Test? |
|---|---|
| URL typo or wrong host | Yes — connection error in the response panel |
| Bad authentication | Yes — 401/403 from your server |
| Endpoint blocks Bolti's IP / region | Yes — connection error or non-2xx |
| Wrong method (POST vs PUT) | Yes — 405 or unexpected behavior |
| Missing or malformed body field | Yes — your endpoint's validation error |
| Timeout too short | Yes — request fails after timeout_ms |
Templating syntax mistake (e.g. {{ wrong-name }}) | Yes — variable left empty in the resolved request |
| Whether the LLM will actually call it | No — that's a function of name + description + assignment. Use a real call to validate. |
The last row is the one to keep in mind. Test confirms the plumbing works. It does not tell you the model will choose to use the tool. For that, assign it to an agent and run a call from Agent Setup → Preview, or place an outbound call.
Safety guards
Bolti rejects test requests to URLs that resolve to private networks (loopback, link-local, RFC1918, ::1, etc.). The same rule applies on live calls.
If you need an agent to reach a service on your private network, expose it through a public ingress (with auth) — don't try to point Bolti at http://localhost or http://10.x.x.x.
Common debugging flow
A typical loop:
- Edit the tool — adjust URL, body, or schema.
- Open Test.
- Fill in variables → Send.
- Read the response panel.
- If wrong: fix the tool (or your endpoint) and repeat.
- When right: Save the tool, assign it to an agent, run a Preview call.
Most production tools are dialed in within 3–4 test iterations. The most common iteration is "my body shape was off" — Test catches it instantly because your server returns a 4xx with a useful message.
Calling the test endpoint outside the dashboard
Test isn't a dashboard-only feature. You can hit it via:
POST /public/v1/workspaces/{workspace_id}/tools/test
Content-Type: application/json
{
"tool": { /* full tool config */ },
"mock_variables": { "order_id": "ORD-1234" }
}
The response includes the resolved request URL, method, headers, body, and the upstream response status, headers, and body. This is useful for CI scripts that want to verify a tool config before deploying it.
The MCP server exposes the same operation as tools_test, so you can run a test directly from Cursor or Claude Desktop. See MCP → Available Tools.
What's next
- Define a tool from scratch: Workspace HTTP Tools
- Write a good schema and description: Custom Function Calls
- Hang up cleanly when done: End Call
- Run a real call against your agent: Agent Setup → Preview