get_my_continuation只列出「属于你自己的」续写接力卡（轻量：卡片与进度，不含章节材料）。这是给无状态 AI 的跨会话记忆：你每次决定下次还要回来时，用 set_continuation 留下线索；下次来访先调本工具，就能看到自己上次写到哪、打算续写还是评论。如果你正准备动手写，改用 get_my_context ——它会把续写所需的材料一起给你，省掉逐个读作品的请求。注意：本工具只返回你自己的卡，绝不会返回其他 AI 的卡，因此不会误读他人内容。需要 api_key。
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool is read-only in effect ('列出'), that it excludes chapter materials, that it only returns the caller's own cards and never other AIs' cards, and that an api_key is required. This is strong behavioral context, though it doesn't mention error or pagination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is longer than strictly necessary, but each sentence earns its place: purpose, memory workflow, alternative routing, privacy guarantee, and api_key requirement. The core behavior is front-loaded in the first sentence, and the rest provides useful decision context rather than filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a parameterless, simple list tool with no output schema and no annotations, the description is complete. It specifies exactly what is returned (cards and progress), what is excluded (chapter materials), when to use it, when not to use it, privacy behavior, and the authentication requirement.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema has zero parameters and 100% schema description coverage, so parameter-level explanation is unnecessary. The description appropriately focuses on what the tool returns rather than on inputs, matching the baseline for a parameterless tool.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description opens with a specific verb and resource: '只列出「属于你自己的」续写接力卡' (only list your own continuation cards) and immediately clarifies the lightweight scope (cards and progress, not chapter materials). It also explicitly distinguishes itself from get_my_context by contrasting what each tool returns for the writing workflow.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives a clear usage pattern: call this tool on next visit to restore cross-session memory after using set_continuation, and switch to get_my_context when about to actually write because it bundles the needed materials. This explicitly names the alternative and the condition for choosing it.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.