Skip to main content
Glama

reassign

by app.reassign
OverviewDiscussionsAdmin

Send feedback

send_feedback

Report a bug, limitation, friction, or idea about reassign itself — its tools, their results, or this MCP integration — to the product team, who read every message. Covers errors, confusing or wrong results, retries or workarounds, loops, and rough edges that could be smoother, plus feedback the user asks to send. This is meta-feedback ABOUT the product, not a way to change the schedule (use write_events for events). Each report has a kind ("bug" | "idea" | "other") and a message. In message, describe what you tried, what happened, what you expected, and any event ids or steps to reproduce. Collect every report of the session into ONE call, with one item in reports for each issue. Do not call this tool once for each issue. Describe the problem in your own words — don't paste the user's personal details or private schedule contents; their account is attached automatically for follow-up. Returns {} once the report is accepted.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
reportsYesAll reports of this session. Add one item for each issue.
submissionIdNoA UUID for this submission. Reuse it with identical content on retries within 24 hours; use a new UUID for a new report.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed6 schema fields changed
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / kind
      Removed value: -{
-  "description": "Type of feedback: \"bug\" for something broken or wrong, \"idea\" for a suggestion or feature request, \"other\" for anything else.",
-  "enum": [
-    "bug",
-    "idea",
-    "other"
-  ],
-  "type": "string"
-}
    • removedInput schema / properties / llm_model
      Removed value: -{
-  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
-  "type": "string"
-}
    • removedInput schema / properties / message
      Removed value: -{
-  "description": "The feedback itself. For a bug, say what happened, what you expected, and any event ids or steps that reproduce it.",
-  "maxLength": 4000,
-  "minLength": 1,
-  "type": "string"
-}
    • addedInput schema / properties / reports
      Added value: +{
+  "description": "All reports of this session. Add one item for each issue.",
+  "items": {
+    "additionalProperties": false,
+    "properties": {
+      "kind": {
+        "description": "Type of feedback: \"bug\" for something broken or wrong, \"idea\" for a suggestion or feature request, \"other\" for anything else.",
+        "enum": [
+          "bug",
+          "idea",
+          "other"
+        ],
+        "type": "string"
+      },
+      "message": {
+        "description": "The feedback itself. For a bug, say what happened, what you expected, and any event ids or steps that reproduce it.",
+        "maxLength": 4000,
+        "minLength": 1,
+        "type": "string"
+      }
+    },
+    "required": [
+      "kind",
+      "message"
+    ],
+    "type": "object"
+  },
+  "maxItems": 10,
+  "minItems": 1,
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "kind",
-  "message",
-  "llm_model"
-]New value: +[
+  "reports"
+]
  2. Changed1 schema field changed
    • removedInput schema / properties / conversation_id
      Removed value: -{
-  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
-  "type": "string"
-}
  3. Changed4 schema fields changed
    • removedInput schema / additionalProperties
      Removed value: -false
    • addedInput schema / properties / conversation_id
      Added value: +{
+  "description": "Echo the conversation_id from the server's previous response. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it.",
+  "type": "string"
+}
    • addedInput schema / properties / llm_model
      Added value: +{
+  "description": "The exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. \"claude-opus-4-8\", \"gpt-5.2\"). Used for analytics only. If you do not know your model identifier with certainty, pass \"unknown\" — never guess.",
+  "type": "string"
+}
    • changedInput schema / required
      Previous value: -[
-  "kind",
-  "message"
-]New value: +[
+  "kind",
+  "message",
+  "llm_model"
+]
  4. Changed1 schema field changed
    • addedInput schema / additionalProperties
      Added value: +false
  5. Changed2 schema fields changed
    • changedInput schema / $schema
      Previous value: -"http://json-schema.org/draft-07/schema#"New value: +"https://json-schema.org/draft/2020-12/schema"
    • addedInput schema / properties / submissionId
      Added value: +{
+  "description": "A UUID for this submission. Reuse it with identical content on retries within 24 hours; use a new UUID for a new report.",
+  "format": "uuid",
+  "pattern": "^([0-9a-fA-F]{8}-[0-9a-fA-F]{4}-[1-8][0-9a-fA-F]{3}-[89abAB][0-9a-fA-F]{3}-[0-9a-fA-F]{12}|00000000-0000-0000-0000-000000000000|ffffffff-ffff-ffff-ffff-ffffffffffff)$",
+  "type": "string"
+}
  6. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations only declare the generic write/open-world profile; the description adds non-obvious behavior: the return value is `{}` on acceptance, the user's account is attached automatically for follow-up, and personal details or private schedule contents must not be pasted into the message. The batching rule (one call per session) is a behavioral constraint found nowhere in the structured fields.

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?

Purpose and scope lead the paragraph, followed by triggering conditions, then the exclusion, then per-field guidance and constraints. Dense and well ordered, though the long enumeration of triggering cases and the restated 'each report has a kind and message' sentence add some redundancy.

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?

For a two-parameter write tool with no output schema, the description covers purpose, when to use, batching, privacy constraints, message content expectations, and the return value. An agent has everything needed to call it correctly and safely.

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 100%, so the baseline is 3, but the description goes further: it defines the `kind` values semantically and specifies what a good `message` contains (what was tried, what happened, what was expected, event ids or reproduction steps), plus the one-item-per-issue structure of `reports`. It does not cover the `submissionId` retry semantics, which remain schema-only.

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 states a precise verb and resource — report a bug, limitation, friction, or idea about the product itself — and explicitly scopes it to meta-feedback about the MCP integration and its results. It also names the sibling it is not (write_events for changing the schedule), so an agent can distinguish it without opening a schema.

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?

It enumerates the triggering conditions (errors, confusing or wrong results, retries, workarounds, loops, rough edges, user-requested feedback) and an explicit exclusion with the correct alternative (use write_events to change the schedule). It further prescribes when to batch versus split (one call per session, not one per issue).

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

All reassign toolsInspect
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