Skip to main content
Glama
Sign In
noyacg-mcp

noyacg-mcp

by kwkare
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Hybrid

上传图片到图床

noy_upload_images

Uploads local images to the noymanga image host and returns post-ready image/<file> references; images are converted to WebP server-side.

Instructions

把本地图片传到 noymanga 的图床，返回发帖可用的 image/<file> 引用。图片一律被服务端转成 webp。这一步本身是写操作（占用图床空间），但不会在社区产生内容。发帖时再引用返回的 file 即可，无需重复上传。

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": {
      "paths": "<paths>"
    },
    "name": "noy_upload_images"
  }
}

Input Schema

NameRequiredDescriptionDefault
pathsYes本地图片绝对路径或相对当前工作目录的路径

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.2/5.0
Behavior4/5

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

Beyond the annotations, the description discloses key traits: the server always converts images to webp, the operation consumes image-host space, and it does not create community content. It doesn't cover re-upload/duplicate behavior (consistent with idempotentHint=false) or size/time limits, so it falls slightly short of a 5.

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?

Four short sentences, front-loaded with the action and return value, then the webp conversion and workflow note. Every sentence carries information the agent needs.

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 no output schema, the description compensates by explaining the return reference format and webp conversion, and it clarifies the write-but-not-published semantics. It omits what happens on partial failure across multiple paths, but is otherwise complete for a 1-param tool.

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%, so the single 'paths' parameter is fully documented in the schema, including its 1–9 item constraint. The description adds only indirect meaning by implying the images are persisted and converted to webp, so the baseline 3 applies.

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?

The description uses a specific verb and resource ('把本地图片传到 noymanga 的图床') and states the returned artifact ('image/<file>' 引用). It is clearly distinguished from content-creating siblings such as noy_create_post by noting it produces no community content.

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 usage context: upload first, and later reference the returned file in a post instead of re-uploading. This effectively routes the agent relative to noy_create_post. However, it does not state explicit when-not conditions or failure cases.

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

Deploy Server

Other Tools