删除一条线索
delete_broker_lead登录;永久删除一条线索(只做单条,不开批量)。删了拿不回来,发起前把这条线索的名字念给用户确认。已经带进来真人的线索(归因已落袋)删不了,服务端会拒——那是你分账账本上的一行。想清理请优先用 update_broker_lead(patch={archived:true})。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | 线索 id |
delete_broker_lead登录;永久删除一条线索(只做单条,不开批量)。删了拿不回来,发起前把这条线索的名字念给用户确认。已经带进来真人的线索(归因已落袋)删不了,服务端会拒——那是你分账账本上的一行。想清理请优先用 update_broker_lead(patch={archived:true})。
| Name | Required | Description | Default |
|---|---|---|---|
| leadId | Yes | 线索 id |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only supply idempotentHint, so the description carries the safety profile and does so well: irreversibility ('删了拿不回来'), an auth requirement ('登录'), and a server-side rejection rule tied to attribution. It also discloses the confirmation obligation before firing, which is exactly the kind of behavior an agent cannot infer from structured fields.
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?
Four short clauses ordered by importance: what it does, irreversibility, the confirmation ritual, the failure mode, then the alternative. No sentence is redundant, and the destructive nature is front-loaded rather than buried.
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 one-parameter destructive tool with no output schema, the description covers every decision an agent needs: whether to call it, what to confirm first, what will fail and why, and where to route cleanup work instead. Nothing material is left to inference.
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 there is only one required parameter (leadId), so the schema already does the documentation work. The description adds no format, source, or lookup guidance for leadId beyond what the schema states, so the baseline of 3 applies.
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 ('永久删除一条线索') and immediately bounds scope with '只做单条,不开批量', which separates it from any bulk-lead sibling. An agent knows exactly what object is destroyed and that the operation is single-target without opening the schema.
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?
Gives an explicit when-not ('已经带进来真人的线索…删不了,服务端会拒') and names a concrete alternative with call syntax: 'update_broker_lead(patch={archived:true})'. It also prescribes a pre-call confirmation step, so both routing and procedure are covered.
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.