The short version
- Tools167 tools in 9 groups, plus 6 guides and a flow-design prompt
- WhoCustomers through claude.ai connectors, Claude Code or any MCP client; our AI Assistant runs the same tools in-process
- Sign-inOAuth 2.1 with PKCE and dynamic client registration. “There is no token to copy.”
- Built2026-02-19 to today. 214 of 232 commits are mine, most of them in October
- Tests631 test methods in 52 files
- PublicHow to connect Claude to Aloware, on the help center
What customers can do
A user asks their assistant in plain language, and it does the work in Aloware. The tools fall into nine groups:
| Group | Tools | For example |
|---|---|---|
| Flows | 53 | Read, build, test and publish automation and voice flows; simulate calls that ring no one |
| Account setup | 32 | Lines, inboxes, users, teams, tags, lists and imports; restoring deleted records |
| Operations | 19 | Users, teams, lists and tags; Power Dialer lists; inbox availability; the audit log |
| Account settings | 19 | Account settings, holidays, dispositions, custom fields, call scripts and SMS templates |
| Reports | 15 | Dashboard and Insights numbers, communication logs and exports; reviewing one call or text |
| Integrations | 10 | CRM settings, calendar apps, webhooks |
| Contacts | 7 | Create and look up contacts; enroll them in sequences; number lookups |
| AI agents | 7 | Create, update, copy and publish AloAi agents; add knowledge files |
| Communication | 5 | Texts, ringless voicemail, two-legged calls, AI agent calls |
Act as a person, not an account
The first version took an account's API token. That made every caller the whole account. Usage data showed token clients calling only about 9 tools, so almost everything moved behind OAuth, and tokens are marked deprecated. A token now sees 14 tools; a signed-in user sees what their role and the account's features allow.
The assistant acts as the user who signed in. It sees only what that user sees, does only what their role allows, and every change it makes carries their name in the audit log.
Each account also has its own MCP switch, checked on every call and on the OAuth consent screen, and suspended users are refused.
The same checks as the page
I didn't want a second copy of the business logic that could drift from the app. The first tools called the existing public API's controllers. For account setup, pulling services out of the controllers meant rewriting about 1,000 lines of the riskiest code, so the tools run the admin page's own route in-process, as the admin. Validation, permissions and the audit log are the page's, and the log names the person.
Built for an agent that can be wrong
An assistant will sometimes pick the wrong record, invent a value or act on text it read. The server is shaped around that:
- Hints on every tool. 64 tools are marked read-only and 51 destructive, so a client can decide what needs a person's OK.
- Instructions that set limits. “Never invent an id, and never write message text the person did not give.” A test fails if the instructions name a tool the server doesn't have.
- Preview, then confirm. Publishing a flow, enrolling contacts in bulk, and setup steps such as buying a line or adding a user first return a preview and a hash. They act only when called again with that hash, so the change that runs is the one the person saw.
- No lost edits. Every edit to a flow draft sends the draft's last hash and is refused if the draft changed meanwhile.
- Undo. Every change an assistant makes to a flow is kept as a labeled version that can be restored, grouped by answer or working session so one answer doesn't leave dozens of versions. Deleted records can be restored too.
- Things it won't do. No keys, passwords or tokens, no connecting apps, no billing changes, and no deleting, pausing or disconnecting setup records.
- Calls that ring no one. A voice flow can be tested with simulated calls, each run inside a rolled-back transaction. An AI can play the caller and grade the result.
Knowing how it's used
The MCP package fires no events when a tool runs, so the server wraps its tool handler: every call, refused or not, writes a row with the account, user, role, sign-in kind, client, tool, outcome and duration, kept for 90 days. That log is what showed token clients barely used most tools, and it tells the AI Assistant's calls apart from outside clients. Rate limits sit on top: per token, per address, and tighter ones for flow writes, report reads, setup writes, exports and line purchases.
What carried over
- The page's code path. Tools that replay the app's own routes get the page's validation and permission checks, and its fixes, without a second copy.
- A person, not an account. Account-wide tokens can't say who did something. Signing in the person puts their name on every change.
- Log before you decide. The call log turned “who should get MCP?” from a guess into a query.
- One server, one set of tools. Four domain servers became one, and the in-app assistant uses it too, so a fix lands everywhere at once.
- Classifier-gated agent actions→200 cases against the classifier that lets an AI agent act without asking: its blind spot, and the per-value check that fixed most of it.
- An AI assistant that works the account→A chat panel that answers from an account's own data and changes it, on the same tools as our MCP server, measured fix by fix.
- Aloware Bot→An AI teammate in our Slack that reads accounts for admins, changes nothing, and keeps account data away from the web.