Hosted REA and Website Builder MCP: What's New

Two new projects at API to Agents bring more of your work into the assistant you already use: hosted REA MCP for investigating software you are authorized to analyze, and a website builder MCP for turning a conversation into a website project you can keep working on.

They are at different stages. Hosted REA requests are open, with dedicated endpoints prepared individually. The website builder is coming soon; its current MCP implementation is a pilot, and public access is not open. This October 19 update explains the experience behind each project, what you can request today, and what remains ahead.

Hosted REA MCP: ask questions about software without managing the local setup

REA stands for Reverse Engineer Anything. The original morluto/rea project supplies software-analysis workflows through MCP. Our apitoagents/rea fork builds on that work; credit for REA and its original MCP implementation belongs to the upstream authors.

Our earlier REA walkthrough explains a local setup, where the tools run on a machine with your target files and analysis engines. The hosted REA offering addresses the installation and operation of that environment. Its announced scope is a remote, authenticated endpoint with managed analysis engines, focused on static analysis of uploaded software.

That matters when you want to investigate an application from a hosted assistant without installing REA and its native analysis dependencies yourself. You describe the target and client you need; we confirm the setup and provide connection details when your endpoint is ready.

From an access request to a useful investigation

The early-access journey has four steps:

Request your endpoint. Use the hosted REA form to tell us which assistant you use, what you need to analyze, and the authorized context for the work.
Confirm the setup with us. We contact you about your requirements. The endpoint URL, credentials, and client-specific instructions follow once the dedicated endpoint is ready.
Connect and supply an allowed target. Follow those instructions and upload software within the agreed scope. Submitting the request form does not immediately create a working connector.
Ask a bounded question and inspect the evidence. Start with a specific part of the application, then ask follow-up questions about the files, relationships, and uncertainties the analysis identifies.

For example, imagine a team investigating a packaged version of its own desktop reporting application. A useful request would be:

Analyze the uploaded build we own. Identify the modules and static relationships involved in exporting a report. Give evidence references and list anything you cannot determine without running the application.

Then ask:

Which findings are directly supported by the artifact, which are inferred, and what should our engineers verify before changing the export feature?

These are illustrative prompts, not results from a customer investigation. The intended outcome is an explanation your team can check, including unresolved questions. Static analysis does not establish that a suspected code path actually ran.

Scope and responsible use

The hosted offering is scoped to static analysis. Running, attaching to, or instrumenting uploaded programs is outside that scope. The product page describes the intended managed engines and session isolation; confirm the supported target, data handling, and retention arrangements for your endpoint before submitting confidential material.

Use REA only for lawful work on software you own or are authorized to analyze, and only where the application's or service's terms permit the intended use. It is not permission to bypass access controls, licensing, or payment restrictions. API to Agents operates independently of the REA maintainers. Results returned to ChatGPT or Claude are also subject to your assistant provider's data policies.

Website builder MCP: from a brief to a plan, build, and preview

The website builder takes a different kind of request: describe the site you want, answer the questions needed to make it concrete, review the plan, and ask the assistant to start a build.

The published design covers a full application: pages and forms, backend routes, data storage, generated illustrations, deployment artifacts, and documentation. The project lives in a Git repository, with code and decisions that a developer can inspect. Public access is still coming soon; the builder overview separates the intended service from its current availability.

Example: a website for a small architecture studio

Here is an illustrative brief for the planned experience:

Create a website for Atelier North, a small architecture studio. We need Home, Projects, About, and Contact pages. Use a quiet editorial style, warm white backgrounds, and dark green accents. Include a project gallery and an enquiry form. Ask us for approved project photographs and the destination email. Do not add payments or client accounts. Done means the pages work on mobile, the gallery is keyboard accessible, and the form reports success and failure clearly.

That gives the assistant an objective, content structure, design direction, boundaries, and concrete acceptance checks. It also leaves questions visible instead of asking the builder to invent contact details or project images.

The current MCP tool surface supports the following sequence:

Create and describe: create_site creates the project; describe_site saves the brief, including pages, features, constraints, and acceptance criteria.
Plan and clarify: plan_site starts planning; answer_questions supplies answers when the planner needs more information.
Build the reviewed plan: build_site starts the build workflow and provisions the repository on first use.
Follow progress: site_status reports the plan, current job, and next action. site_events provides the event history, while list_sites helps you return to an existing project.

The connection and tools guide documents these operations. A request to start work is not evidence that it has finished: the assistant should report the returned job status and share a preview only when one is available. A failed build should be reported as a failure.

The pilot combines quoting and approval inside its planning and build calls, and reports credit information in the results. It should not be described as a separate public checkout or customer approval screen. Public accounts, payments, and pricing are not open yet.

Keep improving the same project

After reviewing a preview, a useful follow-up would be:

Keep the existing pages. Add a project filter by building type, make the enquiry form easier to use on a phone, and show me the changes in a new preview.

The intended workflow starts from the current repository and updates its plan and checks. The repository guide describes the source code, specifications, decisions, runbook, and migration documentation that accompany a site. That gives your own developers a place to inspect the work and contribute.

The transfer and maintenance guide explains the planned path to running the project on your own infrastructure. A move still requires configuring the destination, moving data, deploying, and testing. Custom domains and public production publishing are later steps; a pilot preview is not a general launch on your business domain.

How the MCP connection fits into ChatGPT and Claude

MCP carries tool requests and results between the assistant and a service. Its transport specification distinguishes a client-launched local process from an HTTP endpoint. Hosting changes where the service runs and how the client reaches it; each service still needs its own access and operating rules.

OpenAI documents adding a custom MCP server through ChatGPT Plugins. Anthropic documents custom connectors for remote MCP. Account access, workspace policies, and the endpoint's authentication requirements affect the setup. Follow the connection instructions supplied for your endpoint rather than assuming the same menu or sign-in flow applies everywhere.

The two projects remain separate services. Connecting hosted REA does not also connect the website builder, and analyzing an application does not authorize copying it into a new website.

What you can do today

For hosted REA: request a dedicated endpoint. Tell us your assistant, target type, and authorized use case. The current early-access page states that nothing is charged in this phase and that connection details are supplied after individual preparation.

For the website builder: explore the planned service and tell us what you want to build. Include your pages, features, design references, and anything that must remain out of scope. We can discuss the project while public access is being prepared; there is no public connector URL to install today.

Both projects put a concrete workflow behind a conversation: investigate software and review the evidence, or describe a site and review the implementation. Choose the workflow you need, keep the scope explicit, and inspect the result before relying on it.