Perform a literal keyword search to find exact text matches in the curated library when semantic browsing does not identify a relevant situation group.
兜底的字面检索，只在 browse 挑不出来时用。处境是语义的，字面常常对不上。
| Name | Required | Description | Default |
|---|---|---|---|
| lang | No | 库的语言：zh 中文站，en 英文站。用户说英文就传 en —— 两边的处境不是互译，是各自长出来的（中文有社保、考研，英文另有别的）。 | zh |
| limit | No | ||
| query | Yes |
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 burden, and it does disclose the key behavioral trait: literal, fallback retrieval with probable semantic mismatch. However, it does not mention result format, pagination, side effects, or read-only status. The core limitation is stated, but other behavioral context is missing.
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 two concise sentences with no wasted words. The most important decision-relevant information, that this is a fallback for browse, is front-loaded. Every part earns its place.
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 tool is relatively simple, and the description plus schema covers core invocation intent and the lang parameter. But there is no output schema, no return-format hint, and no explanation of what successful or failed search results look like. For a fallback search tool this is adequate but not complete.
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 only 33%: lang is described, but query and limit have no descriptions. The description implies that query is a literal string, but it does not explicitly explain the three parameters or their relationships. It therefore does not compensate enough for the low schema 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 states a specific verb and resource: it is a literal search tool used as a fallback. It also explicitly contrasts itself with browse, saying it is used only when browse cannot pick something out. This clearly distinguishes search from its sibling tools even without inspecting schemas.
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 usage condition: use it only when browse fails to select the target. It also warns that literal matching often misses semantic situations, which helps an agent decide between browse and search. This is strong when-to-use guidance with a direct alternative named.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.