Retrieve a reader's borrowing history by providing their certificate ID. Requires admin authentication token to access borrowing records, with option to include personally identifiable information.
读者借阅历史（需 admin 认证令牌）。
| Name | Required | Description | Default |
|---|---|---|---|
| token | No | ||
| cert_id | Yes | 读者证件号 CERT_ID | |
| include_pii | No | 是否返回实名（默认脱敏/隐藏） |
| Name | Required | Description | Default |
|---|---|---|---|
No arguments | |||
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description bears full responsibility. It states 'requires admin authentication token' but does not disclose whether the tool is read-only, what data it returns (history, pagination, etc.), or any potential side effects. This is insufficient for safe agent invocation.
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 a single, front-loaded sentence. It conveys purpose and the critical admin requirement without wasted words. However, it is extremely brief, bordering on under specification, which reduces the score from 5.
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?
Despite having 3 parameters, an output schema, and no annotations, the description only covers purpose and auth. It omits usage context, parameter guidance, and behavioral traits like read-only nature. For a tool with moderate complexity, this is incomplete.
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 coverage is 67% (2 of 3 parameters have descriptions in the schema). The description adds no parameter information, such as explaining what cert_id represents or when include_pii should be true. Given moderate coverage, the description should at least echo parameter roles, which it fails to do.
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 '读者借阅历史' clearly identifies the tool as retrieving a reader's borrowing history. It includes the admin authentication requirement, adding specificity. However, it does not explicitly distinguish from sibling get_reader_borrowing, which likely handles current borrows. The Chinese-only phrasing may limit understanding for non-Chinese agents, but the purpose is unambiguous.
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?
No guidance on when to use this versus siblings like get_reader_borrowing or get_reader_fines. The only usage hint is the admin auth requirement, which is a prerequisite, not a selection criterion. An agent would need to infer from the name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.