
agenthost
eu.agenthostPublished by agenthost.euOfficial publisherv0.1.0Updated Oct 24, 2026
Agent-first web hosting: deploy sites, apps, databases and domains over MCP.
Overview
Agent-first web hosting exposed as a remote MCP server, letting an assistant deploy sites, apps, databases and domains.
- What you can do
- Deploy and manage web hosting resources: sites, applications, databases and domains, driven through the MCP server rather than a control panel. Connect over Streamable HTTP to the hosted endpoint; no local installation is involved. Sign in through the client's OAuth flow, or use a long-lived API token as a Bearer header for unattended clients.
- When to use it
- Useful when you want an AI assistant to provision or publish web hosting — sites, apps, databases or domains — on agenthost without leaving the chat or clicking through a control panel.
- Requirements
- A remote MCP server at the agenthost endpoint over Streamable HTTP; nothing to install locally. Authentication is required: OAuth sign-in or sign-up in a browser, or an API token sent as a Bearer header for clients that cannot open a browser. Network access to the endpoint.
Installation
In SourceWeft
- Open agenthost in the dashboard and add it to a workspace.
- Connect the required credentials. They are stored privately and never shown on public pages.
- Enable the server for the chats that should use its tools.
Web executable via Streamable HTTP. Remote servers run from the web runtime once configured in a workspace.
Use with an agent
Paste this prompt into Claude Code, Codex, Cursor or another agent — or into SourceWeft chat. The agent reads this server's install guide, shows you its publisher, endpoint and sign-in, and adds it to your client once you agree. Keys never go into a command.
Read https://sourceweft.com/mcp/eu.agenthost%2Fagenthost/install.md and connect the MCP server it describes to my client. Before changing any config, show me its publisher, endpoint and sign-in method and wait for my OK. Never put an API key in a command or in a file I would commit; ask me where it should come from.Other MCP clients
Add this to your client's mcpServers config. The client completes OAuth sign-in on first connect.
{
"mcpServers": {
"agenthost": {
"type": "http",
"url": "https://agenthost.eu/mcp"
}
}
}README
agenthost MCP server
agenthost is agent-first web hosting, driven entirely
through an MCP server. This repository holds the MCP Registry
listing for it — server.json — and the workflow that publishes
that listing.
agenthost is a remote MCP server: it is hosted by agenthost and reachable over
Streamable HTTP
at https://agenthost.eu/mcp. There is nothing to install locally.
- Registry name:
eu.agenthost/agenthost - Endpoint:
https://agenthost.eu/mcp(Streamable HTTP) - Website: https://agenthost.eu
The server code itself lives in agenthost's private control-panel repository; this repository only carries the public registry metadata.
Connecting
Point any MCP client that speaks Streamable HTTP at https://agenthost.eu/mcp.
Authentication is handled by the client's OAuth flow — you sign in (or sign up) at
agenthost in your browser, so there is no token to paste. For unattended clients
that cannot open a browser, agenthost can mint a long-lived API token to send as a
Bearer header.
Example client configuration:
Publishing
Publishing is automated with GitHub Actions (.github/workflows/publish-mcp.yml).
The registry entry is namespaced under eu.agenthost — the reverse-DNS form of
agenthost.eu — and ownership is proven with DNS authentication: a TXT record
on the apex of agenthost.eu holds the public half of an Ed25519 signing key, and
the workflow signs with the private half stored in the MCP_PRIVATE_KEY secret.
- Every push and pull request validates
server.jsonagainst the official schema (mcp-publisher validate) — no secret required. - Pushing a
v*tag (or running the workflow manually) publishes to the registry. On a tag, the published version is taken from the tag, so the git tag is the single source of truth for the registry version.
To cut a release:
Verify afterwards:
One-time DNS auth setup
Generate the signing key on a trusted machine (needs OpenSSL 3+), so the private key never leaves your control:
Then:
- Add the TXT record from step 2 on the apex of
agenthost.eu(agenthost.eu, not a_mcp-authsubdomain). Wait for it to propagate. - Add the private key from step 3 as a repository secret named
MCP_PRIVATE_KEY(Settings → Secrets and variables → Actions). For stronger protection, store it instead on a GitHub Environment namedmcp-registry-publishand restrict that environment to the default branch and release tags — the workflow already references that environment. - Delete
key.pemonce the secret is stored.
If you rotate the key, remove the old TXT record from the apex — a stale record is tried first and will fail verification.
Editing server.json
server.json follows the MCP Registry
server.schema.json
(the $schema field pins the exact version). Keep the remotes[].url in sync with
the production endpoint, and keep description within the schema's 100-character
limit. CI validates every change, so a malformed edit fails in review.
Source: README.md at commit 23dd919
Tools
0Version history
1- v0.1.0LatestSep 16, 2026
Score
75% of the applicable checks met
How complete this listing is, computed from the registry entry, the endpoint and public sources. Not a rating of the server and not a statement that it is safe or working today: reachability is a dated check, and no installs or reviews go into the score.
- Reached in the last 30 daysRequired25 pts
- Auth declaredRequired10 pts
- Tools listed15 pts
Answer tools/list without a credential, or ship a package that starts in a sandbox without one.
- DescriptionRequired15 pts
- Logo10 pts
- Documentation15 pts
- License10 pts
Declare a license in the repository or the registry entry.