EasyTerritory MCP

Link Designer Account

link_designer

Destructive

Connects the customer's EasyTerritory Designer account so list_designer_projects, import_designer_project, and push_to_designer can call Designer from the server. Returns status linked (designer_origin, designer_user) or waiting_for_user with a link_url and share_with_user. The user pastes their Designer agent token (ezt_pat_...) on that page; the token is never a tool argument and never appears in a result. Repeated calls report the status; recommended_poll_delay_ms is the interval. unlink=true removes the stored link.

Input Schema

Name	Required	Description	Default
`unlink`	No

Output Schema

Name	Required	Description
`ok`	Yes
`error`	No	Present when ok is false.
`result`	No	Present when ok is true.
`warnings`	No

Schema Changelog

Changes observed during successful MCP inspections.

Changed4 schema fields changedNov 1, 2026

removedOutput schema / additionalProperties
```
Removed value: -true
```

addedOutput schema / properties

Added value: +{
+  "error": {
+    "description": "Present when ok is false.",
+    "properties": {
+      "ask_user": {
+        "items": {
+          "type": "string"
+        },
+        "type": "array"
+      },
+      "code": {
+        "type": "string"
+      },
+      "details": {
+        "type": "object"
+      },
+      "do_this_next": {
+        "type": "object"
+      },
+      "message": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "ok": {
+    "type": "boolean"
+  },
+  "result": {
+    "description": "Present when ok is true.",
+    "type": "object"
+  },
+  "warnings": {
+    "items": {
+      "properties": {
+        "code": {
+          "type": "string"
+        },
+        "message": {
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

addedOutput schema / required
```
Added value: +[
+  "ok"
+]
```

removedOutput schema / title

Removed value: -"link_designerDictOutput"

AddedOct 31, 2026

TDQS

A4.6/5.0

Behavior5/5

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

Adds substantial context beyond the annotations: exact return shapes (linked with designer_origin/designer_user, or waiting_for_user with link_url/share_with_user), the out-of-band token flow (ezt_pat_ pasted on a page, never an argument, never in a result), polling cadence, and the destructive effect of unlink=true. This clarifies the destructiveHint and openWorldHint annotations rather than merely repeating them.

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

Conciseness4/5

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

Front-loaded with purpose before status/token/polling details, and every sentence carries distinct information. The opening sentence is somewhat overloaded with the sibling list, but nothing is padded.

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?

Covers the tricky parts an agent would otherwise get wrong: user-mediated token entry, why the token never appears as a parameter, poll interval, and unlink semantics. An output schema exists and annotations declare safety, so nothing material is left unstated for a one-parameter linking tool.

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

Parameters4/5

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

Schema description coverage is 0%, so the description must carry the single boolean, and it does: 'unlink=true removes the stored link.' That fully disambiguates the only parameter and implies the false default, though it does not spell out the default value or what unlink returns.

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?

States a specific verb and resource ('Connects the customer's EasyTerritory Designer account') and names the three downstream sibling tools that depend on it (list_designer_projects, import_designer_project, push_to_designer). An agent can immediately tell this is a prerequisite linking/auth step, distinct from every sibling.

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?

Makes the when-to-use case clear: it exists so the Designer tools can call out from the server, repeated calls just report status, and unlink=true removes the link. It stops short of an explicit 'call this first, before push_to_designer' sequencing statement or what to do if status never becomes linked, but the context is strong.

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

All EasyTerritory MCP tools Inspect

Try in Browser

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?