Skip to main content
Glama
haoan33

OmniQQ-MCP

by haoan33

get_group_honor_info

Fetch QQ group honor titles such as Dragon King and Group Chat Fire to recognize active members and boost engagement.

Instructions

获取指定 QQ 群的群荣誉信息 (龙王、群聊之火、快乐源泉等) (OneBot 11: get_group_honor_info)。 :param group_id: 群号 :param honor_type: 荣誉类型: 'talkative'(龙王), 'performer'(群聊之火), 'legend'(群聊炽焰), 'strong_newbie'(冒尖小春笋), 'emotion'(快乐源泉), 或 'all'(全部)

Input Schema

NameRequiredDescriptionDefault
group_idYes群号
honor_typeNo荣誉类型: 'talkative'(龙王), 'performer'(群聊之火), 'legend'(群聊炽焰), 'strong_newbie'(冒尖小春笋), 'emotion'(快乐源泉), 或 'all'(全部)all

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv1.1.0
    • addedInput schema / additionalProperties
      Added value: +false
  2. First observedv1.0.0

TDQS

C2.9/5.0
Behavior2/5

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

No annotations are provided, so the description carries the entire behavioral burden. The verb '获取' weakly implies a read-only query, but there is no explicit statement about permissions, whether a bot must be a group member, rate limits, or what the response contains. The enumeration of honor types is behavioral-adjacent, but permissions/side-effect context is absent.

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?

Two short sentences, purpose front-loaded, no filler. Mild redundancy in restating the schema's honor_type enumeration, but nothing that wastes the agent's attention.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema, so the description ideally would hint at the return shape (ranking lists per honor type) and any access requirements. Both parameters and the honor-type taxonomy are fully covered, making it minimally adequate for a simple read tool, but return/permission context is missing.

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% and the description's param notes are a near-verbatim copy of the schema text for both group_id and honor_type (including the same enumerated values). Per the coverage rule this is the baseline 3 – no added meaning beyond the schema.

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 ('获取指定 QQ 群的群荣誉信息' – get honor info for a given QQ group) and identifies the underlying OneBot 11 action. It is unambiguous, though it never references any sibling tool, so the differentiation is left implicit (no sibling covers group honors anyway).

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

Usage Guidelines2/5

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

Only implies usage by naming the resource; there is no statement of when to call this versus related tools such as get_group_info or get_group_member_info, nor any prerequisites (e.g. bot must be in the group). Pure 'what', no 'when'.

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