nc-mcp-server

update_circle_config

Idempotent

Update a circle's config flags (bitmask) to control visibility, join permissions, federation, and more. The server automatically adjusts dependent flags for consistency.

Instructions

Update a circle's config flags (bitmask). Requires admin or owner level.

The server auto-adjusts dependent flags — inspect the config field of the returned circle to see what was actually stored:

Setting REQUEST (64) without OPEN auto-adds OPEN → stored as 80.
Setting FEDERATED (32768) without ROOT auto-adds ROOT → stored as 40960.
Clearing OPEN while REQUEST is on drops REQUEST too.
Clearing ROOT while FEDERATED is on drops FEDERATED too.

Args: circle_id: String circle id. config: Bitmask integer. Valid user-facing flags (combine with OR): 8=VISIBLE (listed for non-members), 16=OPEN (anyone can join via join_circle), 32=INVITE (adding a member generates an invitation to accept), 64=REQUEST (join requests need moderator approval; implies OPEN), 128=FRIEND (members can invite friends), 256=PROTECTED (password-protected; password must be set via a dedicated setting endpoint, not exposed by this tool), 4096=LOCAL (not federated, even on GlobalScale), 8192=ROOT (circle cannot be nested inside another circle), 16384=CIRCLE_INVITE (nested circles confirm before joining), 32768=FEDERATED (federated to other instances; implies ROOT), 65536=MOUNTPOINT (auto-create Files folder). Pass 0 for a fully private, invite-by-admin-only circle. NOTE: 1 (SINGLE), 2 (PERSONAL), 4 (SYSTEM), 512 (NO_OWNER), 1024 (HIDDEN), 2048 (BACKEND), and 131072 (APP) are rejected by the public API (400 "Configuration value is not valid").

Returns: JSON of the updated circle. Compare config in the response to the requested value to detect auto-mutations described above.

Input Schema

TableJSON Schema

Name	Required	Description	Default
`config`	Yes
`circle_id`	Yes

Output Schema

TableJSON Schema

Name	Required	Description	Default
`result`	Yes

Schema Changelog

Changes observed during successful MCP inspections.

First observedv0.7.0Sep 21, 2026

TDQS

A4.8/5.0

Behavior5/5

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

The description goes well beyond annotations by explaining server-side auto-adjustments with concrete examples (e.g., REQUEST→OPEN, FEDERATED→ROOT) and instructs to compare the returned config to detect mutations. It also discloses that certain flags are rejected by the public API and that password setting is handled elsewhere. This provides rich behavioral context beyond the idempotentHint=true annotation.

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

Conciseness5/5

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

Although long, the description is tightly structured with clear sections: purpose/requirement, auto-adjustment notes, Args list, and Returns. Every sentence conveys essential information; there is no fluff or redundancy. It is front-loaded with the core purpose and permission requirement.

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?

Given the complexity of a bitmask config with auto-adjustments and rejected flags, the description covers all necessary aspects: valid flags, dependencies, invalid values, and how to interpret the response. The output schema exists, so return format is implicitly covered, and the description adds guidance on comparing the config field. Nothing critical is missing.

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

Parameters5/5

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

With 0% schema description coverage, the description fully compensates. It explains circle_id as a string and config as a bitmask with a comprehensive list of flag values, meanings, OR-combination instructions, the meaning of 0, and rejected flags. This is far more than the schema offers and ensures correct parameter usage.

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?

The description states a specific verb and resource: 'Update a circle's config flags (bitmask).' It clearly distinguishes from siblings like update_circle_name and update_circle_description by focusing on the config bitmask. The purpose is unambiguous and immediately understandable.

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 the prerequisite 'Requires admin or owner level' and clarifies this tool is for config flags, not other circle properties. It doesn't explicitly mention when not to use it, but the context and sibling names make the intended use clear. It could be more explicit about alternatives, but the purpose is distinct enough.

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

Deploy Server