ChatbyteDocs

Tools and actions

Connect services and choose what your agents can do during a conversation.

Tools let an agent do more than answer from its knowledge. A tool can look up an order, check availability, or send information to a connected service. You choose which tools are available and which agents can use them.

Use Customer context when you want information loaded at the start of a conversation. Use a tool when the agent needs fresh information or needs to take an action while helping the customer.

Understand the tool library

Open Tools in your workspace. The organization tool library has three main views:

  • Library: the tools your connected services provide.
  • Assignments: which agents can use those tools and under what conditions.
  • Approvals: requests waiting for a teammate's review where approval is supported.

A source is the service a tool comes from. One source can provide several tools. Connecting a source makes its tools available in the library; assigning a tool makes it available to an agent.

Connect a service

An administrator can use Add Tool to connect an MCP Source or create a Webhook Tool. MCP is a standard way for a service to describe the actions it provides. A webhook tool connects a specific HTTP operation.

Your service provider or developer supplies the endpoint, credentials, and any required configuration. Give the source a recognizable label so teammates know which service it connects to.

Chatbyte loads an MCP source's tools as soon as you connect it. Use Refresh Tools after your service changes them. Review the names and descriptions before assigning them. They should explain when the agent should use each action and what information it needs.

A tool without an output schema returns its full response to the agent, with saved secrets removed. To share only some fields, narrow the output on the assignment.

Sign in with OAuth

If your MCP server uses OAuth, choose OAuth sign-in when you add it. An administrator or owner signs in to the server once; every agent and every tool call then uses that account. Chatbyte finds the server's sign-in from its OAuth metadata (MCP authorization) and registers itself automatically when the server allows it.

  • The server must use HTTPS and publish OAuth protected resource metadata or authorization server metadata.
  • If the server does not let Chatbyte register automatically, create an OAuth app for Chatbyte on your server and enter its client ID (and secret, if it has one) under OAuth app. Use the redirect URL shown there: https://app.chatbyte.ai/api/v1/agent-tools/oauth/callback.
  • Chatbyte requests the scopes your server advertises, plus offline_access when offered so it can keep the connection alive. Enter scopes when adding the source to request others.
  • Tokens are stored encrypted and refreshed automatically, also while the source is idle. If the server revokes access, the source shows Reconnect required, administrators and owners get an email, and its tools fail until someone reconnects.
  • Use Check connection to confirm the server answers with the current sign-in, and Test on a tool to run it once.
  • Changing the server URL disconnects the source.

Choose which agents can use a tool

In Assignments, select a tool, its channel, and the intended agent or agents. Where your plan supports it, an organization default can make a tool available to all current and future agents in that channel.

An agent-specific assignment can override that default. Off for this agent disables the inherited tool for that agent; restoring inheritance makes the organization default apply again.

Each assignment has an execution behavior:

  • Run immediately: the tool runs as soon as the agent calls it. On voice calls, tools that may change data need an extra acknowledgment.
  • Ask the customer first: the agent describes the action and the tool runs only after the customer agrees. In chat, the customer replies that they agree; the chat shows what will run, without buttons. The agreement must come within 24 hours. On a call, the agent reads a summary and waits for the caller's answer; an unanswered request expires after 10 minutes.
  • Require team approval: the request becomes an approval task in Tasks and the conversation carries on. The agent tells the customer the team will review it and gives them a reference; in chat they also see a read-only line with the reference. On calls this is a hand-off: the agent says the team will follow up after the call. Admins, owners and the member you assign approve or reject it on the task (or under Approvals); the tool runs once, with the values the customer was asked about. You choose how long the team has to decide (1 to 30 days, 3 by default) and what happens if nobody does: tell the customer the request expired, or hand the conversation to a person.

The conversation's timeline shows your team when a request was sent for approval and how it was decided, with a link to the task.

Approval rules

Approval rules let one tool behave differently depending on the request. Add rules to an assignment; they're checked in order and the first one that matches decides. Requests no rule matches use the assignment's behavior.

A rule compares one of the tool's inputs with a value (for example amount is at most 50) or checks whether the customer is verified, and then does one of these:

  • Run immediately
  • Ask the customer
  • AI check
  • Send to the team
  • Block

For example: amount is at most 50 → run immediately; amount is at most 500 → AI check, with team approval as the assignment's behavior for everything else.

The AI check follows an instruction you write, such as "Approve if the customer clearly asked for it and says the order arrived damaged." It reads the request's values and the recent chat, and approves, sends the request to the team, or blocks it. It only judges requests a rule sends to it, so it can't approve anything outside that rule. If it can't decide, the request goes to the team, and its reason appears on the approval task. On calls it sees the request but not the conversation.

When a customer asks about a request later, by its reference or by asking for the same thing again, the agent tells them it is still with the team or what was decided. This also works in a new call from the same number or a later chat. Asking again never creates a second request.

These behaviors work in the chat widget and on Pages as well as on calls. In chat, the customer confirms in their reply, as on a call, and repeated requests are matched to the earlier one in the same way. Email and messaging channels such as WhatsApp don't run these tools.

If a tool returns personal data, require a signed-in customer for its assignment so your service can check that the data belongs to them.

Approval inside your own service

Some services run their own review, such as a refund queue. Chatbyte supports this alongside its own approvals:

  • Return a pending answer. Respond with a clear status and your own reference, for example {"status": "pending_review", "reference": "R-1042"}. The agent passes it on.
  • Use the request ID to avoid duplicates. Chatbyte sends an idempotency key with every call in the MCP request metadata (chatbyte.ai/idempotency-key). Treat a repeated key as the same request.
  • Write errors for the agent. When a call can't proceed, return an MCP tool error with a short, customer-safe explanation, such as "Order 1042 has already shipped." Chatbyte passes it to the agent and leaves out stack traces.
  • Keep reading and changing separate. Offer a read-only tool, such as checking a refund, apart from the tool that makes the change, so the agent can check status freely while changes stay behind your chosen behavior.

Check that the tool is ready

StatusMeaning
ActivatingChatbyte is preparing the tool for the agent.
ReadyThe tool is available to the agent.
Needs attentionActivation or output settings need review.
OffThe tool is not available to the agent.
OverriddenA direct assignment takes precedence over an organization default.

After correcting a problem, use Retry activation where offered. After refreshing a source, review changed tools and confirm their status is Ready.

Configure built-in voice actions

A voice agent's Actions screen groups live-call tools separately from automations that run after a call. Depending on your setup, it can include contact capture, appointment booking, phone transfer, and post-call summaries.

Open the action to configure its behavior and required connection. For example, set a phone transfer's destination in the action settings, then explain when to transfer in the agent's instructions.

Developer/API Actions contains older voice-specific actions. Use Create in tool library for new shared actions.

Test the whole conversation

Start a test conversation and ask for a realistic task. Check that the agent requests the right information, calls the intended tool, and explains the result appropriately. For voice calls, open the call record to inspect recorded tool activity and any reported failure.

For a custom service implementation, give your developer the separate API reference.