A server for AI assistants

MCP is a shared language between an AI assistant and small programs that do real work. The assistant asks for a named action with named arguments, the program performs it and answers.

ARMANOS ships one such program: a single Node file with no third-party dependencies. Your AI tool starts it as a child process and talks to it over standard input and output.

The server does no browsing of its own. Each tool call becomes exactly one request to the local automation API on loopback, the same interface a script of yours would use.

So the assistant is not given a new way into your profiles. It is given the way that already existed, with the same token and the same rules.

There are exactly ten tools, and every one of them maps to a route the local API already implements. Nothing on the list is a promise for later.

Each tool carries a description written for a model rather than for a menu. It says what comes back, so the assistant picks a call instead of guessing at one.

Everything you write to the assistant goes to its provider. Enter proxy passwords, site passwords and 2FA keys in the app, not in the chat.

The eight requests below are also in the app, on the For developers screen, with a Copy button. The ten tools of the MCP server carry out each of them.

• Check that ARMANOS is reachable and tell me which profiles are open right now

• Create 5 profiles named Shop-01 to Shop-05 in the group "Shops", Windows template

• Open all profiles in the group "Shops" and tell me which did not open and why

• Close all open profiles

• Show the proxies from my library that failed their last check

• How many profiles do I have in each group, and which of them are protected by a password

• Give me the two-factor code for the profile "Etsy-2"

• Move the profiles tagged "test" to the trash

There is no second store and no export. The assistant sees the same records you see on the Profiles screen, and a profile it creates shows up in the app immediately.

The assistant passes the same gate you pass when you press a button in the app. A locked licence refuses a launch, a create beyond your plan quota fails with the reason the app itself would give, and there is no relaxed mode on this path.

A launch comes back with the debugging endpoint when one exists. On ARMANOS Browser each profile gets its own endpoint, so a driving tool attaches to exactly that profile.

• Identifiers

  Profile id, name and scenario. The id is what launch, stop, delete and the code tool take as their argument.

• Group and fingerprint template

  Where the profile is filed and which of the five templates it wears.

• Proxy summary

  Protocol, host and port. The login and password stay inside the app.

• Tags and times

  Enough for the assistant to sort and choose without opening anything.

Everything you paste is generated for you. The app knows the script path inside the installation, the address the API is really listening on and your current token.

MCP status on the panel follows the API rather than a setting of its own. It reads Ready only while the local API is actually listening, so you never paste a config for a server that is not there.

1. 1

   Turn on the local API

   Open For developers in ARMANOS and flip the switch.

2. 2

   Install Node.js

   Your AI tool launches the server with the node command.

3. 3

   Copy the client configuration

   One button copies the whole block, path, address and token already filled in.

4. 4

   Paste it and restart the client

   Any MCP client reads a file of the same shape.

There is no account to create and no key from us. For the installed app two environment variables are the entire configuration, and the server reads them once when your AI tool starts it. On every call it also looks in the app's data folder for the port the API really listens on, and uses that port when the token there matches its own.

The path in the arguments points inside the installed app. On Linux builds where that path changes from one start to the next, the app copies the script next to its own data, so the path you set once keeps working.

The API listens on loopback and nowhere else. It is off until you switch it on, and the first run writes a random 48-character token into a file inside your account's folder.

Loopback on its own would not be a boundary. The pages you visit run on this machine too, so the API refuses a request that looks like it came from a page before the status route, and such a page does not learn the version.

• Bound to loopback

  Another computer cannot reach it, and neither can anything else on your network.

• Token on every call

  Sent as a header. Only the status route is open, and only to a program on this machine.

• Pages get a refusal

  The API refuses a request carrying the marks of a web page before the status route.

• No credentials in answers

  The proxy listing drops passwords, and a profile carries protocol, host and port only.

• Codes not keys

  The code tool returns the code and the seconds left. The 2FA secret itself never leaves the app.

One honest line about the other end. The server sends nothing to us and needs no internet, but whatever a tool returns lands in your assistant's context, and where that context is processed is a property of your AI tool.

That is why list_profiles, create_profile and update_profile leave out profile notes, where people keep logins and recovery codes, list_profiles does not search them, and the server has no cookie tools.

Neither a bad frame, an unreachable API nor a malformed reply will bring your assistant down. Instead of silence it gets a normal tool error and reads it out to you.

An API error reaches you in its own words rather than reworded. A refusal about a plan limit reaches you as a plan limit, not as a generic failure.