Skip to main content
Glama

send_feedback

Read-onlyIdempotent

Tell Samplecut's developers how the user's task went. Call it once after you finish or give up on a task where you used these tools, with task_completed set to whether the user got what they wanted. Use feedback_type "missing_capability" when the goal needed something these tools do not do (for example naming a song or separating vocals), even if you finished it another way; "issue" when a tool failed, or its result was wrong or confusing; "praise" when it went well. This only records feedback. No links, names or personal details.

Input Schema

NameRequiredDescriptionDefault
detailsNoOptional longer context: what you tried, exact parameter values, the error text you saw, and any workaround you used. Omit when the summary says it all.
summaryYesOne self-contained sentence. For 'missing_capability': the capability you needed, e.g. 'No tool to delete multiple cohorts in one call.' For 'issue': the tool and the problem, e.g. 'query-trends rejects relative date ranges with an unclear error.'
llm_modelYesThe exact model identifier you (the assistant) are running as, taken from your system prompt or environment (e.g. "claude-opus-4-8", "gpt-5.2"). Used for analytics only. If you do not know your model identifier with certainty, pass "unknown" — never guess.
sentimentNoOptional: how the experience felt overall.
tool_nameNoOptional: the existing tool this feedback is about (for 'issue' or 'praise'). Leave empty for 'missing_capability' - the point is that no tool fits.
feedback_typeYesWhat kind of feedback this is. Use 'missing_capability' when the tool you needed does not exist in the tool list - nothing failed, the capability is absent (this is the most valuable report; send it even if you found a workaround). Use 'issue' when an existing tool behaved badly: it failed, returned a confusing error, or its description or schema misled you. Use 'praise' when something worked notably well. Use 'other' for anything else.
task_completedNoOptional: whether you still completed the user's task despite the problem.
conversation_idNoPass the exact conversation_id from the server's previous response, unchanged. The server provides it on the first call — never invent one, and do not issue parallel tool calls until you have it. Keep passing the same conversation_id for the rest of the conversation, including after later user messages or on a different task; do not reset it when the user starts a new request.
friction_pointsNoOptional: the specific moments that slowed you down, as short bullet-like sentences, quoting exact tool names, parameters, or error text.
suggested_improvementNoOptional: the concrete change that would have helped, e.g. the tool to add, the description to reword, or the error message to improve.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior4/5

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

Annotations already declare readOnly, openWorld, idempotent, and non-destructive behavior, so the bar is lower. The description adds useful constraints beyond annotations: it only records feedback, should be called once, and must avoid links, names, and personal details.

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?

The description is front-loaded and compact: purpose, call timing, feedback-type guidance, and privacy constraint each appear in a clear sentence. No sentence is wasted.

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?

With 10 parameters, rich schema descriptions, strong annotations, and no output schema, the description supplies what an agent needs: when to call, how to choose feedback_type, and what not to include. Nothing essential 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. The description still adds value by giving examples for missing_capability and clarifying task_completed as whether the user got what they wanted, plus a privacy constraint that affects summary/details content.

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 states a specific verb and resource: telling Samplecut's developers how the user's task went. It also frames this as feedback tied to tasks where these tools were used, which clearly distinguishes it from the audio-operation siblings.

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?

It gives explicit timing ('once after you finish or give up on a task') and concrete routing rules for feedback_type, including when to use missing_capability even if a workaround was found. The alternatives are well defined.

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