amendor-mcp
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| AMENDOR_API | No | The URL of the Amendor API | https://amendor.site |
| AMENDOR_TOKEN | Yes | Your Amendor project token (required) |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| list_change_requestsA | List change requests submitted by end users on sites you ship. Optionally filter by status. Start here to see what people are asking for. |
| get_change_requestA | 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. |
| set_preview_urlA | Attach a deploy-preview URL to a change request and mark it ready for the requester to review. |
| update_statusA | Update a change request status as it moves through the build and review flow. |
| start_buildA | 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. |
| publish_previewA | 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. |
| ship_changeA | 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. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
No prompts | |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
No resources | |
TDQS
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.