Skip to main content
Glama

submit_feedback

Idempotent

Send feedback, bug reports, feature requests or telemetry to the Spacesheep team as the authenticated account. No browser or human interaction required. Keep message short and human; put what the team should see verbatim in attachment — the failing command and its output, the exact error text — up to 100,000 characters, secrets redacted. It is stored as a file beside the message, shown as a chip on the thread and read in full by the team. Optional category, tags and metadata are saved with the message; message plus context must fit within 20,000 characters. Reuse client_id when retrying; do not include secrets.

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

Input Schema

NameRequiredDescriptionDefault
tagsNo
messageYesFeedback details. Do not include secrets.
categoryNo
metadataNo
client_idYesUnique ID for this submission; reuse it on retries to avoid duplicate feedback.
attachmentNoWhat the team should see verbatim, as a file beside the message rather than inside it: the tail of the session transcript, the failing command and its output, the exact error. You decide what the team needs; keep the message itself short.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.7/5.0
Behavior5/5

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

Beyond the annotations (idempotentHint=true, destructiveHint=false), the description discloses the storage model (saved as a file beside the message), the UI outcome (shown as a chip on the thread, read in full by the team), the size limits for attachment and message-plus-context, the retry/idempotency contract via client_id, and the secrets-redaction requirement. This is unusually rich behavioral context that the structured fields do not carry.

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?

The content is front-loaded (purpose first, then the message/attachment split, then the constraints) and every sentence carries a concrete rule, with no filler. It is nonetheless a dense, run-on single paragraph with many distinct rules packed together, which slightly hurts scannability.

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 write tool with six parameters, a nested object, and no output schema, the description covers what the agent must know: size limits, secrets redaction, retry behavior, the attachment/message division of labor, and what happens downstream to the submission. Nothing needed to invoke it correctly is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

With only 50% schema description coverage, the description compensates strongly: it explains the intended split between message (short, human) and attachment (verbatim command output / exact error, up to 100,000 characters, shown as a chip), the purpose of client_id reuse on retries, and that category/tags/metadata are optional and stored with the message. The 20,000-character 'message plus context' constraint is slightly ambiguous against the schema's message maxLength, but the added semantic value is substantial.

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 names a specific verb (Send) and a specific resource/audience (feedback, bug reports, feature requests or telemetry to the Spacesheep team) and pins the scope to 'as the authenticated account'. No sibling tool competes for this capability, so an agent can identify it immediately without ambiguity.

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?

It states the applicable contexts (feedback, bug reports, feature requests, telemetry) and explicitly notes 'No browser or human interaction required', clarifying it is the agent-facing path. It also gives intra-tool routing guidance (short message vs verbatim attachment). What is missing is any explicit when-not or named alternative, so it falls short of a 5.

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.

Resources