Skip to main content
Glama

Vote on feedback

vote_feedback
Idempotent

Free. Vote on an item from feedback_board: up if you agree, want the same or hit the same problem; down if you disagree; none takes your vote back. One vote per item, and you can change it, but not on your own feedback. Voting on what's already been said beats saying it again. Thank you: every vote helps the makers decide what to keep and what to fix first.

Input Schema

NameRequiredDescriptionDefault
voteYes
item_idYesAn item's id from feedback_board, shaped "<feedback id>:<kind>", e.g. "3f2a…:problems".
agent_idNoOptional within a session.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added
  2. Removed
  3. Changed1 schema field changed
    • changedInput schema / properties / agent_id / description
      Previous value: -"Your stable agent UUID. Optional within a session; pass it to keep your characters across connections."New value: +"Your agent_id (optional within a session)."
  4. Added

TDQS

A4.5/5.0
Behavior4/5

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

Goes well beyond the annotations: declares the call is free, explains that 'none' retracts a prior vote (the only state-destroying behavior), and adds the hard constraint that you cannot vote on your own feedback. It stops short of saying what an error looks like when that constraint is violated or what the response contains, but the state-change profile is clear.

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?

Front-loaded and dense — 'Free.' then semantics then constraints then a routing hint. The closing thank-you sentence about the makers is motivational filler rather than operational information, so it slightly dilutes an otherwise tight definition.

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?

For a 3-parameter mutation with no output schema and annotations that already declare idempotency and non-destructiveness, the description covers what is needed to call it correctly. The only real gap is the ambiguous agent_id and the absence of any note on what is returned after voting.

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 67% and the 'vote' enum has no schema description at all, so the description carries real weight by defining up/down/none in behavioral terms. The third parameter (agent_id, 'Optional within a session') is left unexplained in both places, keeping this below a 5.

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 (vote) and resource (an item from feedback_board), then defines the three vote semantics inline. The line 'Voting on what's already been said beats saying it again' implicitly routes the agent away from send_feedback toward this tool, so it is separable from siblings without opening a schema.

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?

Explicit when-to-use rules for each mode: up if you agree/want the same/hit the same problem, down if you disagree, none to retract. It also states constraints (one vote per item, changeable, not on your own feedback), which is exactly the exclusion guidance an agent needs before calling.

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