Skip to content

MCP server

This API serves a Model Context Protocol server over HTTP at https://api.salesbud.com.br/mcp. Registered once as a custom connector in claude.ai, it lets the model read meetings, calls, transcripts, template answers, evaluations, email and WhatsApp conversations with your credential — nothing to install.

It is a client of the public API, not a new surface. Same OAuth credential, same scopes, same rate limits, read operations only — nothing it can reach is anything the HTTP API would not return to the same credential.

You need an API credential with the scopes you intend to use, the API_ACCESS feature enabled for your company, and owner access to the Claude organization that will hold the connector. Credentials are not self-service; see the Quickstart.

An owner of the Claude organization adds a custom connector pointing at https://api.salesbud.com.br/mcp. Authentication is No sign-in — this server has no OAuth flow — and the credential of the company whose data the connector should read travels in two request headers:

HeaderValue
X-Client-Idsb_client_...
X-Client-Secretsb_secret_...

Any other HTTP client may send the same credential as RFC 7617 Basic instead:

Authorization: Basic <base64 of client_id:client_secret>

Two consequences of a credential entered once by an administrator:

  • It is stored on Anthropic’s side and shared by the whole Claude organization. Everyone in it reads whatever the scopes allow, and the audit trail records the credential, not the person who asked.
  • Revoking means rotating. Rotating the secret breaks every other integration using the same credential, so give the connector one of its own.

If the credential restricts access by IP, the allowlist has to include Anthropic’s egress range, 160.79.104.0/21: the request reaches this API from there, not from the user’s browser.

One tool per public read operation. The scope column is what the credential has to carry — a missing scope comes back as a readable INSUFFICIENT_SCOPE message the model can report, not an exception.

ToolScope
get_api_contextnone beyond a valid credential
list_meetingsmeetings.read
get_meetingmeetings.read
get_meeting_overall_evaluationmeetings.read
get_meeting_answersmeetings.read
get_meeting_transcriptmeetings.read + transcriptions.read
list_callscalls.read
get_callcalls.read
get_call_overall_evaluationcalls.read
get_call_answerscalls.read
get_call_transcriptcalls.read + transcriptions.read
list_emailsemails.read
get_emailemails.read
list_email_messagesemails.read + emails.content.read
list_whatsapp_conversationswhatsapp.read
get_whatsapp_conversationwhatsapp.read
list_whatsapp_messageswhatsapp.read + whatsapp.content.read

Ask get_api_context first when you are unsure what a credential reaches: it answers with the client, the company, the scopes and the per-minute limit.

/oauth/token is deliberately not a tool — the server issues and renews the token itself, and exposing it would burn the OAuth bucket and put the token in the conversation. The liveness and readiness probes are not tools either.

A one-hour transcript is thousands of utterances and does not belong in a model’s context in one piece. The transcript tools return 200 utterances per call and say how many are left; the model passes offset to continue. The API returns the transcript whole — this windowing lives in the MCP server.

A record with no transcript is not an error: the tool reports transcript unavailable (status: not_started), which is the contract described in Meetings and calls.

Email bodies cost more than email metadata

Section titled “Email bodies cost more than email metadata”

list_emails and get_email return conversation metadata — participants, connected mailboxes, linked accounts, counts — and never a body. Reading the messages is a separate tool, list_email_messages, and it asks for more: emails.content.read on top of emails.read, plus its own rate-limit policy, tighter than the rest of the API. Ask for a page at a time instead of walking a whole mailbox.

A body longer than 2,000 characters is trimmed in the text the model reads and kept whole in structuredContent. Attachment content, HTML bodies and bcc are never served by the API, so no tool reaches them.

WhatsApp text costs more than WhatsApp metadata

Section titled “WhatsApp text costs more than WhatsApp metadata”

list_whatsapp_conversations and get_whatsapp_conversation return conversation metadata — contact, seller, linked accounts, activity instants — and never a message. Reading the messages is a separate tool, list_whatsapp_messages, and it asks for more: whatsapp.content.read on top of whatsapp.read, plus its own rate-limit policy. Ask for a page at a time instead of walking a whole history.

A text or an audio transcription longer than 2,000 characters is trimmed in the text the model reads and kept whole in structuredContent. A message deleted for everyone stays as a tombstone with no content; an edited message shows its current text. Media content, provider identifiers, reactions and read state never reach the model — the API does not serve them. See the WhatsApp reference.

What the server handles, and what it does not

Section titled “What the server handles, and what it does not”

It handles token renewal with a safety margin, one retry on 401 with a fresh token, Retry-After on 429, backoff on 503, and immediate failure on the other 4xx. Errors reach the model carrying code and request_id, so a bad date filter comes back as INVALID_DATETIME and the model corrects the format itself.

It does not paginate for you. The model follows has_more and next_cursor like any other client, and the tool description says so, because a short page is not the last page.

It also does not give you incremental sync, because v1 has none: window by meeting_at or created_at and reprocess idempotently by id.

Every credential of a company draws from the same 600 requests/minute company bucket. An agent walking a long history consumes quota your other integrations are using; see Rate limits.