set_tomato_cookiesImport browser cookies as JSON text or file path to authenticate automated publishing on Fanqie Novel. Enables login and scheduled chapter uploads.
手动导入 cookies 文本或文件路径。cookies 需为数组或 {cookies:[...]} 格式（浏览器插件导出格式均可）。
| Name | Required | Description | Default |
|---|---|---|---|
| cookies | No | cookies 的 JSON 文本 | |
| file_path | No | cookies JSON 文件路径（与 cookies 二选一） |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the accepted input formats but says nothing about side effects such as whether imported cookies overwrite existing ones, whether authentication is required first, or how the operation affects session state. For a write-style cookie import tool, that is a significant gap.
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 two concise sentences with no redundant or filler content. The core action is front-loaded, and the format requirement follows immediately, making it easy to scan and act on.
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 simple two-parameter tool with no output schema and no annotations, the description covers input format and source adequately. It does not explain when to prefer this over login_tomato or what happens after import, leaving behavioral context incomplete. An agent can invoke it, but with some uncertainty about side effects.
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?
Schema description coverage is 100%, so the baseline is 3. The description adds value beyond the schema by explaining that cookies may be either a JSON array or a {cookies:[...]} object, and that browser-plugin exports are acceptable. It also reinforces the text-or-file-path choice, which is useful for constructing the call correctly.
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 states a specific verb and resource: manually importing cookies from text or a file path. It also clarifies the expected format, so the agent knows exactly what the tool does. However, it does not explicitly name a sibling (e.g., login_tomato) to differentiate this tool from alternatives, keeping it short of a 5.
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 word '手动' (manually) implies this is an alternative to automatic login, but the description never states when to use this instead of login_tomato or other sibling tools. There is no explicit condition or exclusion. Usage is only implied through the manual/backup framing.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.