Retrieve your past debugging cards by entering a symptom or keyword, such as '500 no logs' or 'index failure'. Get the most relevant experiences to guide your current troubleshooting with proven solutions.
在开始排查任何问题之前调用：检索用户的历史排错卡，把相关旧卡作为上下文注入。 传入当前问题的症状描述或关键词（如 "500 无日志"、"跨域"、"索引失效"），返回最相关的卡片。 若命中相关卡片，回答时应优先参考用户自己的历史经验路径。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回条数上限，默认 5 | |
| query | Yes | 问题/症状描述或关键词 |
Changes observed during successful MCP inspections.
v0.1.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
In the absence of annotations, the description explains the retrieval behavior: it takes symptoms/keywords, returns relevant cards, and instructs using them as context. However, it does not disclose edge behaviors such as no-result handling, whether the operation is read-only, or any rate limits or permission requirements.
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 three sentences and opens with the key instruction on when to call. It is well-structured and economical, though the examples in the second sentence partly duplicate the schema's query description.
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 2-parameter tool with no output schema, the description covers what to pass, what to expect back, and how to use the result in answer generation. It is missing an explicit statement on what to do when there are no matching cards, but overall it is sufficient for correct invocation.
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 already describes both parameters at 100% coverage, giving the baseline of 3. The description adds example keywords for the query, but no additional semantic detail for the limit parameter or any supplemental explanation beyond the schema.
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 historical troubleshooting cards and returns the most relevant ones for context, which is a specific verb+resource pairing. It is distinct from siblings like save_card, delete_card, and claim_card because it focuses on search/retrieval of existing history.
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 explicitly says to call before troubleshooting any issue and to pass symptoms or keywords, which is a strong usage trigger. It also says to favor the returned historical context in answers, but it does not name alternatives or describe when this tool should not be used.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.