Search the web in real-time using local Gemini, Grok, or GLM accounts to retrieve up-to-date tech news, documentation, and factual summaries with authoritative sources.
使用本地已登录的 Gemini / Grok / GLM 账号进行实时全网搜索，获取最新技术动态、文档与事实总结，并附带权威来源。
| Name | Required | Description | Default |
|---|---|---|---|
| query | Yes | 搜索关键词或想要查询的最新信息 | |
| engine | No | 指定搜索引擎后端：gemini (Google 检索，默认推荐)、glm (智谱中文检索)、grok (xAI实时检索)、duckduckgo (公共搜索)、auto (默认自动智能选择) |
Changes observed during successful MCP inspections.
v1.0.0Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Since no annotations are provided, the description carries the full burden. It discloses a key prerequisite (using locally logged-in accounts) and notes real-time retrieval with authoritative sources. However, it does not mention potential failures (e.g., no logged-in accounts), rate limits, or result formatting, leaving gaps.
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 a single, concise sentence that front-loads the core function (real-time web search) and adds relevant context (accounts, sources) without extraneous words. It is optimally sized.
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?
Despite lacking an output schema, the description hints at return content (tech trends, documents, fact summaries, sources) and the prerequisite of logged-in accounts. It does not explain error handling or pagination, but these are less critical for a simple search tool. Overall, it provides sufficient context for an agent to call it correctly.
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 100%, and the description does not add significant meaning beyond the schema. It mentions using logged-in accounts, which links to the 'engine' parameter, but the schema already explains each backend option. The description adds minimal value for parameters.
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 explicitly states the tool performs real-time web-wide search ('实时全网搜索'), retrieves latest tech trends, documents, and fact summaries with authoritative sources. This clearly distinguishes it from the sibling 'fetch_webpage', which fetches a specific page.
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 implies usage for searching rather than fetching specific pages, but it does not explicitly state when to use this tool over 'fetch_webpage' or provide exclusion criteria. The context of 'search' vs 'fetch' is implicit but not articulated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.