搜索历史会话

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description must explain what the tool does when called. The verb "搜索" implies a safe read, and the project-scope statement clarifies what it covers. However, the description never states whether results are ranked or capped, whether it is paginated, or how results are returned, and it doesn't mention any cost or latency traits.

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 purpose is stated first, followed by the clearly labeled 何时用 and 何时不调 blocks; there is no filler. The trigger lists are somewhat long, but each item is a distinct, usable signal, so nothing is wasted.

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 nine-parameter search tool with no output schema, the description explains invocation but not what comes back, so the agent can't anticipate result shape, snippet content, or ranking. Parameter documentation is left almost entirely to the schema; because coverage is high, that is acceptable, but the missing return-value guidance leaves a real gap.

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 89%, so the schema already documents nearly all nine parameters, including the tricky project fallback behavior; this establishes a baseline of 3. The description adds no parameter-level detail (query syntax, filter combination semantics) beyond what the schema says, but it doesn't need to.

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 gives a specific verb+resource ("搜索本项目的历史会话记忆") and scopes it to the current project up front. It doesn't explicitly contrast itself with the sibling tools list_sessions or get_decisions, so an agent reading only the description must infer whether a scope-based list or a decision lookup would be better.

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 description gives an explicit list of trigger conditions (the user says "之前/上次/为什么当时/我们讨论过吗", project onboarding, confirming a prior decision, and troubleshooting) and an explicit list of when not to call it (pure new questions, or content from the current conversation). This is exactly the when/when-not structure that makes tool selection unambiguous.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.