OMASGet Premium

MCP server · Rust 1.97.1+ · MIT

Run one file.
Fix it from your LLM.

Remote support and server administration from any MCP client — or any LLM that can make ordinary HTTPS requests.

Start a sessionHow the relay works →

Their machine

      
            ./omas
          
            
          
            Send this link:
          
            relay.omas.taps.im/t/8zxt954jz…

Allowthey press this

Your LLM

      
            Connector URL added
          
            
          
            “why did nginx die last night?”
          
            
          
            ✓ read /var/log/nginx/error.log
          
            ✓ ran systemctl status nginx

works until they close the window

  • No VPN
  • No SSH key
  • No inbound port
  • Nothing installed

The MCP control plane

Your clients, links and servers in one view.

See every connected MCP, keep this client available at startup, renew private links, and pair another machine without leaving the dashboard.

OMAS control plane showing connected MCP servers, relay health, the private MCP link, and the Start with system toggle
Live control plane · fleet, autostart and relay status
OMAS user pairing dialog over the connected MCP control plane
Pair this client · six-character connection code
OMAS dialog for adding a permanent MCP server from its relay link or token
Add a server · verify a relay link or token

A session, end to end

Four steps, and two of them are theirs.

The person being helped stays in charge of the whole thing. You never ask them for a password, and they never install anything.

  1. They run it

    One file, nothing to install

    The person who needs help — or the server you have to fix — starts OMAS. No account, no installer, no admin rights. On Windows a small window opens; on a server it prints to the console.

  2. They send the link

    A fresh link, good for this session

    One link appears. They paste it into chat, read it down the phone, or you copy it off the server yourself. The next session gets a different one.

  3. You connect

    Any MCP client or HTTPS caller

    Paste it into ChatGPT, Claude or Cursor, or call its JSON tools with curl. Their machine dialled out to reach the relay, so nothing had to be opened on their side.

  4. They allow

    Nothing happens until they say yes

    Until they click Allow — or press Enter in the console — every request comes back refused. The link on its own grants nothing.

On their machine

A window with one link in it.

On Windows that is a small window, the way remote-support tools have always looked. On a Linux server the same thing prints to the console.

server console
    
          ./omas
        
            OMAS support session
        
          
        
            Send this link to the person helping you:
        
              https://relay.omas.taps.im/t/8zxt954jzike7n8b9yudkfzq/mcp
        
          
        
            Nothing is shared until you approve.
        
            Press Enter to allow.

They stay in charge of it

The link is useless on its own. Until Enter is pressed — or Allow is clicked in the Windows window — every request you make comes back refused, and the refusal is written to the audit log.

Closing the window ends the session. Nothing is left running and nothing is left open.

Connection guide →

After they allow

You get what a support engineer needs.

This is a remote-support tool, so an approved session is not a narrow one. We would rather say that plainly than bury it in a policy page.

  • Read anything

    Every file, log and config on the machine, searchable.

  • Change and delete

    Edit files in place, apply multi-file changes, remove generated artifacts.

  • Run commands

    Execute on the machine and read back bounded, secret-redacted output.

  • See the screen

    Screenshots and short silent recordings of what they are looking at.

That is the same reach as a person sitting at the machine. It is exactly why the session has to be approved on that machine, by the person using it, every single time.

Why the link is safe to hand out

The link is not the key.

Remote-support tools fail when holding a link is enough. Here it never is.

  • It is shut until they say yes

    The approval latch starts closed, and a tool is refused before its arguments are even validated. Only the keyboard in front of that machine can open it.

  • Nothing inbound is opened

    The machine dials out over WSS. No port forwarding, no firewall rule, no VPN — and nothing left listening when the session ends.

  • A different link every time

    Session tokens are generated per run from an alphabet with no l, o, 0 or 1, so they survive being read aloud. A link that leaks stops working when the session does.

  • Every call is audited

    Each request emits a value-free JSON event with the tool, outcome and timing — never the contents. Refusals are recorded too.

Read the security model

The other way to run it

For machines you own, scope it down instead.

