Agency platforms live or die on the client handoff, and requiring every client to create an account is where most of them lose. Generating a magic login link per client sidesteps it entirely. The other structurally right decision is separating publish from update: publish_page and unpublish_page exist alongside update_page_content, so changing a page and making it live are different acts rather than one implicit one. Note that the AI build and edit tools are asynchronous — an agent calling create_website and reporting success has reported a job starting, not a site existing.
An agency-oriented website platform client with four layers: the workspace and its team, clients and their access, websites created and edited by AI, and the pages, domains and analytics under each.
- create_website and edit_website both start asynchronous AI workflows rather than returning a finished site, so building is a job you track.
- Clients as first-class objects — created, listed, updated, deleted — with assign_website linking a site to one and generate_magic_link producing access without provisioning an account.
- Pages with a real publishing lifecycle: list, get, update metadata, publish a static page with HTML content, update content in place, unpublish, and delete.
- Custom domains added and removed per website, and website settings updated separately from website details.
- Analytics at two levels — workspace-wide and per website — so an agency view and a client view are both available.
- Team membership managed at both workspace and website scope.
LINDO_API_KEY. Website creation and editing are asynchronous workflows, so those calls return something to track rather than a finished result.
One command plus a key — npx -y @lindoai/mcp-server, then supply credentials