Skip to main content
Glama
noyacg-mcp

noyacg-mcp

by kwkare

设置头像 / 主页背景图

noy_set_profile_image
Destructive

Uploads a local image and sets it as your avatar or profile background, replacing the current image and returning the old URL for rollback.

Instructions

上传本地图片并设为头像或主页背景图(服务端会把新文件直接写进资料,没有单独的「保存」接口)。 ⚠️ 会覆盖当前头像/背景图,旧文件不会自动删除;工具会返回旧地址,方便你回滚。 头像与背景图走不同的图床端点(upload_avatar / upload_bg),限制比发帖图片更严(过大会报 size)。

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": {
      "kind": "<kind>",
      "path": "<path>"
    },
    "name": "noy_set_profile_image"
  }
}

Input Schema

NameRequiredDescriptionDefault
kindYesavatar = 头像,bg = 主页背景图
pathYes本地图片路径(jpg / png / webp / gif)
adultNo是否请求成人向内容(allow-adult 请求头)。不传则用环境变量 NOY_ALLOW_ADULT,默认 false。注意 /api/home 的服务端默认值是 true(不带就是 R18),本项目会显式传 false。

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.5/5.0
Behavior5/5

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

Annotations flag destructive=true and idempotent=false, and the description goes beyond that with what is destroyed (current avatar/bg is overwritten), that old files are not auto-deleted, that the old URL is returned for rollback, and that there is no separate save endpoint. This is exactly the extra context the annotations cannot convey, including stricter size limits.

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 with the core action, then the overwrite warning, then endpoint/size notes — a sensible priority order. It is dense and the long parenthetical in the first sentence slightly burdens reading, but no sentence is filler.

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 destructive, non-idempotent mutation with no output schema, the definition covers overwrite behavior, rollback data, and size-limit risk. It could be more complete by giving concrete size limits or describing the returned payload shape, but the essentials for a correct call are present.

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 real meaning: avatar vs bg route to different upload endpoints (upload_avatar / upload_bg) with different constraints, which the enum alone does not reveal. It says nothing about the `adult` parameter, leaving that to the schema.

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+resource: uploads a local file and sets it as avatar or home background. The parenthetical about the server writing the file directly into the profile distinguishes it from header-only edits, and the mention of 'upload_avatar / upload_bg' vs 发帖图片 separates it from sibling noy_upload_images.

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?

The description gives clear context for when to use it (setting avatar/bg) and implicitly steers away from noy_upload_images by noting these endpoints have stricter limits than post images. It does not explicitly say 'use noy_upload_images for post images instead,' so the alternative routing is only implied.

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