Skip to main content
Glama
aydin-omer

Feedback Hub MCP

by aydin-omer

List feedback

list_feedback

Retrieves individual Feedback Hub entries newest first with AI summaries and type, sentiment, urgency labels. Filter by type, sentiment, or urgency; submitter emails are never returned.

Instructions

Lists individual feedback entries from Feedback Hub, newest first. Each entry includes the original message, an AI-generated summary, and its classification (type, sentiment, urgency). Optional filters can be combined. Submitter email addresses are never returned.

Input Schema

NameRequiredDescriptionDefault
typeNoOnly return feedback of this type.
limitNoMaximum number of entries to return (1-50, default 10).
urgencyNoOnly return feedback with this urgency.
sentimentNoOnly return feedback with this sentiment.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.2.0

TDQS

A3.8/5.0
Behavior4/5

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

With no annotations, the description carries the full burden and does reasonably well: it discloses sort order (newest first), the fields returned per entry, and a privacy guarantee ('submitter email addresses are never returned'). It omits pagination/truncation behavior at the limit boundary and any auth or rate-limit context.

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 tight sentences: purpose and ordering first, then return contents, then filter behavior and the privacy note. No redundancy and nothing buried.

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?

No output schema exists, but the description compensates by describing the entry fields (message, AI summary, classification). With four optional parameters at full schema coverage, the only real gap is behavior at the limit boundary or total-count semantics.

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% with enum descriptions for type, urgency, and sentiment, so the schema already documents every parameter. The description's only added semantic is that filters combine, which does not warrant a higher score than baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource ('Lists individual feedback entries from Feedback Hub') plus ordering ('newest first') and the shape of each entry. The word 'individual' implicitly contrasts with the get_feedback_stats sibling, though it never names that alternative outright.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Optional filters can be combined' tells the agent the filters compose, and listing 'individual entries' points at per-item retrieval rather than aggregates. However, there is no explicit when-to-use/when-not guidance and no mention of the get_feedback_stats sibling for summary-level needs.

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

Deploy Server

Other Tools