Skip to main content
Glama
noyacg-mcp

noyacg-mcp

by kwkare

发帖(社区)

noy_create_post

Publish a community post with optional images, text, emoji codes, and book references. Note that posts cannot be deleted and expire after 90 days.

Instructions

在社区发一条帖子,可选带图。⚠️ 不可撤销:站点没有删帖接口,帖子 90 天后自动过期,但期间无法删除;⚠️ 图片是否打码由服务端判定(spoiler),客户端无法指定;发帖不返回帖子 ID,本工具会去列表里回查。正文支持表情包代码(如 [noygirl:yeah])与 NID<书籍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": {
      "title": "<title>",
      "content": "<content>"
    },
    "name": "noy_create_post"
  }
}

Input Schema

NameRequiredDescriptionDefault
adultNo是否请求成人向内容(allow-adult 请求头)。不传则用环境变量 NOY_ALLOW_ADULT,默认 false。注意 /api/home 的服务端默认值是 true(不带就是 R18),本项目会显式传 false。
titleYes标题
imagesNo图片:本地路径(会先自动上传)或已上传的文件名 / `image/<file>` 引用
contentYes正文,纯文本 + 表情包代码
platformNo客户端标识web

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.1/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 post can never be deleted and only auto-expires after 90 days, that the server (not the client) decides spoiler masking, and that the tool re-queries the list to recover the created post's ID. These are exactly the side effects and quirks an agent cannot infer from readOnlyHint=false / idempotentHint=false alone.

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 purpose, then two ⚠️ warnings, then a body syntax note — a sensible priority order. Dense but nearly every clause carries information; the double warning glyphs are slightly noisy but justified by the irreversible-write risk.

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

Completeness5/5

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

For a 5-parameter mutation with no output schema, the description covers the things an agent would otherwise get wrong: no return ID, irreversible creation, server-decided spoiler, accepted inline markup, and auto-upload of local image paths. Nothing essential to a correct first invocation appears to be missing.

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 the schema lacks: content supports emoji-pack codes like `[noygirl:yeah]` and `NID<书籍ID>` book references, and images may be local paths that get auto-uploaded. It does not touch `adult` or `platform`, which are already documented in 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?

The opening clause '在社区发一条帖子,可选带图' names a concrete verb (发帖) and resource (community post) and flags the optional image dimension. It is clearly distinct from siblings like noy_edit_post / noy_comment by being a creation call, though it never explicitly names those siblings as alternatives, so it stops short of the 5 bar.

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?

When-to-use is only implied by the verb; the description never says 'use noy_edit_post to fix a post' or 'use noy_upload_images first to pre-stage images'. What it does provide are hard constraints (irreversibility, spoiler decided server-side, no post ID returned), which is useful but is guidance about consequences, not about tool selection.

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