Read recorded boss behavior habits from the game knowledge base by boss name, or retrieve all entries when no name is provided, to inform autonomous combat decisions.
读取知识库里记录的 BOSS 行为习惯。
入参：boss_name 可选；不传返回全部记录，传了只返回名字匹配的记录。 返回：历史习性文本；无记录时返回「知识库还没有 BOSS 行为记录(文件不存在)。」 下一步：把习性用于决策，打完用 kb_append 补充新观察。
| Name | Required | Description | Default |
|---|---|---|---|
| boss_name | No |
| Name | Required | Description | Default |
|---|---|---|---|
| result | Yes |
Changes observed during successful MCP inspections.
v2.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that this is a read operation, details the optional parameter's effect, and specifies the return text including a no-record message. However, it omits permissions, safety profile, and whether it has any side effects beyond reading.
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 front-loaded with purpose, then cleanly organized into 入参, 返回, and 下一步 sections. Every sentence serves a distinct function with no redundancy.
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 one-parameter read tool with an output schema, the description covers purpose, parameter behavior, return format, edge case, and next-step guidance. It is nearly complete, missing only minor details like matching strictness (exact vs substring).
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%, so the description must compensate. It fully explains the single parameter: boss_name is optional, omitting it returns all records, and providing it filters by name match. This adds substantial meaning beyond the schema's bare type declaration.
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 (知识库里记录的 BOSS 行为习惯), clearly distinguishing it from general knowledge base tools by its focus on BOSS behavior records. It does not explicitly name sibling alternatives like kb_search, but the intent 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?
It implies usage context by saying '把习性用于决策' and directs to kb_append for writing new observations. However, it lacks explicit guidance on when to use this tool versus general query siblings such as kb_search or kb_list.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.