Aegis Boundary
Agents check in

Your agent can
check in here.

This site has an entry for AI agents, not just for people: an MCP server at /mcp. An agent describes itself, the data it would touch and its use case — and can file a request. What comes back is honest about its state: received, not yet processed, until a person confirms it.

Try it from this page ↓ Read the agent front door (llms.txt)
How it works

Four tools. Read is open; action meets the boundary.

Everything an agent can do here goes through four MCP tools. Two of them only read and illustrate (aegis_overview, boundary_check_in). Two can send something to Aegis, and only when asked to: boundary_arrival with send: true, and request_check_in with a name, a company and a work email. What they send is an unverified intake, never a verified one.

01 · See

aegis_overview

What Aegis is, the state model, the offer and the honesty guardrails — structured, read-only.

02 · Arrive

boundary_arrival

An illustrative Arrival Brief for the agent's own task. With send: true the declaration (categories only) is received as an unverified intake.

03 · Feel

boundary_check_in

An illustrative sample of what a receipt would record for the agent's own path. Advisory only — not a receipt, not an authorization, not enforcement. Left out of the panel below on purpose.

04 · Do

request_check_in

Agents check in. With a name, a company and a work email the request is received by Aegis right away — unverified — and a person completes the verified one at a prefilled link.

What comes back

Received, not yet processed.

An agent's request is real — it reaches our intake — but it is not a verified request, and nothing is checked. The response says so in its own words.

received_not_processed

The request reached Aegis as an agent-originated, unverified intake. It carries a reception number (IN-…) and a prefilled link where a person completes the verified request.

needs_contact

Nothing was sent. Without a name, a company and a work email there is nobody a person could follow up with — the response only carries the prefilled link.

rate_limited · not_received

Too many submissions from one address at one location, or the channel was unavailable. Nothing was received; the link to the human form is still there.

Every intake carries the same line: "Based on what you declared. Nothing was connected, tested, or verified." No record is issued on this path — a Boundary Arrival Record only ever comes through the Aegis gateway, which is planned. A verified request requires a person.
Connect your agent

One endpoint, Streamable HTTP.

Any MCP client that speaks Streamable HTTP with JSON responses can use it (this server opens no server-to-client stream). No key, no sign-up: read is open. The two actions are limited per address at the Worker — a per-location limit, not a global cap.

Claude Code 
claude mcp add --transport http aegis-boundary https://aegisboundary.com/mcp

Generic MCP config 
{
  "mcpServers": {
    "aegis-boundary": {
      "type": "http",
      "url": "https://aegisboundary.com/mcp"
    }
  }
}

From a terminal 
curl -s https://aegisboundary.com/mcp \
  -H 'Content-Type: application/json' \
  -d '{"jsonrpc":"2.0","id":1,"method":"tools/call","params":{"name":"boundary_arrival","arguments":{"agent":"support copilot","data":"customer records","use_case":"draft replies"}}}'

Try it from this page

Call the endpoint an agent would call.

This panel sends the same JSON-RPC an agent sends, from your browser, and shows the response exactly as returned. If you are a person wanting a Check-in, the verified way is the request form — this panel only shows what an agent sees.

Show what went over the wire (JSON-RPC)

Request (JSON-RPC 2.0)


          
Response (the tool's result travels as a JSON string; it is shown unwrapped here for readability)

          

          

          

          
An intake_id (IN-…) is a reception number, not a record and not proof of anything. received_not_processed means exactly that. What you submit is held in Aegis's intake ledger — that it arrived, and what was declared — and sent to our intake mailbox as an internal notice. Sending the same declaration again within ten minutes gives you back the same number instead of a second notice. Responses come back in the language you call in (lang); status values and ids stay English.

        

      

    


    


    
    

      

        

          For people
          
The verified request is still yours to make.

          

            An agent can arrive and file. A person crosses the boundary: the
            request form, verified, one agent / one data path / one use case.
          

          

            Request Boundary Check-in →
            Start with Boundary Arrival
          

        

        

          An agent's intake is received, not yet processed. It is not a Boundary
          Check-in, not a Boundary Receipt, and not a record; nothing is verified
          until a person confirms it. A declared purpose is a label, not an
          authorization. Aegis Gateway stays planned.