EasyTerritory MCP

Submit Feedback

submit_feedback

Sends product feedback to EasyTerritory: a blocked or partial workflow, a workaround, a confusing response, or a missing capability. Returns an acknowledgement with feedback_id. Secrets, emails, Territory Solution JSON, GeoJSON, and account/CSV tables are stripped before storage; the text is meant for a description of what happened, not data.

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "user_goal": "<user_goal>",
      "what_happened": "<what_happened>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

Name	Required	Description	Default
`category`	No		other
`severity`	No		medium
`user_goal`	Yes	What the user was trying to accomplish, sanitized.
`confidence`	No		medium
`session_id`	No	Client session id, if the host has one.
`client_name`	No
`related_tool`	No
`what_happened`	Yes	Where the agent struggled, failed, found confusing results, or used a workaround.
`client_version`	No
`correlation_id`	No	task_id, job_id, or request id the feedback is about.
`context_summary`	No	Optional sanitized summary only. Excludes credentials, API keys, raw customer data, private territory assignments, and PII.
`include_context`	No
`expected_capability`	No
`related_product_area`	No
`suggested_improvement`	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.

Changed9 schema fields changedNov 1, 2026

addedInput schema / properties / context_summary / description

Added value: +"Optional sanitized summary only. Excludes credentials, API keys, raw customer data, private territory assignments, and PII."

addedInput schema / properties / correlation_id / description

Added value: +"task_id, job_id, or request id the feedback is about."

addedInput schema / properties / session_id / description

Added value: +"Client session id, if the host has one."

addedInput schema / properties / user_goal / description

Added value: +"What the user was trying to accomplish, sanitized."

addedInput schema / properties / what_happened / description

Added value: +"Where the agent struggled, failed, found confusing results, or used a workaround."

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.",
+    "properties": {
+      "feedback_id": {
+        "type": "string"
+      },
+      "message": {
+        "type": "string"
+      },
+      "received_at": {
+        "type": "string"
+      },
+      "status": {
+        "type": "string"
+      }
+    },
+    "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: -"submit_feedbackDictOutput"

First observedSep 29, 2026

TDQS

A4.2/5.0

Behavior4/5

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

Annotations already declare the write-like profile (readOnlyHint=false, destructiveHint=false, idempotentHint=false, openWorldHint=false), and the description adds real value beyond that: secrets, emails, Territory Solution JSON, GeoJSON, and account/CSV tables are stripped before storage, and the free-text fields are for narrative, not data. It omits failure/retry behavior and auth requirements, keeping it from a 5.

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?

Two sentences with zero filler, purpose front-loaded before the sanitization caveat. The dense second clause earns its place by preventing accidental submission of sensitive payloads.

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?

An output schema exists so return values need no explanation, and the description covers purpose, triggers, and data handling. With 15 parameters and low schema coverage, the missing guidance on the optional classification/enum fields (category, severity, confidence, product area) is the one real gap.

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?

Schema coverage is only 33% across 15 parameters, so the schema alone doesn't carry the load; the description compensates only partially by telling the agent to put a description of what happened in the text fields rather than raw data. It says nothing about how to choose category, severity, confidence, related_product_area, include_context, or correlation_id.

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 ("Sends product feedback to EasyTerritory") and enumerates the concrete situations it covers (blocked/partial workflow, workaround, confusing response, missing capability), plus what it returns (feedback_id). Nothing in the sibling list overlaps, so an agent can route here unambiguously.

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?

Gives clear triggering conditions — use this when a workflow is blocked or partial, when a workaround was needed, when a response was confusing, or a capability is missing. No explicit exclusions or named alternatives (e.g., get_guidance or tasks_get for transient errors), so a 4 rather than 5.

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?