寻找有权引荐的具体介绍人
find_network_candidates登录;按目标人/悬赏/需求找具体介绍人,沿用授权关系、组织及有效账号范围,返回person与证据;不代表目标同意,不发送邀请。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| text | No | ||
| limit | No | ||
| bountyId | No | ||
| targetUserId | No | ||
| targetContactId | No |
find_network_candidates登录;按目标人/悬赏/需求找具体介绍人,沿用授权关系、组织及有效账号范围,返回person与证据;不代表目标同意,不发送邀请。
| Name | Required | Description | Default |
|---|---|---|---|
| q | No | ||
| text | No | ||
| limit | No | ||
| bountyId | No | ||
| targetUserId | No | ||
| targetContactId | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only cover idempotent/non-destructive, so the description carries the load and does it well: auth requirement, the permission/relationship/active-account scope filter, and the return shape ('返回person与证据'). It also preempts a real misconception by stating that a candidate is not consent and no invite is sent. It stops short of describing result ordering, pagination, or what happens when no in-scope introducer exists.
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?
One dense, semicolon-delimited sentence with no filler, and the core action and returned artifact come before the caveats. The leading login note is slightly misordered relative to the main verb, but nothing is redundant.
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 6-parameter, no-output-schema discovery tool, the description covers purpose, scope, safety caveats and return content, which is most of what an agent needs. The gap is operational: with zero schema descriptions the agent still cannot tell how q, text and the ID parameters combine, nor how results are capped.
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 coverage is 0% across 6 optional parameters, so the description must compensate. It does partially: '目标人/悬赏/需求' maps onto targetUserId/targetContactId, bountyId and the need-oriented inputs, but q vs text (free-text vs search query), limit, and their interaction remain unexplained in both schema and description.
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?
Specific verb+resource: '按目标人/悬赏/需求找具体介绍人' states that it finds concrete introducers, and '沿用授权关系、组织及有效账号范围' pins the scoping. That distinguishes it from generic people search siblings such as search_people or list_network_contacts, though no sibling is named explicitly.
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?
Signals a login prerequisite ('登录') and a clear negative boundary ('不代表目标同意,不发送邀请'), which implies a read-only discovery step before any introduction is made. However, it never names the follow-up tool (e.g. create_network_introduction) or states when to pick this over list_network_introductions/list_network_contacts, leaving the routing to inference.
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.