Skip to main content
Glama

submitFeedback

Report a problem back to the DexPaprika team when a tool got you stuck, returned something unexpected, lacked data you needed, or behaved differently than documented. Use whenever you hit a dead end, a response shape surprised you, or coverage was missing; even partial feedback helps and every submission is read. Low friction: provide goal, expected, and observed instead of a rationale field.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
goalYesREQUIRED: What you (or the user behind you) were trying to accomplish. 10-500 characters; longer goals are validation-rejected at the MCP layer.
expectedNoOPTIONAL: What you expected to happen. Capped at 500 characters; trim or summarize longer narratives.
observedNoOPTIONAL: What actually happened. Capped at 500 characters; trim or summarize longer narratives. Longer text triggers an MCP -32602 input validation error.
severityNoOPTIONAL: How badly this affected your task. Default 'minor'.minor
blocked_atNoOPTIONAL: Tool name or step where you got stuck.
attempted_toolsNoOPTIONAL: List of tool names you called, in order, before submitting this feedback.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
okYesTrue if the feedback row was persisted.
messageYes
severityNo
tracking_idNoStable id agents can reference in follow-up submissions; null if persistence failed.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedOutput schema / (root)
      Previous value: -nullNew value: +{
      +  "$schema": "http://json-schema.org/draft-07/schema#",
      +  "additionalProperties": true,
      +  "properties": {
      +    "message": {
      +      "type": "string"
      +    },
      +    "ok": {
      +      "description": "True if the feedback row was persisted.",
      +      "type": "boolean"
      +    },
      +    "severity": {
      +      "enum": [
      +        "blocker",
      +        "major",
      +        "minor",
      +        "nit"
      +      ],
      +      "type": "string"
      +    },
      +    "tracking_id": {
      +      "description": "Stable id agents can reference in follow-up submissions; null if persistence failed.",
      +      "type": [
      +        "string",
      +        "null"
      +      ]
      +    }
      +  },
      +  "required": [
      +    "ok",
      +    "message"
      +  ],
      +  "type": "object"
      +}
  2. First observed

TDQS

A4.6/5.0
Behavior5/5

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

Annotations only provide broad hints (readOnlyHint false, destructiveHint false, etc.), so the description carries the behavioral burden. It discloses that submissions are read, that partial feedback is valued, that there is no rationale field, and that long inputs are validation-rejected at the MCP layer—all useful behavioral context. Nothing in the description contradicts the annotations.

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 description is front-loaded with purpose and follows with concrete usage triggers and a low-friction tip; every sentence serves a role. Minor redundancy exists between 'stuck, returned something unexpected, lacked data' and 'dead end, response shape surprised, coverage was missing,' but overall it is appropriately sized and scannable.

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 feedback submission tool, the description covers purpose, when to use it, what behavior to expect, and guidance on structuring feedback. The output schema exists, and the input schema fully documents parameters, so no critical information for correctly invoking the tool is missing.

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 the schema fully documents all six parameters and their constraints. The description reinforces the goal/expected/observed trio and mentions length caps, but this adds only marginal framing rather than genuinely new parameter meaning. Baseline 3 is appropriate given the complete schema coverage.

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 uses a specific verb and resource ('Report a problem back to the DexPaprika team') and clearly enumerates the situations that warrant submission. It is unmistakably distinct from the data-retrieval sibling tools, none of which handle user feedback.

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 description explicitly says 'Use whenever you hit a dead end, a response shape surprised you, or coverage was missing,' giving concrete trigger conditions. It also clarifies that partial feedback is acceptable and directs agents to provide goal, expected, and observed, which functions as usage guidance. No alternative feedback tool exists among siblings, so exclusion statements are unnecessary.

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