EasyTerritory MCP

List Designer Projects

list_designer_projects

Read-onlyIdempotent

Lists the EasyTerritory Designer rolodex projects the linked Designer user can read: project_id, label, description, tags, saved_at, is_mine, and layers (point data present). q filters by text, tag by rolodex tag, mine=true to the user's own. project_id is the input to import_designer_project and push_to_designer. Without a link the error is DESIGNER_NOT_LINKED (see link_designer).

Input Schema

Name	Required	Description	Default
`q`	No
`tag`	No
`mine`	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: -"list_designer_projectsDictOutput"

AddedOct 31, 2026

TDQS

A4.5/5.0

Behavior4/5

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

Annotations already declare readOnly, idempotent, non-destructive, so the safety profile is covered; the description adds real behavioral context beyond that — the access scoping to the linked Designer user and the specific DESIGNER_NOT_LINKED failure mode with a recovery path. It stops short of saying anything about result volume or ordering.

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 the verb and resource, then filters, then downstream use, then error handling — a sensible ordering with no filler sentences. The enumerated return field list is partly redundant with the existing output schema and makes the block denser than needed.

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

Completeness4/5

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

Covers the prerequisite link, filter semantics, error code, and downstream consumers, which is what an agent needs to call it correctly; the output schema handles return shape. Minor gaps are query-matching behavior and whether results are bounded or ordered.

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 carries the burden and does explain all three parameters: q is a text filter, tag matches a rolodex tag, mine=true restricts to the user's own projects. It leaves q's matching semantics (substring vs. full-text) and tag format unstated, so not a 5.

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 ('Lists the EasyTerritory Designer rolodex projects the linked Designer user can read') and scopes it to read-accessible projects. It also names the downstream consumers (import_designer_project, push_to_designer), which distinguishes it from those siblings without opening their schemas.

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

Usage Guidelines5/5

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

Explicitly explains each filter's purpose ('q filters by text, tag by rolodex tag, mine=true to the user's own') and states the prerequisite link plus the alternative tool on failure ('Without a link the error is DESIGNER_NOT_LINKED (see link_designer)'). It also tells the agent what to do with the result (project_id feeds import/push).

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?