Set a knowledge base Markdown file as the active tactic for the FlorrVLM-Agent, enabling subsequent decisions to read it directly without re-searching.
指定知识库里的一份 Markdown 文件作为「当前战术」。
用途：让后续决策直接读取这份战术，不用每次重新检索。 入参：tactic_file，知识库中的文档名。 返回：「已切换当前战术为: <文件名>」；文件名非法或文档不存在时返回对应错误文本。 下一步：配合 kb_search / kb_append 迭代这份战术。
| Name | Required | Description | Default |
|---|---|---|---|
| tactic_file | Yes |
| 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 does disclose the success message and the error condition (invalid filename or non-existent document returns error text), which is useful. However it omits whether the setting persists across sessions, its scope, or idempotency, so a mutation-style state change is only partially characterized.
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 broken into labeled sections (用途/入参/返回/下一步) and is front-loaded with the core action. Every sentence carries distinct information 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?
An output schema exists, yet the description still summarizes the return and error text, which is helpful. Combined with parameter meaning and follow-on guidance, it is nearly complete, though persistence/scope behavior of the 'current tactic' state remains unstated.
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 0% (the schema only names 'tactic_file: string'), so the description must compensate, and it does: it explains the parameter is a document name within the knowledge base. It still does not give format constraints or examples for a valid file name, keeping it from a 5.
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: '指定知识库里的一份 Markdown 文件作为「当前战术」' (set a Markdown file as the current tactic), and distinguishes the intent from mere retrieval. It does not disambiguate against the potentially confusing sibling switch_set, which keeps 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?
It explains the point of the operation ('让后续决策直接读取这份战术，不用每次重新检索') and names follow-on tools ('配合 kb_search / kb_append 迭代这份战术'). It gives clear context for when to reach for it but offers no explicit when-not or alternative-selection rule.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.