JMComic AI

Overview Schema Source Related Servers Discussions Admin

daily_checkin

Perform daily check-in for a logged-in JMComic account and return whether today’s check-in succeeded or was already completed, without error on repeat attempts.

Instructions

执行已登录账户的每日签到打卡，需要有效的登录会话、顶层 auth 账号配置或 Cookie。今日已签到时不会报错，而是返回 status="already_checked_in"。

参数: user_id: 可选的用户数字 ID。API 客户端在仅配置 Cookie（未执行密码登录）时需提供；通过 login 工具或顶层 auth 账号密码自动登录后可省略，HTML 客户端无需此参数。

返回: status: "checked_in"（签到成功）、"already_checked_in"（今日已签）或 "error"。 already_checked_in: 今日是否已完成签到（布尔值）。 code: 上游签到码（0=签到成功，1=重复签到，-1=执行失败）。 message: 服务端奖励信息、重复签到提示或错误说明。

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": "daily_checkin"
  }
}

Input Schema

Name	Required	Description	Default
`user_id`	No

Output Schema

Name	Required	Description	Default
No arguments

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.1.10Nov 7, 2026

TDQS

A4.4/5.0

Behavior4/5

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

With no annotations at all, the description carries the full burden and does well: it discloses the auth requirements, and critically that a repeat check-in does not raise an error but returns status="already_checked_in", plus the upstream result codes. It omits rate-limit/throttling behavior and whether the call has any side effects beyond the counter, which is the remaining gap.

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-loads the action in the first sentence, then uses clean 参数/返回 sections. The 返回 block largely restates the output schema, which is redundant given has_output_schema=true, but overall there is little wasted text.

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?

An agent has everything needed to decide whether to call it, what to pass for user_id, and how to interpret success versus already-checked-in. Output schema exists, so the extra return documentation is a bonus rather than a necessity.

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 0%, so the description must compensate, and it does: user_id is described as optional, with the exact condition under which it is required (Cookie-only API client) versus omittable (after login tool / top-level auth) and irrelevant (HTML client). Minor flaw: it calls user_id a numeric ID while the schema types it as a string, which could induce a type mismatch.

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 and resource — perform the daily check-in for the currently logged-in account — which is unambiguous and clearly separable from every sibling (login, download_*, browse_*). No sibling overlaps with a check-in operation, so differentiation is inherent.

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?

Gives concrete preconditions (valid session, top-level auth account config, or Cookie) and explicitly points to the login tool as the path that makes user_id unnecessary. It does not state any when-not-to-use condition, e.g. what to do if unauthenticated, which keeps it short of a 5.

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