Website tools

Most businesses already publish the facts a caller asks about: products and prices, opening hours and locations, policies, FAQs. A website tool reads that site during a call so the agent can answer from it without an API.

Connect the site once and describe what the agent should look up. Meddle authors a matching tool and adds it to the agent.

Website tool or webhook tool

Reach for a website tool when the facts are public, already on the site, and you have no API to point at. It tracks the site as the site changes.

Reach for a webhook tool when the agent needs private data, needs to write to your system, or when the answer must be exactly right every time.

Both coexist on the same agent. A common shape is website tools for the catalogue and opening hours, plus a webhook tool for the one lookup that hits your own system.

Connecting a website

1. Open the agent's Tools page and choose Add tool, then From a website.
2. Enter the site's address and describe the lookup you want, for example "search the store for products the caller names" or "answer questions about opening hours".
3. Meddle reads the site, works out what kind of site it is, and authors a matching endpoint.

Other lookups the site supports are wired as tools at the same time. A recognised shop platform gives you product search and product detail alongside the tool you asked for.

Connecting a new site is restricted to workspace owners because it mints a credential and makes outbound requests. It is also rate-limited per workspace.

Adding another tool against an already-connected site does not re-read the site. Describe the new lookup and it reuses or extends the existing recipe. The Tools page groups every tool under the site it came from.

What gets added

A website tool is an ordinary tool on the agent. It calls an endpoint Meddle hosts for that site, authenticated by a key held as a secret variable:

GET  https://app.meddle.sh/api/site-api/{{site_api_id}}/search_products
     X-API-Key: {{site_api_token}}

You can sharpen its description, mark it background-safe, and give it prerequisites. It lands in a draft and reaches callers only when you publish.

The endpoint only fetches the address you connected. There is no way for a caller, or the model, to make it fetch something else.

Refresh behaviour

Connecting a site starts a background index. Until the index is built, lookups read the site live at call time. Once built, lookups are served from the index, which is what makes them fast enough for a phone call.

A failed refresh leaves the previous index serving, so a temporarily broken site does not empty the agent's answers. The editor's tool detail pane shows the index status and when it was last refreshed.

What the agent sees

Every result carries provenance: whether it came from the index or was read live, and how old it is. The agent can qualify a cached answer rather than presenting it as verified this minute.

Where a site does not publish a firm price (it depends on a postcode, a variant, a login, or the business quotes on request), the result returns no price and names the reason. The agent says so and offers a next step.

When a lookup finds nothing the agent recovers in the conversation, the same as any other tool. See tool errors are instructions.

Limits

• Live reads are deadlined. A lookup that misses the index and cannot be read live within a few seconds returns a "still warming up" result instead of holding the turn open. The caller hears the agent handle it, not silence.
• Requests per minute are capped -- generous for real conversations, a ceiling on a runaway loop.
• Some sites cannot be read. A site behind an aggressive bot wall or one that publishes nothing machine-readable yields a thin or empty result. The failure is reported, and a webhook tool is the answer for that business.
• Read-only. Booking, ordering, and anything that changes state belongs in a webhook tool or a connected app.

Related

• Tools
• Connected apps
• Knowledge base