MoveToGermany.lol

Moving to Germany? Skip the 30 tabs. One application. Two operators. One shared state.

Comment

One shared workspace where you and your agent build your new life in Germany.

Inspiration

Moving to another country means rebuilding almost your entire everyday life from scratch.

Bank account. Health insurance. Doctors. Groceries. Transportation. Paperwork. Jobs. Local services. Appointments.

The information is out there, but it is scattered across dozens of websites, search results, forms, tabs, and directories.

I know this problem personally. I've been traveling since 2019 as a German, just not to Germany. ;-)

We're a digital nomad family of five, and every time we arrive somewhere new, we have to rebuild parts of our everyday life again.

Finding the information isn't even the hardest part. The hard part is turning hundreds of search results, websites, providers, and options into your plan.

That's what made me curious about WebMCP. What if an agent didn't have to look at a website and guess how to use it? Which button should it click? What does this field mean? What state is the application currently in?

Instead, what if the application could expose its capabilities directly to the agent, while the human continued using the normal website?

That's the experiment behind MoveToGermany.lol.

What it does

MoveToGermany.lol explores a different future: instead of doing all of this alone, you and your agent work together inside the same web application.

The agent does the repetitive work. The human makes the decisions.

Humans + agents together

The core idea behind MoveToGermany.lol is simple: the agent doesn't replace the website, and it doesn't replace the human.

A user can say:

I'm moving to Berlin, postal code 10115. I'm a software developer, I have a dog and I only speak English. Set me up with the essentials.

The agent can turn that request into actions inside MoveToGermany: create an arrival profile, discover relevant services, and start building a personalized relocation plan.

But the results don't disappear into a chat. They become part of the actual application state.

I can inspect the recommendations myself, change the shortlist, remove something, pick another provider, or leave a note: "English-speaking only."

Then I can hand control back to the agent. It reads the state I just changed manually and continues from there. For example, it can see that I rejected a provider, understand my note, find a better alternative, and continue building the plan.

That's the part of WebMCP I find most interesting:

Human intent → Agent action → Shared application state → Human decision → Agent continues

What can the agent actually do?

MoveToGermany exposes WebMCP tools across different parts of the relocation journey. Underneath that workflow is a discovery layer of more than 1.16 million real places across 81 categories in Germany.

The agent can:

  • build a personalized arrival profile and starter plan
  • discover nearby services
  • manage and reason over the user's shortlist
  • read notes and decisions made directly in the UI
  • compare providers and find jobs
  • help with paperwork and draft outreach
  • find bookable services and propose appointments

The goal wasn't to build one impressive AI command. I wanted to see what happens when the whole web application becomes a workspace that a human and an agent can operate together.

Why WebMCP?

An agent could theoretically operate MoveToGermany by looking at the page and trying to click through the UI. But the application already knows what it can do. Why make the agent guess?

Without structured tools, the interaction looks something like:

Agent → inspect page → guess UI → click → inspect again → hope

With WebMCP, we get closer to:

Human intent → Agent → WebMCP tool → Application

This isn't a chatbot added on top of the website. The WebMCP tools operate on the same application state the human sees and edits, so the human can take over, make a decision, and the agent can continue from there.

WebMCP turns the website itself into the shared workspace.

How I built it

Tech stack

  • Next.js
  • React
  • TypeScript
  • Tailwind CSS
  • Supabase / PostgreSQL
  • Vercel
  • WebMCP

The WebMCP tools are registered directly in the application using document.modelContext.registerTool():

document.modelContext.registerTool({
  name: "...",
  description: "...",
  inputSchema: {
    // structured input
  },
  execute: async (input) => {
    // interact with the application
  }
});

That's the whole mechanism: one underlying application state, read and written by both the regular UI and the agent.

Challenges I ran into

The biggest challenge wasn't exposing individual functions as tools. It was deciding where the agent should act autonomously and where the human should remain in control.

Searching through hundreds of providers is a great job for an agent. Filtering and comparing them is, too. But choosing the final provider, approving outreach, or confirming an appointment should remain a human decision.

Another challenge was shared state. If the agent builds a plan and the human changes it manually, the agent shouldn't continue working from an outdated version of reality. That pushed me to treat every state change as something either side could make, and to design the tools to read the current state instead of assuming their own version of it.

Accomplishments that I'm proud of

I'm proud that I could reuse a service dataset I had built previously as the discovery layer for a completely new WebMCP application.

I'm also proud that this shows agents can make a small, unglamorous problem, one that a lot of people run into, genuinely easier. An agent working through MoveToGermany can meaningfully reduce the amount of searching, tab-switching, and manual comparison involved in settling into a new country.

What I learned

My biggest takeaway from building MoveToGermany.lol is that making websites usable by agents isn't only about automation. It's about collaboration.

Agents are good at searching, filtering, comparing, and repetitive work. Humans provide context, preferences, judgment, and final approval. The interesting part happens when control can move naturally between the two: work gets done, reviewed, changed, and picked back up again.

That feels less like automating a website and more like designing a new kind of interface.

What's next

MoveToGermany.lol is about relocation, but the experiment is bigger than relocation.

I want to explore what happens when more websites stop treating agents as visitors that need to imitate humans, and start exposing meaningful capabilities directly, while keeping the human in the loop.

One application. Two operators. One shared state.

Built With

Share this project:

Updates

Submission history