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

The description discloses behavioral traits beyond the annotations: it requires login (需要登录), it only returns the user's own words (not model suggestions or others' content), it reflects the user's self-description at that time (not completed results), old statements may not apply with recent corrections taking priority (noted in 'note'), and there is a quantity limit with limit only affecting query searches. These add valuable context beyond the readOnlyHint, openWorldHint, and idempotentHint annotations, and there is no contradiction.

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 structured with clear sections: 【需要登录】【何时用】, 【组合链】, 【口径/坑】. It front-loads the critical usage instruction ('check before asking'). Each sentence adds value, covering purpose, usage flow, and pitfalls. While it is longer than typical descriptions, it is appropriately sized for the tool's complexity and remains well-organized without 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?

The description is complete for an agent to call the tool correctly: it explains what is returned (user's own words), the two modes, the combination with other tools, and important caveats (scope, freshness, limit behavior). It does not explicitly describe the output format or pagination, but given that the output schema is absent and the tool is a simple search, this is sufficient. The description covers the essential context needed for effective use.

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?

The schema descriptions already cover both parameters (limit and query) with their purpose and behavior. The description adds significant meaning beyond the schema by explaining the two modes (empty query vs. non-empty query) and the default behavior, clarifying that limit only works when query is provided, and giving concrete query examples (e.g., budget, weekly time). This enhances understanding beyond the schema, though the schema already provides decent coverage.

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 states the tool retrieves the user's own words from various contexts (onboarding, business card, product creation, needs, cooperation goals, roadshow practice, growth mentor). It explicitly distinguishes two modes: empty query returns a bounded archive of long-term direction, hard constraints, and later corrections; non-empty query does topic-based full-text search. This differentiates it from sibling search tools like search_all, search_needs, etc., which search other content types.

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 explicit usage guidance: '在追问用户之前先查一次' (check before asking the user) and provides a combination chain: first call this tool with empty query to see constraints/corrections, then use get_my_growth_plan, create_need, or submit_signup to fill in with the user's own words. It also warns not to ask again what was already answered. This clearly states when to use and how to use it, including the default mode and query mode.

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