独行录 / opcmenu

接洽需求（找他聊聊）

contact_need

Idempotent

【需要登录】对某条需求「找他聊聊」：与发起人建立 1-1 会话并登记接洽。任何人都能接洽、人数不设上限，需求不会因被接洽而下架。幂等：重复调用只返回已有会话。

【组合链——这是关键】返回 conversationId，直接接 send_message 在该会话继续谈；开聊前可先 get_conversation_needs 一次拿全双方需求上下文。谈妥交付后双方各调一次 complete_need 完成。

【失败语义】不能接洽自己的需求 400 cannot_contact_own_need；404 need_not_found；409 need_closed = 这条需求已被作者下架或已关闭（下架不改 status，判据是返回里的 displaying 布尔，别拿 status 猜），别重试也别换个说法再发；429 chat_quota_exhausted = 今天新开会话的额度用完了（回复老会话不受影响），返回体自带出口，别退避重试。

【可选 message】建立会话后以你的名义发出的第一句话（纯文本，≤2000 字）。替用户打招呼时把招呼语一并放进来：用户只需确认一次，而不是「先确认开会话、再确认发消息」两次。会话已存在时同样照发这一句。

Input Schema

TableJSON Schema

Name	Required	Description	Default
`needId`	Yes	需求 id，从 list_needs_feed / search_needs / get_need 拿
`message`	No	可选：会话建立后以你的名义发出的第一句话（纯文本）。不传则只建会话、不发任何消息

Schema Changelog

Changes observed during successful MCP inspections.

Changed1 schema field changedSep 28, 2026

addedInput schema / properties / message

Added value: +{
+  "description": "可选：会话建立后以你的名义发出的第一句话（纯文本）。不传则只建会话、不发任何消息",
+  "maxLength": 2000,
+  "minLength": 1,
+  "type": "string"
+}

First observedSep 6, 2026

TDQS

A4.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover mutation/idempotency/open-world, but the description adds substantial behavior beyond them: login requirement, that the need is not taken down by contact, idempotent replay returning the existing conversation, and detailed failure semantics (400 own-need, 404, 409 closed with the displaying-boolean判据, 429 quota with no-retry guidance). This is rich, actionable disclosure; the only gap is no mention of return payload shape, though conversationId is named.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Long but front-loaded and organized with bracketed section headers (需要登录, 组合链, 失败语义, 可选 message). Every block carries useful operational detail; density is justified for a multi-failure, chained tool, though it is heavier than strictly necessary.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

No output schema exists and the description compensates by naming the return value (conversationId) and enumerating error codes with their meanings and retry guidance. For a tool with only 2 params and no annotations gaps, this is complete enough for correct invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so both parameters are already documented. The description still adds value by clarifying message semantics (first message sent in your name, plain text ≤2000) and advising the greeting be bundled into this call to avoid double confirmation, which is guidance the schema's terse text does not convey.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb+resource: '找他聊聊' – establishing a 1-1 conversation with a need's initiator and registering the contact. It immediately distinguishes itself from siblings by naming send_message, get_conversation_needs, and complete_need in the follow-up chain.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines5/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Explicitly prescribes the workflow: optionally call get_conversation_needs first for context, then send_message in the returned conversation, and complete_need after delivery. It also states eligibility ('anyone can contact, no cap') and idempotency, leaving nothing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

All 独行录 / opcmenu tools Inspect

Try in Browser

Pay for results, not tokens.Fund a bounty. Let AI agents compete and collaborate to solve your problems.agentbounties.appAd

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources

Need Help?