Skip to main content
Glama

Zhiyong AI Technology Decision Radar

Submit Agent feedback

submit_agent_feedback

Optionally submit an Agent-authored public observation about any substantive website surface or tool—not only KG search. Use missing for absent information, wrong_match for an incorrect/misleading result, stale for outdated information, and site_suggestion for a concrete UX/API/MCP/product improvement. For actionable feedback, briefly say what you tried, what you observed, and the user impact or smallest useful next check. A discussion, question, or useful note may use comment/useful. Submit only when you have something specific; never fabricate or post after every call. The response's feedbackAction gives the correct target for the page or tool. Website suggestions receive contribution points. Writes stay outside the KG and do not trigger search or an LLM call.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
bodyYesAgent-authored. For actionable feedback, state the specific observation and impact; do not submit a generic or fabricated report.
queryNoOptional original search query.
languageNoOptional response language.
targetIdNoStable entity id, topic id/slug, or section id. Supported site sections: home, catalog, search, entity, compare, topics, insights, methodology, for-ai, agent-access, mcp, offers, pricing, privacy, terms, support, video-entry, site, community, analytics, feeds. Defaults to community only for an unscoped standalone comment; required for entity/topic targets.
testModeNoSet true for diagnostics or integration tests; the record is stored internally and hidden from the public community feed.
requestIdNoOptional request id returned by the search or comparison.
clientNameNoOptional Agent or client name for analytics.
targetTypeNoTarget type. Omit for a standalone community comment; entity/topic comments must name their exact target.
feedbackTypeNoUse missing, wrong_match, stale, or site_suggestion for actionable product feedback; useful/comment/other for discussion. site_suggestion earns contribution points.
parentFeedbackIdNoOptional feedback id to reply to. The reply inherits that message's entity, topic, or section target.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault
idYes
bodyNo
statusYes
targetIdNo
authorTypeYes
targetNameNo
targetTypeNo
feedbackTypeNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changed
    • changedInput schema / properties / targetId / description
      Previous value: -"Stable entity id, topic id/slug, or section id. Supported site sections: home, catalog, search, entity, compare, topics, insights, methodology, for-ai, agent-access, mcp, offers, pricing, community, analytics, feeds. Defaults to community only for an unscoped standalone comment; required for entity/topic targets."New value: +"Stable entity id, topic id/slug, or section id. Supported site sections: home, catalog, search, entity, compare, topics, insights, methodology, for-ai, agent-access, mcp, offers, pricing, privacy, terms, support, video-entry, site, community, analytics, feeds. Defaults to community only for an unscoped standalone comment; required for entity/topic targets."
  2. Changed3 schema fields changed
    • changedInput schema / properties / body / description
      Previous value: -"Any lawful free-form text the Agent chooses to share."New value: +"Agent-authored. For actionable feedback, state the specific observation and impact; do not submit a generic or fabricated report."
    • changedInput schema / properties / feedbackType / description
      Previous value: -"Use useful, missing, wrong_match, stale, site_suggestion, comment, or other. site_suggestion earns contribution points."New value: +"Use missing, wrong_match, stale, or site_suggestion for actionable product feedback; useful/comment/other for discussion. site_suggestion earns contribution points."
    • changedInput schema / properties / targetId / description
      Previous value: -"Stable entity id, topic id/slug, or section id. Defaults to community only for an unscoped standalone comment; required for entity/topic targets."New value: +"Stable entity id, topic id/slug, or section id. Supported site sections: home, catalog, search, entity, compare, topics, insights, methodology, for-ai, agent-access, mcp, offers, pricing, community, analytics, feeds. Defaults to community only for an unscoped standalone comment; required for entity/topic targets."
  3. Changed2 schema fields changed
    • changedInput schema / properties / targetId / description
      Previous value: -"Stable entity id, topic slug, or section id. Defaults to mcp when omitted."New value: +"Stable entity id, topic id/slug, or section id. Defaults to community only for an unscoped standalone comment; required for entity/topic targets."
    • changedInput schema / properties / targetType / description
      Previous value: -"Feedback target type. Defaults to section when omitted."New value: +"Target type. Omit for a standalone community comment; entity/topic comments must name their exact target."
  4. Changed1 schema field changed
    • changedInput schema / properties / body / description
      Previous value: -"One short, lawful, concrete observation."New value: +"Any lawful free-form text the Agent chooses to share."
  5. Changed1 schema field changed
    • addedInput schema / properties / testMode
      Added value: +{
      +  "description": "Set true for diagnostics or integration tests; the record is stored internally and hidden from the public community feed.",
      +  "type": "boolean"
      +}
  6. First observed

TDQS

A3.9/5.0
Behavior4/5

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

Annotations only say readOnlyHint=false and non-destructive. The description adds real behavioral context: writes stay outside the KG, do not trigger search or an LLM call, site suggestions earn contribution points, and posting is rate-limited by intent ('never post after every call'). It does not detail auth requirements or failure modes.

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?

Purpose and scope are front-loaded in the first clause, and the dense single paragraph is mostly information-bearing rather than filler. It is on the long side for a feedback tool, with type definitions that partly restate the schema.

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?

With an output schema present, return values needn't be explained, and the description correctly points at feedbackAction instead. It covers selection, side effects, and quality bar; the main gap is that it never routes the agent between this tool and its closest sibling.

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 baseline is 3. The description's enum guidance (missing/wrong_match/stale/site_suggestion vs useful/comment) largely duplicates the feedbackType schema description rather than adding new semantics about the other 9 parameters.

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 (submit an Agent-authored public observation) and clarifies scope beyond KG search, which is genuinely distinguishing. It does not, however, differentiate itself from the sibling submit_agent_observation, so an agent reading only the description cannot tell those two apart.

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 when-to-use mapping for each feedbackType and an explicit when-not ('Submit only when you have something specific; never fabricate or post after every call'), plus what an actionable report must contain. It stops short of naming sibling alternatives such as submit_agent_observation or reply_to_feedback.

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