API reference

Everything an assistant can do with an Avrosh account, with the exact text the model reads before it decides to call. No account needed to read this page.

What this is

Avrosh speaks MCP over streamable HTTP. Point an MCP client — Claude, or anything else that speaks the protocol — at one URL, and it can read your businesses, their calls and transcripts, and create or change a business.

It is JSON-RPC 2.0 in a POST body. If you are wiring it by hand rather than through a client, initialize, tools/list and tools/call are the three methods you need.

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

Claude · signs in, no key

Claude Code — one line, and there is no key in it:

claude mcp add --transport http avrosh https://us.avrosh.com/mcp

Then /mcp inside a session to sign in and see the tools, or claude mcp list to check it. Add --scope user to have it in every project rather than this one.

The Claude app — Settings, then Connectors, then Add custom connector, and paste the URL. A browser opens and asks you to sign in to Avrosh.

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.

export AVROSH_KEY=avk_...   # made in the dashboard under Docs

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/list"}'

Run it in your own terminal. Pasting it into a chat will not work: an assistant’s sandbox cannot reach hosts outside its allowlist and does not inherit your shell, so both the host and the key come back empty.

The boundary is the account, not a scope. An assistant reaches every business on the account it signed in to, and no others. There is nothing to switch on: what bounds it is whose account it is, enforced in the database rather than by a permission anybody sets.

Who runs this server

Avrosh is operated by PT Laras Teknologi International, a company incorporated in Indonesia. Where accounts run, which model serves them, and every subprocessor that touches data are listed on security and subprocessors; the contract terms are in terms and the MSA.

Worth knowing before you connect anything, here or elsewhere: an MCP server sees whatever the client sends it, and its tool descriptions are read by your model. Ours are published in full on this page, word for word, precisely so that is checkable rather than taken on trust.

Set it up by asking

Paste this into the same chat. It reads your account first, asks for whatever it needs, and builds the rest. There is nothing to choose and nothing to fill in first.

paste into your assistant
You have access to my Avrosh account through the Avrosh MCP connector.

Set up my business end to end. Never invent a fact: every price, hour, policy and
name must come from me. If I do not give you something, leave it empty and list it
at the end as missing.

Start by reading what is already there with list_businesses and, if one exists,
get_business, list_knowledge, list_bookable_types, list_menu_items and
list_phone_numbers. Tell me in a few lines what you found.

If there is no business yet, ask me in ONE message for: the name; the town and the
time zone; the currency; what customers book, each with a price and how many
minutes; anything sold over the counter with prices; opening hours per day; how
customers pay; and the cancellation policy. Then create it with create_business,
a create_bookable_type plus set_bookable_type_schedule for each service, and a
create_menu_item for anything sold over the counter.

If a business already exists, do not recreate it. Tell me what is incomplete
- a service with no price, no duration or no hours, knowledge that cannot answer
an obvious question, no phone number, no voice chosen - and ask me only for what
is needed to close those gaps, then fill them with update_ and set_ tools.

Either way, finish by writing what the assistant should know with
add_knowledge_chapter, one chapter per subject, using only what I told you.
Payment and cancellation get their own chapters, word for word.

Then show me get_business and list_phone_numbers, and say plainly whether a
number is connected and a voice is chosen.

Rules: tell me in one line what you did after each write. If a tool returns an
error, stop and show it to me rather than trying a different tool. Do not delete
anything unless I ask.

It asks before it writes, and it is told not to guess. A model handed “set up a barbershop” will invent prices, opening hours and a cancellation policy, and nobody notices until a customer is quoted a number no one chose. Anything you leave out stays empty and comes back to you as a list of what is missing.

Run it again later and it does the other job: it finds what is incomplete and offers to finish it, rather than building a second business.

Authorization

Avrosh is an OAuth 2.1 authorisation server: RFC 8414 for discovery, RFC 9728 for the protected-resource metadata the 401 points at, and RFC 7591 for registration. Clients are public and register themselves, so there is no secret to share and none is issued.

  • PKCE, S256 only. plain is in the specification and is deliberately not implemented: it protects nothing against the only attacker it claims to stop.
  • Redirect URIs match exactly, never by prefix. Two addresses can share a prefix and not be the same place.
  • Refresh tokens rotate on every use; access tokens are opaque and bound to this resource.
  • Authorisation is tenancy, enforced in the database. There are no scopes to configure, so there are none to configure wrongly.

Avrosh is not an OpenID Connect provider. It issues no id_token, so /.well-known/openid-configuration returns 404 on purpose and there is no JWKS. Discovery runs over the OAuth 2.1 path, which answers on both the plain and the resource-suffixed form.

Tools

Reads are safe to call freely. The ones marked write change something, and they refuse while a business is in free mode.

What it sells

14
readlist_menu_itemsEvery item on this business's menu or product list - category, name, description, price, availability, dietary and allergen tags, photos.writecreate_menu_itemAdd one item to the menu or product list.writeupdate_menu_itemChange one menu item: name, price, category, description, dietary or allergen tags.writeset_menu_item_availabilityMark one item sold out (false) or back on sale (true).writedelete_menu_itemRemove one item from the menu.writerestore_menu_itemBring back an item deleted in the last 7 days, photos and all.writeremove_menu_item_photoRemove one photo from an item's gallery, by its URL as returned in list_menu_items.writeset_menu_item_thumbnailPick which gallery photo is the item's thumbnail - the one shown first on cards.readlist_bookable_typesEvery bookable type this business sells - rooms, services, or rentable units - with capacity, prices, schedule kind ('day' = per-night, 'time' = appointment slots), slot configuration and weekly hours.writecreate_bookable_typeAdd one bookable type.writeupdate_bookable_typeChange one bookable type: name, prices, capacity, description, amenities, or the deposit asked to confirm a booking.writeset_bookable_type_scheduleConfigure how one type is booked: kind ('day' per-night or 'time' appointment slots), slot length, service duration, turnaround buffer, minimum lead time, and weekly open hours.writedelete_bookable_typeRemove one bookable type from sale.writerestore_bookable_typeBring back a type deleted in the last 7 days, exactly as it was.

Bookings

9

Phone

7

Outbound

16

Errors

A tool that fails for a business reason returns a normal result with isError: true and a readable message, not a JSON-RPC error — so a client can relay it instead of dropping the connection. Protocol errors stay protocol errors.

invalid_api_key

HTTP 401. The key is unknown or revoked. Not retryable - make a new key in the dashboard under Docs.

business_deleted

The business was deleted and is in its recovery window. Call list_businesses for the current set.

free_readonly

The business is in free mode. Reads work; changes do not, until the account is activated. This is the same refusal the operator gets in their own browser.

business_exists

A business with that name is already on the account. Returned instead of silently creating a duplicate, because a timed-out create that gets retried would otherwise make two.

no_changes

update_business was called with no fields to change. Send at least one.

Placing calls

An assistant can schedule a call back, and it cannot place one. The tool writes down a promise; a sweep decides whether that promise is ever dialled, and it answers to three things the assistant does not control.

The business has to have opened a window. A property whose calling hours are unset never dials, whatever is scheduled against it, and unset is the default. The do-not-call list outranks the promise, including a number that agreed on one call and refused on a later one. Attempts are capped per promise, because somebody who asked to be rung asked to be rung once.

What an assistant still cannot do is dial on its own, run a campaign, or reach a number the business has never been able to reach.