← Back to blog

Tool calling with MCP: give agents safe access to your systems

How agents go from answering to acting — built-in tools, MCP connectors for Slack/Notion/CRM, and custom HTTP tools with auth, approval gates, and rate limits.

Written by

WisebotAI

Published

June 6, 2026

An agent that can only talk is a chatbot. An agent that can act — look up an order, file a ticket, post to Slack, update a CRM record — is a teammate. The bridge is tool calling, and the question that matters for any business is: how do we let agents act without giving them the keys to everything?

Three kinds of tools

1. Built-in tools. Common actions ship ready to use: knowledge search, escalate/resolve a conversation, book an appointment, web search, run code, create an image or deck. Turn them on per agent.

2. MCP connectors. The Model Context Protocol lets an agent call an external system's tools through a standard interface. WisebotAI supports connectors for tools like Notion, Google Drive, GitHub, Slack, and Confluence, plus HTTP-based connectors for systems like Salesforce, HubSpot, Zendesk, Jira, ServiceNow and more — and you can register a custom MCP server.

3. Custom HTTP tools. For your own backend, define a tool against any REST endpoint:

name: lookup_order
method: GET
url: https://api.acme.com/orders/{{order_id}}
auth: Bearer (stored secret)
rate limit: 30 calls / minute

Parameters are validated against your schema, so only well-formed calls reach production systems.

Safety is the whole point

Acting on real systems is exactly where things go wrong, so control is first-class:

  • Approval gates — mark sensitive tools requireApproval. The agent proposes the call; a human approves it from the cockpit before it runs.
  • Auth that stays server-side — credentials are stored encrypted and referenced by name, not pasted into prompts.
  • Rate limits & error handling — cap calls per window and define what the agent says when a tool fails.
  • Per-agent scoping — each agent only sees the tools you install for it.

A concrete example

A support agent resolving "where's my refund":

  1. Calls lookup_order (custom HTTP tool) to read status.
  2. If a refund is owed and under the policy threshold, calls the Zendesk connector to log the resolution.
  3. If it's over the threshold, the refund tool is approval-gated — the agent drafts it and a human approves.

The agent did real work; nothing irreversible happened without oversight.

Where to go next