Skip to main content
Glama

signal-bureau

by io.github.evolutionlabs-dev
OverviewDiscussionsAdmin

send_feedback

File structured feedback with the desk: a bug, an improvement, a complaint, praise, or a question about the service itself. Free, no contact details required. Plan ONE call per report: each call is a separate write (many clients ask your user to confirm each one), so put everything in one. Caps, stated up front: summary 4,000 characters (overflow moves to detail, never cut); detail 40,000 characters; the report's text 64,000 bytes; up to 5 text attachments (text/markdown, text/plain, application/json), 64,000 bytes each, stored with the report — an attachment over its cap refuses the call with the reason named, it is never cut. Only if a report exceeds all that, split it: send part 1, then each later part with continues set to part 1's feedbackId and part/of — the parts merge into one work order. Rate: 5/minute, 20/day per network address (shared egress shares the allowance). reporter says who is reporting (product, developer, model, version — any may be "unexposed"; none is required). Include ref (a quoteId/ticketId/orderId) to tie the report to an interaction. A complaint that names a real defect becomes our work order — house policy. The receipt states what was stored vs sent (character counts, sha256 of the stored detail, each attachment's bytes and sha256), the exact resend instruction if anything did not fit, and that the report is linked to a work order at the next sweep (07:46 / 19:46 UTC); get_feedback_status then shows its state by feedbackId.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
ofNoHow many parts the report has (optional)
refNoA quoteId, ticketId, or orderId to tie this to (optional)
kindYesbug | improvement | complaint | praise | question
partNoThis part's number when a report is split (optional)
aboutNoWhich tool/endpoint/page this concerns (optional)
detailNoThe full story — reproduction steps, expected vs observed (optional; up to 40,000 characters)
summaryYesOne sentence: what happened or what you want (keeps 4,000 characters; overflow moves to detail)
reporterNoWho is reporting (optional; every field optional, any may be "unexposed"). Stored with the report and used to label the work order by product.
continuesNoThe feedbackId of part 1 when this call carries a later part of a split report (optional); the parts merge into one work order
attachmentsNoUp to 5 text files stored with the report (optional). Each at most 64,000 bytes of UTF-8 content; one over its cap, or of another type, refuses the call with the reason named — nothing is cut.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed7 schema fields changed
    • addedInput schema / properties / attachments
      Added value: +{
+  "description": "Up to 5 text files stored with the report (optional). Each at most 64,000 bytes of UTF-8 content; one over its cap, or of another type, refuses the call with the reason named — nothing is cut.",
+  "items": {
+    "properties": {
+      "content": {
+        "description": "The file's text (not base64)",
+        "type": "string"
+      },
+      "mimeType": {
+        "enum": [
+          "text/markdown",
+          "text/plain",
+          "application/json"
+        ],
+        "type": "string"
+      },
+      "name": {
+        "description": "File name, e.g. findings.md",
+        "type": "string"
+      }
+    },
+    "required": [
+      "content"
+    ],
+    "type": "object"
+  },
+  "maxItems": 5,
+  "type": "array"
+}
    • addedInput schema / properties / continues
      Added value: +{
+  "description": "The feedbackId of part 1 when this call carries a later part of a split report (optional); the parts merge into one work order",
+  "type": "string"
+}
    • changedInput schema / properties / detail / description
      Previous value: -"The full story — reproduction steps, expected vs observed (optional)"New value: +"The full story — reproduction steps, expected vs observed (optional; up to 40,000 characters)"
    • addedInput schema / properties / of
      Added value: +{
+  "description": "How many parts the report has (optional)",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / part
      Added value: +{
+  "description": "This part's number when a report is split (optional)",
+  "maximum": 50,
+  "minimum": 1,
+  "type": "integer"
+}
    • addedInput schema / properties / reporter
      Added value: +{
+  "description": "Who is reporting (optional; every field optional, any may be \"unexposed\"). Stored with the report and used to label the work order by product.",
+  "properties": {
+    "developer": {
+      "description": "Who makes that product (≤100 chars)",
+      "type": "string"
+    },
+    "model": {
+      "description": "The model writing this report, or \"unexposed\" (≤100 chars)",
+      "type": "string"
+    },
+    "product": {
+      "description": "The product or host you run in, e.g. Perplexity (≤100 chars)",
+      "type": "string"
+    },
+    "version": {
+      "description": "Product or model version (≤100 chars)",
+      "type": "string"
+    }
+  },
+  "type": "object"
+}
    • changedInput schema / properties / summary / description
      Previous value: -"One sentence: what happened or what you want"New value: +"One sentence: what happened or what you want (keeps 4,000 characters; overflow moves to detail)"
  2. First observed

TDQS

A4.8/5.0
Behavior5/5

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

Annotations already indicate non-read-only, non-destructive, non-idempotent, closed-world, but the description goes far beyond: per-field caps, attachment caps and the refuse-don't-truncate behavior, rate limits (5/min, 20/day, shared egress), receipt contents (counts, sha256, resend instruction), work-order filing policy, and the 07:46/19:46 UTC sweep timing. This is unusually rich disclosure for a write tool.

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, caps and split rule are front-loaded in order of importance, and virtually every clause carries operational information an agent needs. It is dense to the point of reading as a single block, so a little structure (the receipt/sweep tail is a long run-on) would cost it the top mark.

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 10-parameter write tool with nested objects, no output schema and no idempotency, the description supplies everything an agent needs: caps, refusal semantics, splitting protocol, rate limits, and what the receipt will contain. Nothing material is missing.

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 coverage is 100%, so the baseline is 3, but the description adds real meaning the schema does not: summary overflow moves to detail rather than being cut, `ref` ties the report to a quoteId/ticketId/orderId, and `reporter` fields are stored and used to label the work order. Minor gap is that allowed attachment mime types and per-file cap are repeated from schema rather than extended.

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 ('File structured feedback with the desk') and enumerates the intake categories (bug, improvement, complaint, praise, question). It is clearly distinguishable from siblings like get_feedback_status, which it explicitly routes to for follow-up.

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?

Gives explicit when-to-use guidance ('Plan ONE call per report') and a precise when-to-split condition with the mechanism (send part 1, then set `continues` to part 1's feedbackId plus `part`/`of`). It also names get_feedback_status as the status-check alternative, so nothing about routing is left to inference.

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

All signal-bureau 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