invite_organization_members【需要登录·OWNER/ADMIN】点名邀请站内用户加入组织，对方会立刻收到推送，接受即入会（免审）。一次最多 30 人。 【组合链】search_organization_invite_candidates 拿 userId → 把名单和附言念给用户确认 → 本工具 → list_organization_member_invites 看谁接了。 【口径/坑】① 已是成员、已有待回应邀请、30 天内拒过、被移出过、拉黑关系、未装 App 的云用户会进 skipped（带原因），不是失败。② message 是对方会看到的原文（≤200 字），发起前念给用户。③ 每个组织每天最多手动邀 200 人。
| Name | Required | Description | Default |
|---|---|---|---|
| message | No | 附言（对方在推送与邀请横幅里看到的原文），可选 | |
| userIds | Yes | 被邀请人的 userId，一次最多 30 | |
| organizationId | Yes | 组织 id |
Changes observed during successful MCP inspections.
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly=false, openWorld=true, idempotent=false, destructive=false, but the description adds substantial context: permission requirements, immediate recipient push, auto-accept/no-review behavior, 30-per-call and 200-per-day limits, and skipped reasons. This is rich behavioral disclosure beyond annotations with no contradictions.
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?
Bracketed sections front-load purpose, permission, side effect, then chain, then caveats. It is dense but every sentence carries operational detail for a complex mutation; there is no filler.
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 non-idempotent, open-world mutation with no output schema, the description covers prerequisites, side effects, daily caps, skipped-invite semantics, and follow-up verification. Nothing material for correct invocation is missing.
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%, so baseline is 3. The description adds that userIds should be obtained via search_organization_invite_candidates and that the message is recipient-facing text to confirm with the user before sending, giving extra operational meaning beyond the schema field descriptions.
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: inviting named in-app users into an organization, with permission level and the immediate push/auto-join effect. It names sibling tools in the combination chain, so an agent can distinguish it from search_organization_invite_candidates and list_organization_member_invites.
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 combination chain: use search_organization_invite_candidates to get userIds, confirm message with the user, call this tool, then use list_organization_member_invites to check acceptance. It also states login/OWNER/ADMIN prerequisites and clarifies that skipped invitees are not failures.
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.