amendor-mcp

Get change request

get_change_request

Read-onlyIdempotent

Retrieve full details of a change request including the user request, targeted element (CSS selector and outerHTML), page URL, and screenshot URL to implement the change.

Instructions

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.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`id`	Yes	Change request id, from list_change_requests.

Output Schema

TableJSON Schema

Name	Required	Description
`id`	Yes	Change request id.
`status`	Yes	Current status.
`page_url`	Yes	URL of the page the request was made on.
`requested_by`	Yes	Requester email, or "anonymous".
`request_text`	Yes	What the user wants.
`revision_requested`	Yes	True if the requester reviewed a preview and asked for changes; push to the same branch/PR.
`revision_comment`	Yes	The revision note, or empty string if none.
`elements`	Yes	Elements attached to the request; empty for a general request.
`screenshot_url`	Yes	Absolute screenshot URL, or empty string.
`attachment_urls`	Yes	Absolute URLs of any extra attachments.

Schema Changelog

Changes observed during successful MCP inspections.

Changed2 schema fields changedv0.1.4Jun 22, 2026

addedInput schema / properties / id / description

Added value: +"Change request id, from list_change_requests."

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": false,
+  "properties": {
+    "attachment_urls": {
+      "description": "Absolute URLs of any extra attachments.",
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    "elements": {
+      "description": "Elements attached to the request; empty for a general request.",
+      "items": {
+        "additionalProperties": false,
+        "properties": {
+          "html": {
+            "description": "outerHTML of that element; may be empty.",
+            "type": "string"
+          },
+          "selector": {
+            "description": "CSS selector of the element the user pointed at.",
+            "type": "string"
+          }
+        },
+        "required": [
+          "selector",
+          "html"
+        ],
+        "type": "object"
+      },
+      "type": "array"
+    },
+    "id": {
+      "description": "Change request id.",
+      "type": "string"
+    },
+    "page_url": {
+      "description": "URL of the page the request was made on.",
+      "type": "string"
+    },
+    "request_text": {
+      "description": "What the user wants.",
+      "type": "string"
+    },
+    "requested_by": {
+      "description": "Requester email, or \"anonymous\".",
+      "type": "string"
+    },
+    "revision_comment": {
+      "description": "The revision note, or empty string if none.",
+      "type": "string"
+    },
+    "revision_requested": {
+      "description": "True if the requester reviewed a preview and asked for changes; push to the same branch/PR.",
+      "type": "boolean"
+    },
+    "screenshot_url": {
+      "description": "Absolute screenshot URL, or empty string.",
+      "type": "string"
+    },
+    "status": {
+      "description": "Current status.",
+      "type": "string"
+    }
+  },
+  "required": [
+    "id",
+    "status",
+    "page_url",
+    "requested_by",
+    "request_text",
+    "revision_requested",
+    "revision_comment",
+    "elements",
+    "screenshot_url",
+    "attachment_urls"
+  ],
+  "type": "object"
+}

First observedv0.1.0Jun 22, 2026

TDQS

A4.3/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true and destructiveHint=false, establishing safety. The description adds value by detailing the exact return fields (user request, element, page URL, screenshot URL), which is beyond what annotations provide. No contradiction; the description complements annotations with useful behavioral context about the response content.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that immediately states the tool's purpose ('Get full detail for one change request') and then lists key details. Every word is necessary; there is no redundancy or filler. The instruction to call before making the change is efficiently integrated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (1 param, output schema exists, annotations cover safety), the description is complete. It explains what the tool returns, when to use it, and how to obtain the required input. The presence of an output schema means detailed return value documentation is not needed in the description.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single parameter 'id' is fully described in the schema (100% coverage) as 'Change request id, from list_change_requests.' The description does not add additional semantic meaning beyond what the schema already provides. Baseline 3 is appropriate since the schema handles the explanation.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the verb 'Get', the resource 'full detail for one change request', and specifies what is included (user request, element, page URL, screenshot URL). It also implies the tool's role in the workflow by saying 'Call this before making the change', distinguishing it from siblings like list_change_requests (list all) and update_status (update).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines4/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description explicitly says 'Call this before making the change', providing clear when-to-use guidance. While it doesn't list exclusions or alternatives, the context of sibling tools (list, set, update) makes the intended usage clear. The instruction to use before implementation is strong guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server