Set or view the current conversation focus to keep long chats on-topic. Push a topic to weight related content in future retrieval; omit topic to read the current focus stack.
焦点栈：查看或更新'现在在聊什么'。长对话里先压入当前话题，后续检索会自动给相关内容加权，避免跑题。不传 topic 就是查看。
| Name | Required | Description | Default |
|---|---|---|---|
| n | No | 渲染几条焦点，默认 3 | |
| topic | No | 当前话题（不传则只看不写） | |
| weight | No | 权重，默认 1.0 | |
| agent_id | No | default | |
| entities | No | 涉及的实体/关键词 |
Changes observed during successful MCP inspections.
v0.2.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the transparency burden and does a solid job: it discloses both read and write modes, that pushing a topic affects future retrieval weighting, and the 'avoid off-topic' purpose. It does not detail exact stack side effects such as overwrite versus accumulation, but the core behavioral traits are explicit.
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?
Three short sentences: purpose first, then the long-conversation usage context/effect, then the read-mode behavior. 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?
The description plus a well-annotated schema provide enough to invoke safely: when to call, read vs write mode, and what the call affects. Without annotations or an output schema, a little more detail about accumulated/updated focus state would make it fully complete, but the current definition is sufficient for typical calls.
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 80% and parameter descriptions already document n, topic, weight, and entities. The description adds complementary semantics by linking topic/weight/entities to the retrieval-weighting mechanism, which helps an agent understand why these parameters matter. agent_id remains undocumented in both schema and description, preventing 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?
Description states a specific action: '查看或更新"现在在聊什么"' on a '焦点栈', and explains its role as topic weighting for retrieval to avoid off-topic drift. This is clear and distinct from generic siblings, though it never explicitly names a sibling to contrast against.
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?
Clearly gives usage context: in long conversations, push the current topic before subsequent retrieval so related content gets weighted. It also defines the read-only call path ('不传 topic 就是查看'). It does not name alternatives or explicit exclusions, so it stops short of a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.