Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type @ followed by the MCP server name and your instructions, e.g., "@amendor-mcp show me the change requests"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Connect your coding agent to Amendor.
Amendor lets the people you build for request changes right on your live site. Requests land on a board. This connector pulls them into your agent (Claude Code, Cursor, Cline, Codex, any MCP client) so it can build each one on a branch and open a pull request.
Sign in at amendor.site and create a project.
Go to Settings and copy the connector command. It already has your token filled in and looks like this:
claude mcp add amendor --env AMENDOR_API=https://amendor.site --env AMENDOR_TOKEN=your-token -- npx -y amendor-mcpRun it in your repo.
AMENDOR_TOKEN is the key that ties the connector to your Amendor account. You do not make it up. Amendor generates it and shows it inside the ready-made command on the Settings page, so create a project first, then copy the whole command.
Related MCP server: bgagents
Ask your agent: "show me the change requests," pick one, "build that one." It opens a pull request, your host builds a preview, the requester approves, you merge.
Tools: list_change_requests, get_change_request, start_build, set_preview_url, publish_preview, update_status, ship_change.
MIT license. More at amendor.site.
Get full detail for one change request so you can implement it: the user request, the exact element they pointed at (CSS selector + outerHTML), the page URL, and a screenshot URL. Call this before making the change.
Inputs: id (required). Returns: id, status, page_url, requested_by, +6 more
List change requests submitted by end users on sites you ship. Optionally filter by status. Start here to see what people are asking for.
Inputs: status. Returns: requests
Mark a change request ready for the requester to review. The preview is already live from the worktree; this flips status to "in preview" and surfaces the link.
Inputs: id (required). Returns: id, status, review_url
Attach a deploy-preview URL to a change request and mark it ready for the requester to review.
Inputs: id (required), url (required). Returns: id, status, review_url
Ship an approved change: merge the task branch into the project base, remove the worktree, and mark it shipped. Production (the live site) now reflects the change.
Inputs: id (required). Returns: id, merged, into, status
LOCAL MODE ONLY (repo on this machine, no host). Cuts a branch + git worktree the local Amendor serves at /preview//. For the normal GitHub flow, do NOT call this: instead branch "relay/task-" in your own repo clone, edit, commit, push, and open a PR tagged "relay-task:" — the host builds the preview and the webhook captures it automatically.
Inputs: id (required). Returns: id, branch, base, worktree, +1 more
Update a change request status as it moves through the build and review flow.
Inputs: id (required), status (required). Returns: id, status
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
Loading tool schema changelog…
Scored across 7 tools
Most tools have distinct purposes, but publish_preview and set_preview_url both mark a change request as ready for review, potentially confusing an agent. start_build is a separate local-mode flow that could be misused if the normal GitHub flow is expected.
All tool names follow a consistent verb_noun pattern in snake_case (e.g., get_change_request, publish_preview, ship_change), making them predictable and easy to understand.
With 7 tools covering listing, detail retrieval, status updates, preview management, and final shipping, the count is well-scoped for managing change requests without excess or deficiency.
The tool set covers the main lifecycle but lacks a creation tool, which is acceptable if change requests are always created externally. update_status provides flexibility for status transitions.
Hosted coding agent: start, follow up on and stop tasks that can open GitHub pull requests.
Agent-first hosting: create apps, push code, and deploy to HTTPS URLs from your coding agent.
Build and deploy websites, Telegram and Discord bots from chat via the DreamAgent platform.
Host files from coding agents; stage on a branch and attach to GitHub PRs.
