独行录 / opcmenu

改组织资料

update_organization

Idempotent

【需要登录·OWNER/ADMIN】先get_organization，省略不改；负责人另可改可见性/加入方式/协议。名称/简介/类型/协议/表单推进协议版本，后续申请须重新同意；名称/类型让认证待审。地点/名录/全员发活动按身份限制，联盟身份另管。成员可见，先确认；logo用set_organization_logo。

Input Schema

TableJSON Schema

Name	Required	Description
`name`	No	组织名称（2-100 字）
`type`	No	BOARD 理事会 \| INCUBATOR 孵化器 \| CLUB 俱乐部 \| ASSOCIATION 协会/商会 \| INVESTOR 投资机构 \| COMMUNITY 社群（缺省）\| OTHER 其他。联盟不是组织类型：选 ALLIANCE 会被拒（联盟要在 App「我的 → 创建联盟」单独申请）
`place`	No	城市/国家/游民；null 清空
`terms`	No	新的加入协议 {title, body}（仅负责人；传了即发新版本）
`formFields`	No	整组替换申请表题目
`joinPolicy`	No	OPEN \| REVIEW \| INVITE（仅负责人）
`visibility`	No	PUBLIC \| PRIVATE（仅负责人）
`description`	No	简介（≤5000 字）
`organizationId`	Yes	组织 id
`publicDirectory`	No	公开成员名录；仅负责人可开，私密组织不可开
`membersCanPublishActivities`	No	允许在册成员发活动；须 OWNER/ADMIN

Schema Changelog

Changes observed during successful MCP inspections.

Changed3 schema fields changedOct 4, 2026

addedInput schema / properties / membersCanPublishActivities

Added value: +{
+  "description": "允许在册成员发活动；须 OWNER/ADMIN",
+  "type": "boolean"
+}

addedInput schema / properties / place

Added value: +{
+  "anyOf": [
+    {
+      "maxLength": 20,
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "description": "城市/国家/游民；null 清空"
+}

addedInput schema / properties / publicDirectory

Added value: +{
+  "description": "公开成员名录；仅负责人可开，私密组织不可开",
+  "type": "boolean"
+}

Changed1 schema field changedOct 1, 2026

changedInput schema / properties / type / description

Previous value: -"BOARD 理事会 | INCUBATOR 孵化器 | CLUB 俱乐部 | ASSOCIATION 协会/商会 | INVESTOR 投资机构 | COMMUNITY 社群（缺省）| OTHER 其他 | ALLIANCE（独行录官方联盟由平台建，自建组织别选）"New value: +"BOARD 理事会 | INCUBATOR 孵化器 | CLUB 俱乐部 | ASSOCIATION 协会/商会 | INVESTOR 投资机构 | COMMUNITY 社群（缺省）| OTHER 其他。联盟不是组织类型：选 ALLIANCE 会被拒（联盟要在 App「我的 → 创建联盟」单独申请）"

AddedSep 28, 2026

TDQS

A4.4/5.0

Behavior5/5

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

Beyond the annotations (which only say it is a non-read-only, idempotent, non-destructive write), it discloses real side effects: name/bio/type/terms/formFields advance the agreement version so prior applicants must re-consent, and name/type move verification into a pending-review state. It also notes identity-based restrictions on place/directory/activity-publishing and that omitted fields are left unchanged, consistent with idempotentHint.

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?

A single dense paragraph, front-loaded with the auth requirement and partial-update rule, using semicolons to pack many facts without filler sentences. It is terse to the point of being run-on, but every clause carries information.

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

Completeness4/5

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

For an 11-parameter, nested-object mutation with no output schema, the description covers authorization, partial-update semantics, side effects, and alternative tools. Return behavior is not described, but with no output schema that is a minor gap given how much else is covered.

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 the baseline is 3, but the description adds cross-field meaning beyond the schema: which fields only the owner may set, which fields trigger a version bump or re-verification, and the identity-based limits on place/publicDirectory/membersCanPublishActivities. It does not restate per-field constraints, which is appropriate given the rich schema.

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

Purpose4/5

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

The description establishes a partial-update tool for organization profile fields and distinguishes itself from siblings by pointing to get_organization for reads and set_organization_logo for logos, and by noting alliance identity is handled elsewhere. The verb 'update' is only implied (omitted fields unchanged), but the resource and scope are clear enough to separate it from neighboring tools.

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?

It states the precondition (login required, OWNER/ADMIN), instructs calling get_organization first, marks owner-only fields (visibility/join policy/terms), and routes two adjacent needs to alternatives (set_organization_logo for logo, separate handling for alliance identity). This is explicit when-to-use and when-to-use-something-else guidance.

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?