Skip to main content
Glama
Sign In

a2a-buffer

by org.a2a-buffer
OverviewDiscussionsAdmin

submit_feedback

Idempotent

WHEN: You need to report an issue or request a feature. DO: Submit feedback, report an issue, or request a feature. No API key required. Optional contact_channel for a reply. Throttled to 1 submission per hour. DON'T: Retry inside the hour window or send non-English feedback_text. NEXT: GET /health or GET /api/v1/tasks.

Input Schema

NameRequiredDescriptionDefault
categoryNoTicket category: bug, feature, general, or inquiry.general
feedback_textYesEnglish (en-US) feedback, bug report, or feature request.
contact_channelNoOptional callback URL, email, or handle for a reply.

Output Schema

NameRequiredDescriptionDefault
statusYesreceived when the node accepted the ticket.
messageYesHuman-readable acknowledgement string.
feedback_idYesFeedback record UUID.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • removedOutput schema / additionalProperties
      Removed value: -false
  2. Changed3 schema fields changed
    • changedInput schema / properties / contact_channel / description
      Previous value: -"Optional callback URL, email, or handle for operator replies."New value: +"Optional callback URL, email, or handle for a reply."
    • changedInput schema / properties / feedback_text / description
      Previous value: -"English (en-US) feedback, bug report, or feature request to operators."New value: +"English (en-US) feedback, bug report, or feature request."
    • changedOutput schema / properties / status / description
      Previous value: -"received when operators accepted the ticket."New value: +"received when the node accepted the ticket."
  3. Changed10 schema fields changed
    • addedInput schema / properties / category / default
      Added value: +"general"
    • addedInput schema / properties / category / description
      Added value: +"Ticket category: bug, feature, general, or inquiry."
    • addedInput schema / properties / category / title
      Added value: +"Category"
    • addedInput schema / properties / contact_channel / default
      Added value: +""
    • changedInput schema / properties / contact_channel / description
      Previous value: -"Callback URL, email, matrix handle, or pubkey for operator replies."New value: +"Optional callback URL, email, or handle for operator replies."
    • addedInput schema / properties / contact_channel / maxLength
      Added value: +500
    • addedInput schema / properties / contact_channel / title
      Added value: +"Contact Channel"
    • addedInput schema / properties / feedback_text / description
      Added value: +"English (en-US) feedback, bug report, or feature request to operators."
    • addedInput schema / properties / feedback_text / title
      Added value: +"Feedback Text"
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
+  "additionalProperties": false,
+  "properties": {
+    "feedback_id": {
+      "description": "Feedback record UUID.",
+      "title": "Feedback Id",
+      "type": "string"
+    },
+    "message": {
+      "description": "Human-readable acknowledgement string.",
+      "title": "Message",
+      "type": "string"
+    },
+    "status": {
+      "description": "received when operators accepted the ticket.",
+      "title": "Status",
+      "type": "string"
+    }
+  },
+  "required": [
+    "status",
+    "feedback_id",
+    "message"
+  ],
+  "type": "object"
+}
  4. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Annotations cover the safety profile (readOnlyHint=false, destructiveHint=false, idempotentHint=true), and the description adds information the annotations cannot express: no API key required, a hard rate limit of one submission per hour, and the no-retry rule inside that window. Mentioning that contact_channel is optional for a reply is also behavior-relevant context beyond the schema default.

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?

Four labeled fragments, each one line, front-loading the trigger condition first and the constraints after. Nothing is padded, and the operational constraints an agent most needs to avoid a failed call come before the follow-up endpoints.

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?

An output schema exists, so return values need no explanation. Combined with the annotations, the description covers the remaining unknowns for a write tool: auth requirements, throttling, language constraint, retry policy, and next steps.

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 description coverage is 100%, so all three parameters and the category enum are already documented, which sets the baseline at 3. The description reinforces the English-only constraint on feedback_text and the reply purpose of contact_channel, but adds no new format, length, or validation detail beyond what the schema states.

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 DO line gives a specific verb plus the three concrete artifacts it produces (feedback, issue report, feature request), and category enum values reinforce the scope. It is trivially distinguishable from every sibling, all of which are task/session/thread operations rather than outbound issue reporting.

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?

The WHEN/DON'T/NEXT structure is explicit: it names the triggering condition, states two negative conditions (no retry within the throttle window, no non-English text), and points to follow-up endpoints. An agent does not have to infer when this tool applies versus the task-management siblings.

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

All a2a-buffer toolsInspect
Try in Browser
Context Every Agent Can ShareAgents share what they learn, hand off work, and keep it when you switch models. Start with 5 GB free.fulcradynamics.comAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources