DevelopersChanges data

delete_call_list

API reference — one of the tools an AI assistant can call on an Avrosh account.

What it does

Remove a campaign. Refused while it is RUNNING - pause it first with update_call_list, so that stopping a live campaign and discarding it stay two separate decisions.

This is the exact text the model reads before deciding to call.

Parameters

business_idstringrequired

The id returned by list_businesses.

list_idstringrequired

From list_call_lists.

Request

curl -X POST https://us.avrosh.com/mcp \
  -H "Authorization: Bearer $AVROSH_KEY" \
  -H "Content-Type: application/json" \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"delete_call_list","arguments":{"business_id":"926135ac-487d-4367-8bad-25397d0d4b87","list_id":"cl_2…"}}}'

Response

The result arrives as an MCP content block; the JSON below is what the text field parses to.

{
  "deleted": true
}

Connecting

Paste the URL into your assistant and log in. Avrosh implements OAuth 2.1, so an MCP client discovers the authorisation server, registers itself, and opens a browser asking you to sign in here. That is the whole setup: nothing to copy, no key to keep, and nothing to rotate later.

https://us.avrosh.com/mcp

For something with no browser to log in with — a cron job, a script, an automation platform — there is a second door: a bearer key made in the dashboard under Docs, shown once because only its hash is stored, and revocable at any time.

curl https://us.avrosh.com/mcp \
  -H "Authorization: Bearer $AVROSH_KEY"

Either way the boundary is the same one: an assistant reaches every business on the account it signed in to, and no others. There are no scopes to configure and nothing to switch on — what bounds it is whose account it is, enforced in the database rather than by a permission anybody sets.