查线索池
list_broker_leads【需要登录】本人线索按来源/q/归档筛选,最多200。q支持号码归一查询但仅回尾4位,勿复述完整号码;note保留自定义资料并去电话邮箱。archived=true查归档。核对后scan_broker_matches(leadIds),新资料import_broker_leads。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| source | No | ||
| archived | No |
list_broker_leads【需要登录】本人线索按来源/q/归档筛选,最多200。q支持号码归一查询但仅回尾4位,勿复述完整号码;note保留自定义资料并去电话邮箱。archived=true查归档。核对后scan_broker_matches(leadIds),新资料import_broker_leads。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| limit | No | ||
| source | No | ||
| archived | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Beyond the annotations (readOnly/idempotent/destructive/openWorld), the description discloses login requirement, a 200-item cap, and critical privacy behavior: q is normalized but only the last 4 digits are returned, the agent is warned not to repeat the full number, and note strips phone/email. This is exactly the behavioral context annotations cannot convey.
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?
Dense and front-loaded: login/auth first, then filtering and the limit, then the privacy caveat, then routing. Each clause adds information, though the semicolon-packed Chinese makes it slightly heavy to scan.
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 annotations covering the safety profile and no output schema, the description still explains auth needs, result cap, the masked-number return, stripped fields in note, and the recommended follow-up tools. An agent has everything needed 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 0%, so the description must carry the meaning: q (number-normalized query returning only last 4 digits), archived (true = archived set), source (来源 filter), and limit (max 200). All four parameters receive some explanation, though limit's 1–200 range and default are only implied.
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 and resource ('本人线索' / list my leads) with filtering dimensions (来源/q/归档) and a max of 200. It is readily distinguishable from sibling broker tools like create_broker_lead or scan_broker_matches.
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 routes the agent along the broker workflow: '核对后scan_broker_matches(leadIds),新资料import_broker_leads', and explains that archived=true selects archived leads. Clear context for when to follow up, though it does not explicitly state when NOT to use it versus collect_broker_leads or list_broker_fresh_joiners.
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.