Skip to main content
Glama

独行录 / opcmenu

新建联盟自有组织

create_alliance_organization

【需要登录】须联盟 manage。确认组织字段/协议和自有关系(全部授权、员工自动进驻)后创建,我成为负责人并入联盟。创建与挂入分两步,失败先 list_my_organization_memberships 检查已创建组织,再决定挂入,勿直接重试。

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameYes
typeNoCOMMUNITY
termsNo
allianceIdYes
formFieldsNo
joinPolicyNoREVIEW
visibilityNoPUBLIC
descriptionNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Added

TDQS

A3.8/5.0
Behavior5/5

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

Beyond the annotations it discloses the login and permission requirements, the side effects (creator becomes head, all grants applied, employees auto-join the alliance), and the non-idempotent two-step nature implied by idempotentHint=false, explicitly warning '勿直接重试' (do not retry directly) with a recovery path. This is substantial behavioral context the annotations alone do not convey.

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?

It is a single dense paragraph with the permission requirement front-loaded and no filler sentences. It is tight, though the run-on phrasing makes it slightly harder to parse the distinct ideas at a glance.

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

Completeness3/5

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

For a mutation tool with nested objects and no output schema, the description covers permissions, side effects, and failure recovery well. However, with 0% schema coverage the eight input parameters (enums, nested formFields, terms) remain unexplained, leaving a real gap an agent would need to fill.

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

Parameters2/5

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

Schema description coverage is 0% across 8 parameters, so the description carries the full burden. It only vaguely references '组织字段/协议' (organization fields/terms) and adds no meaning for name, type, joinPolicy, visibility, description, or formFields structure. It leaves most of the complex nested parameters undocumented.

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 states a specific verb+resource ('创建' alliance organization) and the resulting state ('我成为负责人并入联盟'), and it explicitly distinguishes the create step from the separate attach step, which separates it from siblings like attach_alliance_organization and create_organization. The core purpose is slightly buried behind the permission preamble but is unambiguous.

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

Usage Guidelines4/5

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

It specifies prerequisites (login required, alliance manage permission) and the preconditions for invoking (confirm organization fields/terms and the ownership relationship). It also routes the agent on failure to list_my_organization_memberships and explains that creation and attachment are two steps, covering most when/when-not cases without explicit exclusions.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources