Your agent needs to work with Chili Piper. It needs to route an inbound lead, check which rep is up in the round robin, pull open slots, and book the meeting without a human touching a scheduling UI. Chili Piper ships an official remote MCP server and a full Edge API, and both are documented, supported, and production-ready. Unlike most tools in this series, the two paths cover roughly the same ground. That makes the decision harder, not easier, because the tradeoffs move from capability to credential scope, determinism, and how many tools you are willing to put in a context window.
Both surfaces are owned and hosted by Chili Piper. Neither is a community wrapper, and neither requires you to run a server. The distinction is in the transport and the credential model, not in what lives behind them.
Chili Piper hosts a single remote MCP endpoint over streamable HTTP. There is one server URL for every client, and Chili Piper handles hosting, scaling, and schema updates. It works with Claude Desktop, claude.ai, Claude Code, Cursor, ChatGPT, OpenAI Codex, Gemini CLI, and Microsoft Copilot Studio.
Authentication is either browser-based OAuth, which requires an Admin on a paid Chili Piper account and needs no client ID or secret because the client discovers the OAuth configuration from the server, or a bearer API access token generated in Command Center. Setup and the full client matrix are in Chili Piper's MCP connection guide, and the product surface is described on the Chili Piper MCP product page.
The Edge API is a REST surface named after the subdomain it is served from. It exposes Health, Tenant, Rule, Workspace, Team, Distribution, Availability, User, CRM, Meetings, Concierge, Scheduling Links, and Handoff. Programmatic booking follows a two-step pattern across all three entry points: one call routes or initializes and returns a session plus available slots, a second call commits the meeting.
Authentication is a bearer API access token generated under Command Center, Integrations, Credentials, API Access Tokens. Token generation, the endpoint inventory, and pagination behavior are documented in Chili Piper's Edge API References.
Most articles in this series open by naming a capability gap. There is not a meaningful one to name for Chili Piper. Chili Piper's own programmatic scheduling guide states plainly that the Edge API and MCP resolve to the same backend, and that the MCP tool names mirror the Edge operation IDs.
That single sentence rewrites the decision. You are not choosing between a rich surface and a reduced one. You are choosing between letting a model pick the operation dynamically and writing the call yourself.
The comparison below holds capability roughly constant and varies the things that actually differ in production: who the credential belongs to, how narrowly it can be scoped, and how much of the tool surface lands in your context window.
Scalekit's catalogue lists 156 tools on the ChiliPiper MCP connector, covering assignment tables, data fields, Distro router configuration, Chat AI conversation logs, and webhook subscription management alongside the core booking tools.
Chili Piper's Edge API help article enumerates thirteen endpoint groups and points to a Swagger reference for the complete list. So the difference you will notice is in documentation density, not in reachable functionality. Treat the tool catalogue as the more current inventory of what the server will actually answer to, and verify anything load-bearing against the Swagger spec.
A 156-tool server is not a feature for an autonomous agent. Chili Piper documents this directly for one client: Microsoft Copilot Studio truncates the tool list at 70, the org MCP endpoint exposes more than that, so some tools are silently dropped and which ones is not something you control.
The failure mode is nasty because it is quiet. The agent tells a user it cannot do something it actually supports, or reaches for a worse-fitting tool. Chili Piper's own recommendation is to build narrow, purpose-built agents rather than one general-purpose agent, and that advice generalizes well past Copilot Studio.
Every tool definition in context consumes tokens. At the common heuristic of roughly 200 tokens per tool definition, a 156-tool surface is somewhere near 31,000 tokens before your agent reads its first instruction.
Tool bloat is an accuracy problem and a cost problem at the same time. The fix is not better prompting. It is surface reduction, which is the argument made in more depth in token-efficient tool calling.
This is where the two paths genuinely diverge, and it is the inverse of what you may expect if you have read the Notion or Salesforce entries in this series. For Chili Piper, the MCP path is the one that supports a static credential, and OAuth is the less flexible option.
The OAuth path is browser-based and Admin-only on a paid account. Chili Piper notes that a plugin authorized this way reaches every Chili Piper tool the account can use, and recommends an API key with scoped permissions when you want to hand out narrower access.
API access tokens are generated with an explicit permissions dialog: you pick Ping, Read, Modify, and Remove per section, and Schedule in the Concierge, Scheduling-links, and Handoff sections. A booking agent needs Schedule on one section plus Read where it lists assets, and nothing more.
Chili Piper's OAuth path does store a per-user token, but only Admins can complete the grant. There is no non-admin OAuth flow for MCP today.
Combine that with the documented limitation that all tool calls are scoped to your organization tenant, and the conclusion is unavoidable: your agent's Chili Piper identity is an org-level admin identity on both paths. Salesforce enforces field-level security and sharing rules on every MCP tool call. Chili Piper does not have an equivalent, so a booking agent can, in principle, also delete a routing rule.
If you are building a B2B product where each customer connects their own Chili Piper org, the unit of isolation is the tenant, not the rep. Forty reps inside one customer share one credential surface; forty customers means forty credentials to store, scope, and revoke.
Neither path gives you least privilege at the user level, so you have to construct it yourself: one narrowly scoped token per tenant per agent role, and a tool surface that does not include the destructive operations that agent role never needs. That is an infrastructure decision, and it is the same decision regardless of which transport you pick. For a deeper look at how this credential ownership problem plays out across agent patterns, see who holds the token across agent tool-calling patterns.
Chili Piper manages hosting, scaling, and schema updates on the MCP path, and it versions the Edge API on its own cadence. Everything below is yours on both paths.
Routing and scheduling sessions are single-use and short-lived. If the book call fails because a slot was taken, you cannot retry the same session; you start again from the route or init step.
Concierge session timeouts are configured per router path and returned in the response as timeoutInMS. Scheduling links and Handoff use a server-side TTL. Build your retry logic around re-routing, not around re-booking.
Meeting list and meeting export accept a maximum span of seven days. Concierge logs, Distro call logs, and Chat AI logs each cap the window at 30 days.
Pagination differs by path in a way that catches people out. The Edge API returns 50 records by default, caps at 100 with ?pageSize=100, and supplies a nextPage value. Several MCP list tools default to page 0 with a page size of 10. An agent asked to summarize last quarter's meetings will silently under-report unless you paginate explicitly.
Every Gemini surface, including Gemini CLI, the Google Gen AI SDK, and the Agent Development Kit, requires the X-MCP-Schema-Dialect: gemini header. Without it, the richer tools covering rules, distributions, routers, meeting types, and Handoff fail to load, and one failed tool takes the whole tool list down. Simple tools still work, so the connection looks healthy in a quick test.
Copilot Studio's 70-tool cap sits in the same category. These are not misconfigurations you can debug from your own logs; they are client behaviors you plan around.
MCP tool schemas change when Chili Piper updates the hosted server. You consume a managed contract without controlling its cadence. The Edge API gives you a stable REST contract you can pin your integration code against.
One write behavior applies to both paths and deserves a test: distribution weight adjustments are additive, not absolute. If a rep's current weight is 100 and your agent adjusts by 50, the new weight is 150. An agent that retries a failed adjustment without checking state will skew your round robin.
Because capability is roughly constant, this decision is about who chooses the operation: the model at runtime, or you at development time.
Chili Piper gives you a credential. It does not give you a vault, a rotation policy, a revocation flow, or per-tenant isolation. That work is identical whichever transport you chose, which is why the MCP-versus-API decision should not be the thing that determines your auth architecture.
In a multi-tenant agent, every customer org needs its own Chili Piper API token, stored encrypted, isolated per tenant, and never written to logs. Twenty customers is twenty credentials with twenty independent lifecycles.
The MCP path does not reduce that count and the Edge API path does not increase it. What changes is only the header you attach. The broader architecture challenge of moving from single-tenant to multi-tenant tool calling is worth reading before you commit to a credential strategy.
Chili Piper API tokens are shown once at generation and can be deleted from Command Center, which immediately revokes view, update, and manage access for that token. There is no refresh grant to fall back on.
So a revoked token is not an error you recover from in code. It is a re-authorization event that has to reach a human in the customer's org. If the first signal your system gets is a failed tool call in the middle of a booking, you have already lost the meeting. For a systematic approach to this, see how to handle token refresh for AI agents.
Scalekit's ChiliPiper MCP connector holds the token in a per-tenant encrypted vault, injects it into every request, and tracks connected-account state so a revoked token surfaces as a connected_account.status_updated webhook rather than a failed booking. The connector works the same way whether you call tools directly or expose them over MCP, so the transport decision stops touching your credential infrastructure.
Scalekit ships one Chili Piper connector today, and it fronts the vendor's own MCP server. Some tools in the connector catalogue have separate API and MCP entries; Chili Piper currently has the MCP one, backed by bearer token auth rather than an OAuth redirect.
Create the connection once per environment in the Scalekit dashboard under AgentKit, Connections, then register each tenant's Chili Piper token as a connected account. Generate the token in Command Center under Integrations, Credentials, API Access Tokens, and grant only the permissions that agent role needs.
The Node.js equivalent uses the same connection name and credential shape.
Chili Piper's tool names are not uniformly formatted. Some use underscores throughout, such as chilipipermcp_availability_slots_v2, and others keep the hyphenated Edge operation ID, such as chilipipermcp_concierge-route-by-slug.
Do not type them from memory. Retrieve the authorized surface for the current identifier and execute only names that come back.
The Concierge flow maps directly onto the Edge two-step pattern. Route first to get a session and slots, then commit one slot.
Sessions are single-use, so a failed booking means re-running the route call, not retrying this one. Log the full wrapper once when you wire a new tool, then read fields from data, because response keys vary per tool.
For an agent that reasons over routing decisions rather than following a script, the LangChain adapter returns native tool objects with no schema reshaping.
The in-process filter above is a stopgap. It trims what the model sees, but the connected account is still authorized for all 156 tools, so a bug or a prompt injection can reach past the list.
A Virtual MCP server enforces the restriction at the endpoint instead of in your process. You declare which connections and which tools an agent role can see, once, and get back a static mcp_server_url. Every run mints a short-lived session token bound to one identifier.
Four tools instead of 156 is the difference between an agent that books meetings and an agent that might delete a routing rule. The booking agent cannot reach distribution-delete because that tool is not on its endpoint, not because the prompt asked it not to.
Mastra has native MCP support, so it discovers the scoped tool list and schemas directly from the endpoint. Generate the per-user URL on your backend and pass it into the agent for the authenticated tenant only.
Chili Piper's own logs answer why a lead routed somewhere. They do not answer which agent run initiated the call, on whose authorization, or from which tenant's credential.
Because every Scalekit tool call resolves through a connected account, the downstream call carries that attribution. When an auditor asks who cancelled 40 meetings last Tuesday, the answer is a query, not a forensic exercise. The reasoning behind that design is covered in agent tool observability and audit trails for agent auth.
Connected-account state is part of the same picture. Subscribing to connected_account.status_updated means a revoked Chili Piper token pages your system, not a prospect staring at a failed booking form.
If your agent's job is investigative, where the next call depends on what the last one returned, use the MCP server and let the model choose the operation. If your agent's job is a booking pipeline that runs the same five calls every time, write against the Edge API and pin the contract; the model has nothing useful to decide there.
Most production Chili Piper agents end up doing both. A booking path that must not drift, and a reasoning path for the RevOps questions nobody can enumerate in advance. What does not change across either is that Chili Piper's credential is org-level, unscoped by default, and revocable with no refresh path. That is the part worth building on infrastructure rather than in your application.
Start from the ChiliPiper MCP connector docs, or from a working blueprint: the CRM AI agent, the meeting prep agent, the sales call prep agent, and the email to calendar agent all sit in the same GTM surface as Chili Piper. The full set is under GTM and RevOps agent templates, and usage-based limits are on the agent gateway pricing page.
If you are wiring Chili Piper routing into an agent and hitting the tool-surface or token-scoping problems above, come compare notes in the Scalekit Slack community.
For a scoping conversation about multi-tenant Chili Piper agents, per-tenant token isolation, or Virtual MCP server design, talk to us directly.
