noyacg-mcp

佩戴 / 取消佩戴徽章

noy_set_badge

Idempotent

Safely toggles a badge's wearing status by validating its ID against the badge table, ensuring idempotent updates and preventing invalid entries.

Instructions

设置徽章佩戴状态。接口本身是开关式且不校验 ID（传垃圾值会写进 show 数组），所以本工具会先校验 ID 是否在徽章表里，再按当前状态决定是否需要切换，保证幂等。

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "badge_id": "<badge_id>"
    },
    "name": "noy_set_badge"
  }
}

Input Schema

Name	Required	Description	Default
`wear`	No	true = 佩戴，false = 取消佩戴
`badge_id`	Yes	徽章 ID，来自 noy_list_badges

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.1.0Oct 29, 2026

TDQS

A3.9/5.0

Behavior5/5

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

Goes well beyond the annotations: it discloses that the underlying API is a blind toggle that does not validate IDs and will persist garbage values into the show array, and that the tool pre-validates against the badge table and only switches when needed. That explains both the safety profile and the meaning of idempotentHint=true without contradicting any annotation.

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?

A single dense sentence that front-loads the purpose before the rationale. Every clause (toggle API, no ID validation, pre-validation, state check, idempotency) earns its place, though the parenthetical makes it slightly heavy.

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 2-parameter mutation with annotations present and no output schema, the description covers behavior and risk adequately. It does not say what happens on an invalid badge_id (error vs silent no-op) or what the call returns, which are the remaining gaps.

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% and both parameters already carry descriptions, including the wear boolean semantics and the source of badge_id. The prose adds no parameter-level detail beyond what the schema provides, so the baseline 3 applies.

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 concrete verb+resource (set badge wear/unwear state) and immediately qualifies the scope: an idempotent wrapper around a toggle API. It does not explicitly name a sibling to distinguish from (the schema instead points at noy_list_badges), so it falls just short of 5.

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?

Usage is implied rather than stated: the agent can infer this is the tool to wear/unwear a badge, and the description usefully notes it will check current state so the caller needn't. There is no explicit 'use when / don't use when' framing or named alternative.

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