向鸣儿商业情报助手提问招投标线索。用自然语言描述需求（如"帮我找适合调查公司的本月招标项目""最近海南有哪些信息化类标的"），鸣儿自动检索项目库并给出线索清单、月度大盘概况与下一步建议。也可加 keyword 精准过滤。
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | 返回线索条数，默认10，最大30 | |
| keyword | No | 可选，标题关键词，如"社会调查""信息化" | |
| province | No | 可选，省名，如"海南" | |
| question | Yes | 自然语言问题，如"帮我找适合调查公司的招标项目" |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the full behavioral burden. It does disclose what happens at runtime (auto-searches the project library, returns a lead list, a monthly overview and follow-up suggestions), which is useful, but says nothing about whether it is read-only, latency, cost, or any access 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?
A compact, front-loaded passage: purpose first, then two inline examples, then the optional keyword filter. No filler sentences, though the embedded examples make it slightly denser than a strict one-line statement.
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?
With no output schema and no annotations, the description does cover what the tool returns (leads, monthly overview, suggestions), which is the main gap it needs to fill. It still omits any routing guidance against the closely related sibling tools, so it is not fully complete for selection.
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%, so all four parameters are already documented in the schema with defaults and examples ('limit' default 10 max 30, 'keyword', 'province', 'question'). The description only echoes the keyword filter, adding no new semantics beyond the schema, so the baseline 3 is appropriate.
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?
States a specific verb+resource: ask the 'Minger' assistant natural-language questions about bidding leads, and details the deliverable (lead list, monthly overview, next-step suggestions). The purpose is clear, but it never distinguishes itself from the sibling search_bidding_projects, which sounds like an overlapping retrieval tool.
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 gives concrete natural-language usage examples (finding suitable projects, recent Hainan informatization tenders), which implies when to use it. However, it offers no explicit exclusions or pointer to alternatives such as search_bidding_projects or get_bidding_market_stats, leaving the agent to guess which retrieval path to pick.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Add one secure layer between your agents and this server.