Skip to main content
An AI assistant with access to your CRM can delete records, spend money and mint shareable links. Ringee’s MCP server treats those three categories differently from ordinary reads and writes.

Sensitivity classes

MCP annotations

Every tool carries the standard MCP trust hints, so a client can surface the right warning without knowing anything about Ringee: schedule_meeting, search_leads, reveal_lead and start_ai_voice_agent_call are open-world tools: they sync calendars, query Apollo/Prospeo or place a real phone call.

Hard guards in the server

Some protections do not depend on the client behaving well.
Two conditions must both hold:
  1. confirm is the literal boolean true;
  2. confirmPhoneNumber exactly matches the contact’s stored E.164 number.
A mismatch returns an error telling the assistant to re-fetch the contact and ask the user again. This makes it very hard to delete the wrong record from a fuzzy instruction like “delete that lead”.
update_contact and delete_contact re-read the contact and check it belongs to the active workspace before writing. Passing an id from another workspace fails.
delete_call_session marks the session revoked and invalidates every active token at once. Call history is preserved — the revoke is not a data deletion.
update_call_session can replace the contact queue only before the first call. Once dialing starts, the queue is frozen so progress and attribution stay coherent.
delete_campaign_lead requires confirm: true and refuses a lead that is locked, dialing or in a call. remove_from_dnc also requires confirm: true, because it makes a suppressed number callable again.
Before dialing, Ringee verifies the organization workspace, agent ownership and readiness, caller number, user’s calling permission, DNC list, available credits and the selected agent type’s required variables.

Credits

start_ai_voice_agent_call creates a real call. Ringee debits the telephony leg and the AI conversation usage when provider records settle. Bring-your-own model providers can also bill your provider account. reveal_lead consumes the connected enrichment provider’s credits rather than Ringee calling credits. It is explicitly non-idempotent: repeating it can spend the provider’s credits again. Assistants must not retry either reveal_lead or start_ai_voice_agent_call automatically after an ambiguous failure.

What an assistant should do

The server-side rules exist as a backstop. Well-behaved assistants also follow these:
1

Resolve before acting

Use search_contacts or get_contact to resolve a real id before any write. Never act on an id the user did not approve.
2

Read the target back

Before a destructive action, state what will happen and to which record — name and phone number — and wait for an explicit yes.
3

Confirm spend

Before reveal_lead, say that provider credits will be spent and for which lead. Before start_ai_voice_agent_call, name the agent and destination and explain that a real billed call will start.
4

Treat links as secrets

Share a joinUrl only with the person who asked for it. Never post it into a shared channel unprompted.
5

Never auto-confirm

confirm: true must reflect a human decision, not the assistant’s own inference.
These rules ship as machine-readable guardrails in @ringee-io/agent, which is what the ringee CLI, the Claude skills and the ChatGPT app all build on.

CLI equivalents

The CLI enforces the same classes with explicit flags, so an autonomous agent cannot spend or delete by accident: See CLI commands.