Retrieve recent save receipts and verify Bilibili’s actual save status by action_id. This read-only check confirms watch-later or favorite saves without repeating write operations.
查询最近保存回执；传 action_id 可回读 B 站实际状态。不会重复执行写入。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | ||
| action_id | No |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so '不会重复执行写入' largely restates what structured data provides. What the description does add is the open-world detail that action_id triggers a re-read of the live Bilibili state rather than local cache, which is genuinely useful context not encoded in 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.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two short clauses, front-loaded with the listing behavior and then the action_id mode, plus one reassurance clause. No filler or repetition.
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 read-only two-parameter query with full annotation coverage and no output schema, the description covers both operational modes and the safety profile adequately. Minor gaps remain around receipt retention and whether action_id results still appear when the underlying save failed.
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 0%, but the description clarifies action_id's semantics — it looks up the actual remote status of a prior save action rather than just a local receipt — which the bare uuid pattern does not convey. The limit parameter (default 20, max 100) is still undocumented as to what it bounds (number of receipts), so the compensation is partial but meaningful.
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 names a specific action and resource: querying recent save receipts, with an optional action_id mode to re-read the actual Bilibili state. This clearly distinguishes it from the sibling write tool bilibili_save_videos, though it never explicitly names that sibling or state the relationship.
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 phrase '传 action_id 可回读' implies the two usage modes (list recent receipts vs. check one action's real status), and the closing clause '不会重复执行写入' hints it is the safe verification step after a save. But it never states explicitly when to prefer this over simply re-calling bilibili_save_videos or how soon after a save it should be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.