Skip to main content
Glama
noyacg-mcp

noyacg-mcp

by kwkare

登出(清除登录态)

noy_logout
DestructiveIdempotent

Clears the locally saved login session and invalidates the current process so all tools require re-login; set revoke=true to also revoke the server-side session.

Instructions

清除本地保存的登录态(~/.noyacg-mcp/session.json)并让当前进程立即失效,之后所有工具会要求重新登录。 默认只清本地:服务端的会话仍然有效(其它设备不受影响,同一个 cookie 复制走还能用)。 revoke=true 会额外调用 /api/logout 吊销服务端会话——这是不可逆的,之后必须重新登录。 注意:如果登录态来自环境变量 NOY_SESSION,本工具清不掉它,需要用户自己改 MCP 配置。

Tool call template

This tool declares no required parameters. Add optional parameters from the input schema as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {},
    "name": "noy_logout"
  }
}

Input Schema

NameRequiredDescriptionDefault
revokeNo是否同时吊销服务端会话(不可逆,会影响其它设备上的同一 cookie)

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

TDQS

A4.9/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=true, but the description adds crucial context beyond them: what exactly is deleted, that the server session survives and a copied cookie still works, that revocation is irreversible and requires re-login, and the env-var escape hatch. This is well above the bar set by the annotations.

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?

Four sentences, front-loaded with the default behavior before the opt-in destructive mode. Each sentence earns its place, though the parenthetical path and endpoint notation make it dense; minor trimming possible without loss.

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 single-boolean tool with no output schema, the description covers side effects, irreversibility, cross-device impact, and the environment-variable limitation. Nothing an agent needs to decide whether to call it or how to set `revoke` is missing.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters5/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The single `revoke` param is schema-documented (100% coverage), but the description adds real meaning: revoke=false is the default with a specific non-obvious consequence (server session stays valid, cookie copyable), and revoke=true hits a named endpoint. This goes beyond the schema's brief note.

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: it clears the locally saved login state at `~/.noyacg-mcp/session.json` and invalidates the current process. It also distinguishes itself from a server-side logout by naming the default (local-only) behavior up front, so an agent can tell exactly what this tool does.

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

Usage Guidelines5/5

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

Explicitly routes the two modes: default clears only local state (other devices unaffected), while revoke=true additionally calls `/api/logout` and is irreversible. It also gives a clear condition where the tool cannot help (NOY_SESSION from env), telling the user to edit MCP config instead.

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