An attended session is all-or-nothing by design. A machine you administer yourself can run OMAS permanently with a fixed scope and a capability mode per directory.

  1. --mode read

    Bounded reads

    Bounded repository reads and search. Writes stay disabled.

    • Tree, search, and bounded file reads
    • Policy explanation before you attempt an operation
    • Bounded images and multi-file reads
  2. --mode write

    Contained writes

    Everything in read, plus policy-checked file writes subject to denied paths, size limits, symlink checks, and secret scanning.

    • Repo-relative file writes
    • Hard denied-path and secret-value rejection
    • Configured byte and path limits enforced
  3. --mode ship

    Local cleanup

    Everything in write, plus deletion of generated, untracked artifacts under an explicit path list.

    • Untracked cleanup under an explicit path list
    • Refuses tracked files outright
    • Never runs a shell or a Git command

No mode enables arbitrary command execution. Commands are gated separately and stay disabled until configured explicitly.

22 tools

MCP when you have it. Plain HTTPS when you do not.

Every tool uses the same embedded schemas, approval latch and audit trail whether it is called through an MCP session or the compact JSON bridge behind your relay token.

any HTTPS-capable agent
    
          curl -sS "$OMAS_URL/http/tools"
        
          curl -sS -X POST "$OMAS_URL/http/call" \
        
            -H 'content-type: application/json' \
        
            --data '{"tool":"repo_list_roots","arguments":{}}'
Browse all 22 toolsUse curl or HTTPSRead the source

OMAS hardware · Kickstarter preview

Give the agent eyes and hands before software starts.

PIXELCTRL ONE is a pocket-sized HDMI capture and USB HID interface for remote support, recovery, testing and physical device automation.

  • HDMI screen capture
  • Standard USB keyboard and mouse control
  • Single-cable mode for supported phones
  • No target-side driver or agent required
Explore PIXELCTRL ONE
PIXELCTRL ONE hardware overview

Questions

What people ask first

What can the helper actually do once I allow?
Everything a person sitting at your machine could do: read and search any file, change and delete files, run commands, and take screenshots or short screen recordings. This is a remote-support tool, and an attended session is deliberately not a narrow one. Every call is written to a value-free audit log, and closing the window ends it.
Is the link enough to get in?
No — and this is the part worth understanding. The link only tells the relay which machine to route to. Until you press Enter in the console, or click Allow in the window, every request is refused before its arguments are even read. Only the keyboard in front of that machine can open the session.
Do I have to open a port or set up a VPN?
Neither. The machine being helped dials outward over WSS to reach the relay, the same way a chat client does. There is no port forwarding, no firewall rule, no router configuration, and nothing left listening once the session ends.
What happens to the link afterwards?
It stops working. A session token is generated fresh each time the binary runs, so a link that gets forwarded or pasted somewhere it should not be is useless once that session ends. Tokens avoid the characters l, o, 0 and 1 so they survive being read down the phone.
Can I use this on a server instead of someone's desktop?
Yes, and it is the same binary. Run ./omas over SSH once, or from a systemd unit, and the connector link prints to the console instead of opening a window. For a machine you administer permanently you can also run it with a fixed configuration and a capability mode per directory, so it stays scoped rather than all-or-nothing.
Does it only work with ChatGPT?
No. OMAS speaks the Model Context Protocol, so ChatGPT, Claude, Cursor and any other MCP client can connect to the same link. Nothing about the server is specific to one vendor.
Do I need Node.js or an installer?
No. OMAS is a single native Rust binary. The person being helped downloads one file and runs it — no installer, no account, no administrator rights.
Is the licence a subscription?
No. Premium is a one-time purchase with a perpetual key that verifies offline against a public key embedded in the app, so it keeps working without phoning home. The MIT-licensed server itself is free, and you can self-host the relay if you would rather not depend on ours.

Premium · one-time €149

The machine you cannot reach is the one you need most.

The relay is what makes the link work at all from behind NAT — a rack, a home office, a client site. Perpetual licence, verified offline, packaged for Windows, AppImage and Flatpak, and self-hostable if you would rather run the relay yourself.

Get PremiumHow the relay works