Skip to main content
Glama

Rate the agent

rate_agent_result
Idempotent

Record what a person thought of something the agent produced — a reply, an export, a report, an email. Send it as soon as they press the thumb: the reason and their words are optional and may follow in a second call, which replaces the first. Pick reason_code from get_feedback_reasons; an unknown code is dropped and the rating is still saved (reason_dropped: true). For target_kind: "report" the target_ref is the view_key, NOT the report_key — one report is read by many country pages and only the view_key tells them apart. target_ref is verified against your own message log: the answer carries ref_check saying whether it matched (verified), did not (mismatch), could not be checked (unchecked) or was never sent (absent). A rating is never dropped because the check failed.

Input Schema

NameRequiredDescriptionDefault
modelNoWhich model produced the rated answer.
probeNoTrue when the call comes from a test run rather than a person. 🔴 Derive it from the process you run in — do not set it by hand: a flag someone has to remember is a flag someone forgets. The rating is still STORED; it is hidden behind a switch on the triage screen, because dropping it on arrival would lose what later needs explaining. Omit the field when you cannot tell — absent means "not stated", never "a person".
topicNoWhat the exchange was about, one short phrase.
signalNothumb (default) for a pressed thumb; undone when they cancelled the result; rephrased or left for the quiet signals. The weight is set by the platform, not by you.
commentNoTheir own words. Optional. Trimmed at 2000 characters.
surfaceYesWhere it happened, e.g. widget.
verdictYesThe thumb the person pressed. Send "retracted" (or an empty string) when they pressed the same thumb again and took the rating back — it then stops counting and leaves the triage queue. Retracting needs the same target_ref as the rating it undoes.
target_refNoYour identifier of the rated work: the message id for an answer, the view_key for a report. Omit it only when the kind has none.
reason_codeNoA code from get_feedback_reasons.
target_kindYesWhat was rated: answer | export | report | email | any future kind.
knowledge_idsNoIds of the platform rules that were in the prompt for this answer, up to 50. This is how a harmful rule gets noticed from a single complaint.
reason_shown_langNoLanguage the person actually SAW the reason card in — send it together with `reason_code`, never alone. It exists so that "they picked this reason" can be told apart from "they tapped something they could not read": when the card had not been translated yet, the language differs from the visitor locale. Omit the field entirely rather than sending an empty string — absent means "not stated", which is a different answer from "in their own language".

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A4.7/5.0
Behavior5/5

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

Adds substantial behaviour beyond the annotations: unknown reason codes are dropped but the rating is still saved (reason_dropped: true), a later call replaces an earlier one, and target_ref is verified with ref_check values (verified/mismatch/unchecked/absent) while never causing the rating to be discarded. These are exactly the edge cases an agent needs and are not derivable from readOnlyHint/openWorldHint/idempotentHint.

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?

Front-loaded with the core action, then each subsequent sentence delivers a distinct operational fact (replacement semantics, unknown-code handling, report/view_key gotcha, ref_check outcomes). No sentence merely restates the tool name or the title.

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 12-parameter, no-output-schema mutation tool, the description supplies the return-field semantics (reason_dropped, ref_check) and the failure-mode guarantees that would otherwise be missing. Combined with the rich schema descriptions, an agent has everything needed to call it correctly and interpret the result.

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, but the description adds cross-parameter rules the schema cannot express: target_ref for a report is the view_key and NOT the report_key because one report is read across many country pages, and reason_code must come from get_feedback_reasons. It doesn't touch several other parameters (signal, knowledge_ids, probe), so not 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 and resource ("Record what a person thought of something the agent produced") and enumerates what can be rated: reply, export, report, email. This lets an agent distinguish it from siblings like add_feedback_message or create_feedback_ticket without opening any schema.

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?

Gives clear timing guidance ("Send it as soon as they press the thumb") and explains that reason/comment may follow in a second call that replaces the first, plus points to get_feedback_reasons for codes. It stops short of naming exclusions or the sibling that handles a different case (e.g., add_feedback_message), so it lacks the when-not half 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