查看我的交流请求
list_connection_requests【需要登录】按方向/场景分页查本人交流请求,重验可见性、屏蔽与状态,无联系方式。与合作方案请求、协助联系申请不同,不混用id。
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| direction | No | all | |
| activityId | No | ||
| organizationId | No |
list_connection_requests【需要登录】按方向/场景分页查本人交流请求,重验可见性、屏蔽与状态,无联系方式。与合作方案请求、协助联系申请不同,不混用id。
| Name | Required | Description | Default |
|---|---|---|---|
| cursor | No | ||
| direction | No | all | |
| activityId | No | ||
| organizationId | No |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
注解已交代 readOnly/idempotent/openWorld,描述额外补充了注解未覆盖的行为:需要登录鉴权、结果会重验可见性/屏蔽/状态(即返回项受这些规则过滤)、且不含联系方式。这些是描述相对注解的净增值,但对分页行为(cursor 语义、页大小)未提及。
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?
单段紧凑,前置了最关键的"需要登录",随后依次给出范围、行为约束与工具区分,信息密度高、无冗余句。可读性因密集堆叠而略受影响,但中文表达下仍属精炼。
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?
无输出 schema,参数覆盖率 0%,描述覆盖了鉴权、过滤行为、结果约束与兄弟工具区分,对列表工具而言信息量尚可。但未解释 activityId/organizationId 这一"场景"过滤维度的含义与优先级,也未说明分页游标使用方式,面向 4 参数工具仍略显不足。
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 描述覆盖率 0%,4 个参数(cursor/direction/activityId/organizationId)在 schema 中完全无说明,描述需承担解释责任。描述以"方向/场景/分页"暗示了 direction、activityId/organizationId 与 cursor 的用途,部分补偿了覆盖缺口,但未给出取值(除 all/incoming/outgoing 外)或 cursor 格式。
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?
明确声明动词+资源("查本人交流请求"),并限定范围(本人、按方向/场景分页),agent 无需打开 schema 即可判断其与 get_connection_request 这类单条查询的区别。更进一步点名了两个易混淆的兄弟工具(合作方案请求、协助联系申请)并声明不混用 id。
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?
给出了使用前提"需要登录",并通过"与合作方案请求、协助联系申请不同,不混用id"显式排除了相近工具。但未说明何时该用本工具 vs get_connection_request(单条)或 list_my_cooperation_requests,缺少正面触发条件。
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.