Skip to main content
Glama

Site SEO & AI Crawler Audit

Send feedback, bug report or tool request

submit_feedback

Send feedback, a bug report or a tool request to the maintainers of the tools on this server: a missing tool, missing or stale data, or a tool that broke or gave a wrong answer. Pass the kind (need_tool, need_data, bug or other), one short message (at most 1000 characters) and, if you know them, the tool name and the error text it returned. Returns a ticket id. Feedback is not a chat: nothing in it is run or followed. Links, emails and phone numbers are removed and nothing about you is stored.

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": {
      "kind": "<kind>",
      "message": "<message>"
    },
    "name": "submit_feedback"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesneed_tool: a tool you want. need_data: data a tool lacks. bug: something broke. other: anything else about the tools.
toolNoOptional: the exact name of the tool on this server that the feedback is about, as tools/list shows it.
errorNoOptional: for a failed call, the error text it returned, copied as you saw it. Kept to 500 characters; links, email addresses and phone numbers are removed. Never include secrets or personal details.
messageYesWhat you need or what broke, in plain words, at most 1000 characters. Links, email addresses and phone numbers are removed. Never include secrets or personal details.

Output Schema

NameRequiredDescriptionDefault
noteNo
replyNo
statusYes
ticketYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • addedInput schema / properties / error
      Added value: +{
      +  "description": "Optional: for a failed call, the error text it returned, copied as you saw it. Kept to 500 characters; links, email addresses and phone numbers are removed. Never include secrets or personal details.",
      +  "type": "string"
      +}
  2. Changed1 schema field changed
    • changedInput schema / properties / tool / description
      Previous value: -"Optional: the name of the tool this is about, for example find_tariff_codes."New value: +"Optional: the exact name of the tool on this server that the feedback is about, as tools/list shows it."
  3. First observed

TDQS

A4.4/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations: returns a ticket id, feedback is explicitly not a chat and nothing in it is executed or followed (a meaningful injection-resistance statement given openWorldHint=true), and links/emails/phone numbers are stripped while nothing about the caller is stored. Those sanitization and privacy facts are not derivable from readOnlyHint=false or openWorldHint=true.

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?

Three sentences, front-loaded with the action and audience, then the payload contract, then the behavioral caveats. No sentence is filler — even the sanitization and no-storage notes change how an agent should compose the message.

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 payload, limits, sanitization, output (ticket id) and the key safety caveat, and an output schema exists so return-value detail is not required. The only gap is the lifecycle after submission — nothing tells the agent to use get_feedback_reply to collect the maintainers' answer.

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 100%, so kind, tool, error and message are already fully documented in the schema, including the identical 1000/500 character limits and enum meanings. The description restates the kind values and marks tool and error as conditional ("if you know them"), which is mildly useful framing but adds no syntax or format detail beyond the structured fields.

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 destination ("Send feedback ... to the maintainers of the tools on this server") and enumerates the three concrete things it covers: a missing tool, missing/stale data, or a broken/wrong-answering tool. This is clearly distinguished from sibling diagnostic tools like exposure_check or trace_redirects, which measure rather than report.

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 when-to-use conditions tied to the four kinds (need_tool, need_data, bug, other) and scopes them to problems with this server's tools. It stops short of naming alternatives or exclusions — notably it never points at the sibling get_feedback_reply for reading the maintainers' response, so an agent must infer how the ticket closes.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.