MCP (Model Context Protocol) is the open standard for connecting
LLMs to external tools and data. Pitchbar acts as an MCP
client: buyers connect their MCP servers
(CRMs, calendars, inventory, internal APIs) and the agent calls
tools mid-conversation when the visitor's question needs live
data the crawl can't provide.
What it unlocks
- The bot looks up an order status in Shopify before answering "where is my package?"
- The bot books a demo on Cal.com without leaving the chat.
- The bot fetches the visitor's open tickets from HubSpot to give context-aware replies.
- The bot queries the buyer's own internal API via their custom MCP server.
Architecture in one paragraph
Each agent has its own set of attached MCP servers. The admin
explicitly enables each tool per agent — destructive tools (writes
to the external system) require a confirmation dialog. At
runtime, the agent's tool-call loop merges built-in tools
(escalate_to_human, etc.) with MCP-discovered tools. When the
LLM decides to call an MCP tool, the request goes through a
rate-limited, circuit-breakered executor that wraps the tool
output in <tool-result trusted="false"> tags
so the system prompt can treat it as data, not instructions.
Hard rules
- Whitelist by default. Discovered tools land in the catalogue
as disabled. An admin explicitly turns each one on per agent.
- Schema drift = re-approval. When a tool's input shape changes
between catalogue refreshes, every existing grant is auto-disabled so the
admin re-acks the new parameters.
- SSRF guard. Server URLs that resolve to private / loopback /
cloud-metadata addresses are rejected at validation time AND at every call.
- Token budget. Tool outputs are truncated to 1200 tokens by
default (per-tool override allowed) so a chatty MCP server can't blow the
model's context window.
- Audit trail. Every call is logged with status, latency, args
preview, output preview, and a ULID request id for cross-system correlation.
Next steps