How do I use Circle MCP Server?

1. Click on "Deploy Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@Circle MCP Server show me my community's spaces and the latest posts in each one" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

Circle MCP Server

Q: Which integrations are available for this server?

Provides tools for interacting with the Circle community platform via its Admin API V2, enabling management of community members, spaces, posts, comments, events, courses, access groups, messages, forms, paywalls, and workflows. It exposes read operations and confirmed write operations for administering a Circle community.

by thenavidm

Overview Schema Source Related Servers Discussions Admin

TypeScript

Local

Circle MCP Server & CLI

npm License YouTube LinkedIn

Circle MCP server and CLI for Claude Code, Codex and AI agents. 170 tools: 66 reads and 104 confirmed writes for community members, spaces, posts, comments, events, courses, access groups, messages, forms, paywalls and workflows.

One package gives you two ways in: circle-mcp connects the tools to your AI app, and circle-cli makes the same tools shell commands. Claude Desktop also has a bundled .mcpb extension.

Built and maintained by Navid Moazzez. Built on Slipway, which turns one definition of each tool into the MCP server and the CLI. Complete installation and private account setup are in INSTALL.md.

The terminal illustrates shipped tools and the draft workflow. It is a presentation preview, not a verified live account operation.

You need a private Circle Admin V2 API token and eligible Admin API access. Community permissions and plan limits apply. The community wrapper preserves AGPL-3.0-or-later licensing; Circle service charges remain separate. This is not a Circle-endorsed product.

Circle already has an official hosted MCP with broad Admin API coverage and community MCP alternatives. No dedicated task CLI was identified in the official pages reviewed. The comparison below records the evidence; this package makes no unsupported claim of broader coverage or measured efficiency.

Two ways to use it

Command line

npm install -g @thenavidm/circle-mcp-cli@latest
circle-cli
circle-cli list-spaces --help
circle-cli schema create-post
circle-cli list-spaces --per-page 5 --agent

Configure credentials privately first. Every write needs --confirm; --agent and --yes never authorize changes.

MCP server, for your AI app

claude mcp add --scope user circle -- npx -y @thenavidm/circle-mcp-cli@latest

Then ask: Show this community's spaces and the latest posts in the space I choose. Full client/OS wiring is in INSTALL.md.

Which one

Where you work	Surface
Claude Code, Codex, Cursor or another shell agent	MCP, CLI or both
Claude Desktop chat	Local MCP or desktop bundle
Scripts/CI	CLI or an MCP client
Remote-URL-only web clients	Official hosted Circle MCP

Features

Capability	CLI	MCP
Community and spaces	circle-cli get-community / list-spaces	get_community / list_spaces
Members	circle-cli list-members / search-member	list_members / search_member
Draft posts	circle-cli create-post / get-post	create_post / get_post
Courses and events	circle-cli list-course-lessons / list-events	list_course_lessons / list_events
Workflow reads	circle-cli list-workflows	list_workflows
Access groups	circle-cli list-access-groups	list_access_groups
Private account labels	circle-cli list-accounts	list_accounts
Diagnosis	circle-cli doctor	CLI utility

Number	Section	Covers
1	What you can ask it	Prompts and coverage
2	Quick install	MCP, CLI and desktop
3	Set up Circle access	Tokens, plans and auth discrepancy
4	Connect your client	Clients and OS routes
5	Check it works	Doctor and first read
6	Output, flags and exit codes	Inputs, JSON and scripting
7	MCP or CLI and token cost	Actual usage measurement
8	Every tool and argument	All tools and arguments
9	Community workflows	Drafts, members, events and messages
10	Pagination, exports and uploads	Pages, quota and direct uploads
11	Several private accounts	Named credentials
12	Writing safely	Confirmation and logs
13	How it works	Shared source and maintenance
14	Your data	Hosts and private data
15	Environment variables	Credential/safety/tuning settings
16	Updates and removal	Updating and revoking
17	Troubleshooting	Symptoms and remedies
18	API coverage and comparisons	Official and community alternatives
19	Versions	Version history and migration
20	FAQ	Accordion questions

1. What you can ask it

Show this community's spaces and member directory.
Find an existing member before changing their access.
Read the latest posts and identify unanswered questions.
Draft the community post I requested, leaving it unpublished.
Inspect course sections, lessons, events and form submissions.
Read an existing workflow before the activation I requested.

The pinned Admin API v2 snapshot contains 169 operations. With the private account helper, this package exposes 170 tools: 66 reads and 104 confirmed writes. It covers members, access groups, community settings, basic/image posts, comments, events, courses, tags, forms, search, transcripts, messages, paywalls and workflows.

Circle already has an official hosted MCP. It is a useful OAuth connection with broad Admin API coverage. This implementation offers a local shared task CLI, named private tokens, predictable JSON and explicit bounded page retrieval. Tool counts do not establish broader coverage or efficiency. Live account outcomes and desktop GUI installation remain unverified.

2. Quick install

npm install -g @thenavidm/circle-mcp-cli@latest
circle-cli --version
circle-cli login
circle-cli doctor
circle-cli tools

Node 22 or newer is required for manual MCP and CLI installation. Set the API token privately before a network request. The release supplies a circle-2.0.0.mcpb archive for a compatible Claude Desktop host. It bundles production dependencies, no account credentials. See INSTALL.md for client and OS configuration.

For Claude Code, after private configuration:

claude mcp add --scope user circle -- npx -y @thenavidm/circle-mcp-cli@latest
claude mcp list

3. Set up Circle access

Obtain an Admin V2 token

Sign in to the intended Circle community as an admin.
Open Settings > Developers > Tokens.
Create a token with type Admin V2 on an eligible plan.
Store it only in private shell/client settings as CIRCLE_API_TOKEN, or use the private file route below.
Run circle-cli doctor, then circle-cli doctor --network for a community read.

Follow the current quick start. Never use a Circle password, browser cookies, a member access token or a Google OAuth client as a substitute. The Admin API is intended for administrative integrations; member-facing experiences use the separate Headless APIs. The local package does not perform OAuth or host an authorization callback. login prints instructions without opening a browser or saving credentials.

Authentication discrepancy

The pinned OpenAPI security scheme specifies Authorization: Token AUTH_TOKEN; the quick-start prose and examples use Bearer. This version defaults to Token, preserving the schema and existing implementation. Explicitly set CIRCLE_AUTH_SCHEME=Bearer if your account requires the prose's scheme. Named accounts accept auth_scheme. No automatic auth fallback or write resubmission occurs. Both choices need live account validation; fixture checks establish only the outgoing request shape.

The token identifies the community. Requests use the fixed HTTPS origin app.circle.so, with its normal Host header. No arbitrary base URL or legacy community-ID override is exposed.

Private token file

Save only the token text in a regular file outside the checkout. Set CIRCLE_TOKEN_FILE to its absolute path. It takes precedence over the environment token, is limited to 64 KB, and refuses symlinks. Protect POSIX files with mode 0600 and Windows files/folders with user-only ACLs. The process caches the token in memory: restart after rotation. No automatic .env loader is included, and GUI clients may not inherit terminal variables.

Plans, usage and revocation

The official MCP is for admins on Business plans and above. Admin API allowances are Business 5,000; Enterprise/Circle Plus 30,000; Circle Plus Platform 250,000 requests/month. The documented rate limit is 2,000 requests per five minutes per IP and may change. Official MCP actions, local CLI calls, retries and every retrieved page consume the same community allowance. Many 4xx responses count too; usage may appear about five minutes later. Do not treat the old January 2025 enforcement paragraph as a current grace period.

Default local pacing is 200 ms per account/process; it is not a global quota manager. Other processes and tools share limits. Revoke a token through Circle and remove private client settings to disconnect. Uninstalling npm does not revoke access or delete community data.

4. Connect your client

INSTALL.md includes Claude Code, Codex, Claude Desktop extension/manual settings, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Docker and other local stdio clients on macOS, Windows and Linux. All examples use placeholders or environment forwarding; actual values belong in private user settings.

The local MCP launches with npx -y @thenavidm/circle-mcp-cli@latest. A client that only accepts a remote URL needs the official OAuth MCP at https://app.circle.so/api/mcp. It does not accept this package's local launch command. Keep the two server entries distinct if you configure both. Browser-only setup and official OAuth permissions are separate from this package's private Admin token.

Agents with a shell can install the CLI and make SKILL.md available using the client's supported skills location. The package does not register skills automatically. Ask your agent to read INSTALL.md, verify Node/binaries, help you configure credentials privately and run discovery/doctor. Installing the package is not proof of account access.

5. Check it works

circle-cli --version
circle-cli doctor
circle-cli doctor --network
circle-cli list-accounts --agent
circle-cli list-spaces --per-page 5 --agent

Discovery and schema inspection work without credentials. The network doctor makes a community-details read without printing private community content. It does not invite members, publish posts or change billing. Success proves only access to that read with the selected credentials. Read-only discovery exposes 66 tools.

6. Output, flags and exit codes

Tool names become dashed commands; underscores are accepted too. Path parameter names follow the discovered schema, such as post_id → --post-id. Body tools accept individual top-level flags, complete --payload JSON, or --payload-file pointing to a regular JSON body file up to 5 MB. Do not mix those body routes. Path/query flags remain separate. Nested objects take JSON and array flags repeat once per item; a whole array is not a single item.

circle-cli get-post --help
circle-cli schema create-post
circle-cli list-members --member-tag-ids 3 --member-tag-ids 4 --per-page 10 --agent
circle-cli search --query "onboarding" --filters '{"space_ids":["7"]}' --agent

IDs above are illustrative; use discovered resources from your own community. Nullable fields require an actual JSON null inside payload; --field null is a string. Nested Tiptap properties preserve upstream extensibility; unknown top-level body fields are refused. Body-required fields are validated during execution even when the wrapper schema allows an alternative payload route. Operations whose upstream request body is required need body flags or an explicit payload; a deliberately supplied empty object is sent as JSON, never omitted.

Flag	Behavior
--help / schema COMMAND	Current argument help / full JSON Schema
--json	Structured JSON
--compact	One-line JSON
--agent	Compact JSON and no prompts; never confirms a write
--select a,b.c	Keep selected fields, including nested objects/arrays
--no-color / --no-input	Noninteractive house flags
--yes	Never replaces write confirmation
--confirm	Confirm only the requested mutation
--account NAME	Select private local credentials
--payload JSON / --payload-file PATH	Complete request body, mutually exclusive with body flags

Exit	Meaning
0	Success
1	Unexpected error
2	Invalid arguments or refused write, an unknown command or a hidden write
3	Resource not found
4	Authentication/permission failure
5	API/transport failure
7	Rate limit
10	Missing or invalid private configuration

Results go to stdout, errors as JSON to stderr. Selection changes local output, not the original API response or quota charge. API success is not proof of notification delivery or a completed export.

7. MCP or CLI and token cost

MCP and CLI are built by Slipway from each tool's one definition, so they share schemas, validation and HTTP handlers; there is no second API implementation.

Measured on 2026-10-05 against 2.0.1, the same day, with Claude Code 2.1.286 on Claude Opus 5.5 (one short prompt with and without the server connected, the difference read from the API's own usage figures) and Codex 0.159.3 on gpt-6.1-sol:

Cost	2.0.1	3.0.0
Claude Code, every tool loaded, every message	93,800	84,415
Claude Code's default, tool search, every message	2,499	2,499
`SKILL.md`, read once	903	940
Codex over the CLI, one task, median of five	86,128	82,915
Codex over MCP, the same task, median of five	77,642	77,488

The task was "find the command that refunds a member's charge, and the flags it requires". Every tool loaded costs less because many write bodies appeared twice, as their own fields and inside payload, and 3.0.0 writes each repeated part once under $defs. Over the CLI, every 3.0.0 run asked which (315 characters) where 2.0.1's read the full command list (11,631). Over MCP, Codex prints its own TypeScript rendering of the tool list and cuts it to about 10,000 tokens; the full rendering is 2,046 tokens longer on 3.0.0, while the part Codex kept was a little shorter, and two 2.0.1 runs printed only the tool names. SKILL.md costs 37 more because it now says how approval works over MCP.

API quota and service costs remain separate, and no other offering was measured.

8. Every tool and argument

All 169 API operations come from the pinned official v2 snapshot. list_accounts is the local helper. The tables document every top-level operation argument. schema returns all nested requirements, unions, nullable values and enums. A body marked required is required in the body, whether supplied by flags or payload.

Tool	API	Mode
`add_to_access_group`	`POST /api/admin/v2/access_groups/{access_group_id}/community_members`	Write, confirms
`remove_from_access_group`	`DELETE /api/admin/v2/access_groups/{access_group_id}/community_members`	Write, confirms
`list_access_group_community_members`	`GET /api/admin/v2/access_groups/{access_group_id}/community_members`	Read
`get_access_group_community_member`	`GET /api/admin/v2/access_groups/{access_group_id}/community_member`	Read
`create_access_group`	`POST /api/admin/v2/access_groups`	Write, confirms
`list_access_groups`	`GET /api/admin/v2/access_groups`	Read
`archive_access_group`	`DELETE /api/admin/v2/access_groups/{id}`	Write, confirms
`update_access_group`	`PUT /api/admin/v2/access_groups/{id}`	Write, confirms
`unarchive_access_group`	`PATCH /api/admin/v2/access_groups/{id}/unarchive`	Write, confirms
`search`	`GET /api/admin/v2/advanced_search`	Read
`update_chat_preferences`	`PUT /api/admin/v2/chat_preferences`	Write, confirms
`import_chat_room_message`	`POST /api/admin/v2/chat_room_message_imports`	Write, confirms
`create_comment`	`POST /api/admin/v2/comments`	Write, confirms
`list_comments`	`GET /api/admin/v2/comments`	Read
`delete_comment`	`DELETE /api/admin/v2/comments/{id}`	Write, confirms
`get_comment`	`GET /api/admin/v2/comments/{id}`	Read
`get_community`	`GET /api/admin/v2/community`	Read
`update_community`	`PUT /api/admin/v2/community`	Write, confirms
`create_lead`	`POST /api/admin/v2/community_leads`	Write, confirms
`delete_lead`	`DELETE /api/admin/v2/community_leads/{id}`	Write, confirms
`export_community_member_charges`	`POST /api/admin/v2/community_member_charges/export`	Write, confirms
`list_charges`	`GET /api/admin/v2/community_member_charges`	Read
`refund_community_member_charge`	`POST /api/admin/v2/community_member_charges/{id}/refund`	Write, confirms
`list_member_spaces`	`GET /api/admin/v2/community_member_spaces`	Read
`cancel_community_member_subscription`	`POST /api/admin/v2/community_member_subscriptions/{id}/cancel`	Write, confirms
`export_community_member_subscriptions`	`POST /api/admin/v2/community_member_subscriptions/export`	Write, confirms
`list_subscriptions`	`GET /api/admin/v2/community_member_subscriptions`	Read
`resume_community_member_subscription`	`POST /api/admin/v2/community_member_subscriptions/{id}/resume`	Write, confirms
`list_member_access_groups`	`GET /api/admin/v2/community_members/{community_member_id}/access_groups`	Read
`ban_community_member`	`PUT /api/admin/v2/community_members/{id}/ban_member`	Write, confirms
`create_member`	`POST /api/admin/v2/community_members`	Write, confirms
`list_members`	`GET /api/admin/v2/community_members`	Read
`delete_community_member`	`PUT /api/admin/v2/community_members/{id}/delete_member`	Write, confirms
`remove_member`	`DELETE /api/admin/v2/community_members/{id}`	Write, confirms
`get_member`	`GET /api/admin/v2/community_members/{id}`	Read
`update_member`	`PUT /api/admin/v2/community_members/{id}`	Write, confirms
`search_member`	`GET /api/admin/v2/community_members/search`	Read
`create_community_segment`	`POST /api/admin/v2/community_segments`	Write, confirms
`list_segments`	`GET /api/admin/v2/community_segments`	Read
`delete_community_segment`	`DELETE /api/admin/v2/community_segments/{id}`	Write, confirms
`update_community_segment`	`PUT /api/admin/v2/community_segments/{id}`	Write, confirms
`duplicate_community_segment`	`POST /api/admin/v2/community_segments/{id}/duplicate`	Write, confirms
`create_contact_note`	`POST /api/admin/v2/contacts/{contact_id}/contact_notes`	Write, confirms
`list_contact_notes`	`GET /api/admin/v2/contacts/{contact_id}/contact_notes`	Read
`update_course_progress`	`PUT /api/admin/v2/course_lesson_progress`	Write, confirms
`create_course_lesson`	`POST /api/admin/v2/course_lessons`	Write, confirms
`list_course_lessons`	`GET /api/admin/v2/course_lessons`	Read
`delete_course_lesson`	`DELETE /api/admin/v2/course_lessons/{id}`	Write, confirms
`get_course_lesson`	`GET /api/admin/v2/course_lessons/{id}`	Read
`update_course_lesson`	`PATCH /api/admin/v2/course_lessons/{id}`	Write, confirms
`reorder_course_lessons`	`PUT /api/admin/v2/course_lessons/reorder`	Write, confirms
`create_course_section`	`POST /api/admin/v2/course_sections`	Write, confirms
`list_course_sections`	`GET /api/admin/v2/course_sections`	Read
`delete_course_section`	`DELETE /api/admin/v2/course_sections/{id}`	Write, confirms
`get_course_section`	`GET /api/admin/v2/course_sections/{id}`	Read
`update_course_section`	`PUT /api/admin/v2/course_sections/{id}`	Write, confirms
`create_direct_upload`	`POST /api/admin/v2/direct_uploads`	Write, confirms
`create_embed`	`POST /api/admin/v2/embeds`	Write, confirms
`get_embed`	`GET /api/admin/v2/embeds/{sgid}`	Read
`create_event_attendee`	`POST /api/admin/v2/event_attendees`	Write, confirms
`delete_event_attendee`	`DELETE /api/admin/v2/event_attendees`	Write, confirms
`list_event_attendees`	`GET /api/admin/v2/event_attendees`	Read
`create_event`	`POST /api/admin/v2/events`	Write, confirms
`list_events`	`GET /api/admin/v2/events`	Read
`delete_event`	`DELETE /api/admin/v2/events/{id}`	Write, confirms
`get_event`	`GET /api/admin/v2/events/{id}`	Read
`update_event`	`PUT /api/admin/v2/events/{id}`	Write, confirms
`duplicate_event`	`POST /api/admin/v2/spaces/{space_id}/events/{id}/duplicate`	Write, confirms
`get_filter_configuration`	`GET /api/admin/v2/filter_kit_configuration`	Read
`create_filter_control`	`POST /api/admin/v2/filter_kit_controls`	Write, confirms
`list_filter_controls`	`GET /api/admin/v2/filter_kit_controls`	Read
`delete_filter_control`	`DELETE /api/admin/v2/filter_kit_controls/{id}`	Write, confirms
`get_filter_control`	`GET /api/admin/v2/filter_kit_controls/{id}`	Read
`update_filter_control`	`PATCH /api/admin/v2/filter_kit_controls/{id}`	Write, confirms
`report_flagged_content`	`POST /api/admin/v2/flagged_contents`	Write, confirms
`list_flagged_content`	`GET /api/admin/v2/flagged_contents`	Read
`delete_form`	`DELETE /api/admin/v2/forms/{id}`	Write, confirms
`get_form`	`GET /api/admin/v2/forms/{id}`	Read
`update_form`	`PUT /api/admin/v2/forms/{id}`	Write, confirms
`duplicate_form`	`POST /api/admin/v2/forms/{id}/duplicate`	Write, confirms
`list_forms`	`GET /api/admin/v2/forms`	Read
`create_form_submission`	`POST /api/admin/v2/forms/{form_id}/submissions`	Write, confirms
`get_form_submissions`	`GET /api/admin/v2/forms/{form_id}/submissions`	Read
`get_leaderboard`	`GET /api/admin/v2/gamification/leaderboard`	Read
`create_image_post`	`POST /api/admin/v2/spaces/{space_id}/images/posts`	Write, confirms
`list_image_posts`	`GET /api/admin/v2/spaces/{space_id}/images/posts`	Read
`delete_image_post`	`DELETE /api/admin/v2/spaces/{space_id}/images/posts/{id}`	Write, confirms
`get_image_post`	`GET /api/admin/v2/spaces/{space_id}/images/posts/{id}`	Read
`duplicate_image_post`	`POST /api/admin/v2/spaces/{space_id}/images/posts/{id}/duplicate`	Write, confirms
`create_invitation`	`POST /api/admin/v2/invitation_links`	Write, confirms
`list_invitations`	`GET /api/admin/v2/invitation_links`	Read
`delete_invitation_link`	`DELETE /api/admin/v2/invitation_links/{id}`	Write, confirms
`update_invitation_link`	`PUT /api/admin/v2/invitation_links/{id}`	Write, confirms
`revoke_invitation_link`	`PATCH /api/admin/v2/invitation_links/{id}/revoke`	Write, confirms
`list_live_rooms`	`GET /api/admin/v2/live/rooms`	Read
`list_live_room_transcripts`	`GET /api/admin/v2/live/rooms/{room_id}/transcripts`	Read
`search_locations`	`GET /api/admin/v2/locations/search`	Read
`create_member_tag`	`POST /api/admin/v2/member_tags`	Write, confirms
`list_member_tags`	`GET /api/admin/v2/member_tags`	Read
`delete_member_tag`	`DELETE /api/admin/v2/member_tags/{id}`	Write, confirms
`get_member_tag`	`GET /api/admin/v2/member_tags/{id}`	Read
`update_member_tag`	`PUT /api/admin/v2/member_tags/{id}`	Write, confirms
`send_message`	`POST /api/admin/v2/messages`	Write, confirms
`list_page_profile_fields`	`GET /api/admin/v2/page_profile_fields`	Read
`get_payment_method_settings`	`GET /api/admin/v2/payment_method_setting`	Read
`export_paywall_affiliate_payouts`	`POST /api/admin/v2/paywall_affiliate_payouts/export`	Write, confirms
`mark_paywall_affiliate_payouts_paid`	`POST /api/admin/v2/paywall_affiliate_payouts/mark_paid`	Write, confirms
`start_paywall_affiliate_payouts`	`POST /api/admin/v2/paywall_affiliate_payouts/start`	Write, confirms
`list_paywall_affiliates`	`GET /api/admin/v2/paywall_affiliates`	Read
`invite_paywall_affiliates`	`POST /api/admin/v2/paywall_affiliates/invite`	Write, confirms
`update_paywall_affiliate`	`PATCH /api/admin/v2/paywall_affiliates/{id}`	Write, confirms
`delete_paywall_coupon`	`DELETE /api/admin/v2/paywall_coupons/{id}`	Write, confirms
`create_paywall_group`	`POST /api/admin/v2/paywall_groups`	Write, confirms
`update_paywall_group`	`PUT /api/admin/v2/paywall_groups/{id}`	Write, confirms
`search_paywalls`	`GET /api/admin/v2/paywalls/search`	Read
`delete_paywall`	`DELETE /api/admin/v2/paywalls/{id}`	Write, confirms
`archive_paywall`	`PUT /api/admin/v2/paywalls/{id}/archive`	Write, confirms
`publish_paywall`	`PUT /api/admin/v2/paywalls/{id}/publish`	Write, confirms
`unarchive_paywall`	`PUT /api/admin/v2/paywalls/{id}/unarchive`	Write, confirms
`unfollow_post`	`DELETE /api/admin/v2/posts/{post_id}/post_followers`	Write, confirms
`create_post`	`POST /api/admin/v2/posts`	Write, confirms
`list_posts`	`GET /api/admin/v2/posts`	Read
`delete_post`	`DELETE /api/admin/v2/posts/{id}`	Write, confirms
`get_post`	`GET /api/admin/v2/posts/{id}`	Read
`update_post`	`PUT /api/admin/v2/posts/{id}`	Write, confirms
`get_post_summary`	`GET /api/admin/v2/posts/{post_id}/summary`	Read
`archive_profile_field`	`PUT /api/admin/v2/profile_fields/{id}/archive`	Write, confirms
`create_profile_field`	`POST /api/admin/v2/profile_fields`	Write, confirms
`list_profile_fields`	`GET /api/admin/v2/profile_fields`	Read
`delete_profile_field`	`DELETE /api/admin/v2/profile_fields/{id}`	Write, confirms
`update_profile_field`	`PUT /api/admin/v2/profile_fields/{id}`	Write, confirms
`unarchive_profile_field`	`PUT /api/admin/v2/profile_fields/{id}/unarchive`	Write, confirms
`get_connect_settings`	`GET /api/admin/v2/settings/connect`	Read
`update_connect_settings`	`PATCH /api/admin/v2/settings/connect`	Write, confirms
`create_space_group_member`	`POST /api/admin/v2/space_group_members`	Write, confirms
`delete_space_group_member`	`DELETE /api/admin/v2/space_group_members`	Write, confirms
`list_space_group_members`	`GET /api/admin/v2/space_group_members`	Read
`get_space_group_member`	`GET /api/admin/v2/space_group_member`	Read
`create_space_group`	`POST /api/admin/v2/space_groups`	Write, confirms
`list_space_groups`	`GET /api/admin/v2/space_groups`	Read
`delete_space_group`	`DELETE /api/admin/v2/space_groups/{id}`	Write, confirms
`get_space_group`	`GET /api/admin/v2/space_groups/{id}`	Read
`update_space_group`	`PUT /api/admin/v2/space_groups/{id}`	Write, confirms
`add_space_member`	`POST /api/admin/v2/space_members`	Write, confirms
`remove_space_member`	`DELETE /api/admin/v2/space_members`	Write, confirms
`list_space_members`	`GET /api/admin/v2/space_members`	Read
`get_space_member`	`GET /api/admin/v2/space_member`	Read
`get_space_ai_summaries`	`GET /api/admin/v2/spaces/{space_id}/ai_summaries`	Read
`create_space`	`POST /api/admin/v2/spaces`	Write, confirms
`list_spaces`	`GET /api/admin/v2/spaces`	Read
`delete_space`	`DELETE /api/admin/v2/spaces/{id}`	Write, confirms
`get_space`	`GET /api/admin/v2/spaces/{id}`	Read
`update_space`	`PUT /api/admin/v2/spaces/{id}`	Write, confirms
`tag_member`	`POST /api/admin/v2/tagged_members`	Write, confirms
`untag_member`	`DELETE /api/admin/v2/tagged_members`	Write, confirms
`list_tagged_members`	`GET /api/admin/v2/tagged_members`	Read
`get_tagged_member`	`GET /api/admin/v2/tagged_members/{id}`	Read
`get_tax_settings`	`GET /api/admin/v2/tax_setting`	Read
`update_tax_settings`	`PUT /api/admin/v2/tax_setting`	Write, confirms
`create_topic`	`POST /api/admin/v2/topics`	Write, confirms
`list_topics`	`GET /api/admin/v2/topics`	Read
`delete_topic`	`DELETE /api/admin/v2/topics/{id}`	Write, confirms
`get_topic`	`GET /api/admin/v2/topics/{id}`	Read
`update_topic`	`PUT /api/admin/v2/topics/{id}`	Write, confirms
`activate_workflow`	`PUT /api/admin/v2/workflows/{id}/activate`	Write, confirms
`deactivate_workflow`	`PUT /api/admin/v2/workflows/{id}/deactivate`	Write, confirms
`duplicate_workflow`	`POST /api/admin/v2/workflows/{id}/duplicate`	Write, confirms
`list_workflows`	`GET /api/admin/v2/workflows`	Read
`get_workflow`	`GET /api/admin/v2/workflows/{id}`	Read
`list_accounts`	Local settings	Read

Shared arguments

All API tools accept account; all writes accept confirm. Tools with body properties accept payload or payload_file instead of body flags. Only the 33 reads with native page/per_page input expose all_pages and max_items. list_accounts takes no arguments.

Complete arguments

add_to_access_group

Add Member to Access Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli add-to-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access group id (path input). minimum: `1`.
`email`	string	Body	Email (body input).

remove_from_access_group

Remove Access Group Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli remove-from-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access group id (path input). minimum: `1`.
`email`	string	Yes	Email

list_access_group_community_members

List Access Group Community Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-access-group-community-members --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access Group ID minimum: `1`.
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_access_group_community_member

Show Access Group Community Member. Reads community data.

circle-cli get-access-group-community-member --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access Group ID minimum: `1`.
`email`	string	Yes	Email

create_access_group

Create Access Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group`	object	Body	Access group (body input). Object requires: `name`.

list_access_groups

List Access Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-access-groups --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`status`	string	No	Filter by access group status Values: `active`, `archived`, `all`.
`ids`	array	No	Filter by access group ids Array items: integer.
`name`	string	No	Filter by access group name
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

archive_access_group

Archive Access Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli archive-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access Group ID minimum: `1`.

update_access_group

Update Access Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access Group ID minimum: `1`.
`access_group`	object	Body	Access group (body input).

unarchive_access_group

Unarchive Access Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli unarchive-access-group --help

Argument	Type	Required	Meaning and constraints
`access_group_id`	integer	Yes	Access Group ID minimum: `1`.

search

Advanced Search. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli search --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`query`	string	Yes	Search query
`type`	string	No	Search type Values: `general`, `members`, `posts`, `comments`, `spaces`, `lessons`, `events`, `entity_list`, `mentions`.
`mention_scope`	string	No	Mention scope Values: `space`, `group_chat`, `thread`, `direct`.
`filters`	object	No	Filters
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

update_chat_preferences

Update Chat Preferences. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-chat-preferences --help

Argument	Type	Required	Meaning and constraints
`messaging_enabled`	boolean	No	Enable or disable messaging for the community
`group_messaging_enabled`	boolean	No	Enable or disable group messaging for the community
`voice_messages_enabled`	boolean	No	Enable or disable voice messages for the community
`member_to_member_messaging_enabled`	boolean	No	Enable or disable member-to-member messaging for the community

import_chat_room_message

Import Chat Room Message. Changes community state and requires confirm=true for the user-requested action.

circle-cli import-chat-room-message --help

Argument	Type	Required	Meaning and constraints
`chat_room_uuid`	string	Body	UUID of the target chat room (from a chat space)
`user_email`	string	Body	Email of the community member who is the message sender
`rich_text_body`	object	Body	TipTap rich text body, wrapped as `{ body: }`
`sent_at`	string	Body	Timestamp for the imported message. Required and must not be in the future. format: `date-time`.
`parent_message_id`	integer/null	No	ID of the parent message when creating a thread reply

create_comment

Create Comment. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-comment --help

Argument	Type	Required	Meaning and constraints
`body`	string	Body	Body (body input).
`post_id`	integer	Body	Post id (body input).
`parent_comment_id`	integer	No	Parent comment id (body input).
`created_at`	string	No	Created at (body input). format: `date-time`.
`updated_at`	string	No	Updated at (body input). format: `date-time`.
`skip_notifications`	boolean	No	Skip notifications (body input).

list_comments

List Comments. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-comments --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_id`	integer	No	Space ID
`post_id`	integer	No	Post ID
`search_text`	string	No	Search text
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_comment

Destroy Comment. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-comment --help

Argument	Type	Required	Meaning and constraints
`comment_id`	string	Yes	Comment id (path input).

get_comment

Show Comment. Reads community data.

circle-cli get-comment --help

Argument	Type	Required	Meaning and constraints
`comment_id`	string	Yes	Comment id (path input).

get_community

Get community details. Reads community data.

circle-cli get-community --help

Argument	Type	Required	Meaning and constraints
None	Not applicable	No	Shared account/confirmation controls only.

update_community

Update Community. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-community --help

Argument	Type	Required	Meaning and constraints
`community`	object	No	Community (body input).
`community_setting`	object	No	Community setting (body input).

create_lead

Create a non-member contact (lead). To add a full community member instead, use create_community_member.. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-lead --help

Argument	Type	Required	Meaning and constraints
`email`	string	Body	Email address of the contact. Must not already belong to a member or an existing non-member contact in this community.
`name`	string	No	Display name of the contact.
`member_tag_ids`	array	No	IDs of existing member tags to apply to the new contact. Use the member_tags endpoints to look these up. Array items: integer.

delete_lead

Delete a non-member contact (lead). To delete a full community member instead, use destroy_community_member.. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-lead --help

Argument	Type	Required	Meaning and constraints
`lead_id`	integer	Yes	Numeric id of the non-member contact to delete minimum: `1`.

export_community_member_charges

Export Community Member Charges. Changes community state and requires confirm=true for the user-requested action.

circle-cli export-community-member-charges --help

Argument	Type	Required	Meaning and constraints
`member_email`	string	No	Filter by community member email (partial match)
`community_member_id`	integer	No	Filter by community member ID
`community_member_public_uid`	string	No	Filter by community member public UID
`billing_info_business_name`	string	No	Filter by billing info business name (partial match)
`paywall_price_type`	string	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`processor_id`	string	No	Filter by exact processor (charge) ID
`subscription_processor_id`	string	No	Filter by exact subscription processor ID
`invoice_processor_id`	string	No	Filter by exact invoice processor ID
`currency`	string	No	Comma-separated list of currency codes
`paywall_ids`	string	No	Comma-separated list of paywall IDs
`status`	string	No	Comma-separated list of statuses (e.g. paid,refunded,partial_refunded)
`platform`	string	No	Comma-separated list of platforms (web, app_store, play_store)
`amount_gte`	integer	No	Minimum charge amount (in currency subunits)
`amount_lte`	integer	No	Maximum charge amount (in currency subunits)
`created_at_gte`	string	No	Only include charges created on/after this date (ISO8601)
`created_at_lte`	string	No	Only include charges created on/before this date (ISO8601)
`fields`	string	No	Comma-separated list of CSV columns to include
`timezone`	string	No	Timezone used to render dates in the CSV (defaults to Etc/UTC)

list_charges

Community Member Charges List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-charges --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Records per page (max 100) minimum: `1`. maximum: `100`.
`query`	string	No	Free-text search
`member_email`	string	No	Filter by community member email (partial match)
`community_member_id`	integer	No	Filter by community member ID
`community_member_public_uid`	string	No	Filter by community member public UID
`billing_info_business_name`	string	No	Filter by billing info business name (partial match)
`paywall_price_type`	string	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`processor_id`	string	No	Filter by exact processor (charge) ID
`subscription_processor_id`	string	No	Filter by exact subscription processor ID
`invoice_processor_id`	string	No	Filter by exact invoice processor ID
`currency`	string	No	Comma-separated list of currency codes
`paywall_ids`	string	No	Comma-separated list of paywall IDs
`status`	string	No	Comma-separated list of statuses (e.g. paid,refunded,partial_refunded)
`platform`	string	No	Comma-separated list of platforms (web, app_store, play_store)
`amount_gte`	integer	No	Minimum charge amount (in currency subunits)
`amount_lte`	integer	No	Maximum charge amount (in currency subunits)
`created_at_gte`	string	No	Only include charges created on/after this date (ISO8601)
`created_at_lte`	string	No	Only include charges created on/before this date (ISO8601)
`sort`	string	No	Sort field. Defaults to created_at. Values: `amount`, `charge_term`, `community_member_name`, `paywall_name`, `platform`, `display_status`, `created_at`.
`direction`	string	No	Sort direction. Defaults to desc. Values: `asc`, `desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

refund_community_member_charge

Refund Community Member Charge. Changes community state and requires confirm=true for the user-requested action.

circle-cli refund-community-member-charge --help

Argument	Type	Required	Meaning and constraints
`charge_id`	integer	Yes	Community Member Charge ID minimum: `1`.
`amount`	integer	No	Amount to refund (in currency subunits). Omit for a full refund.
`reason_details`	string	Body	Refund reason. Required, 255 characters max. maxLength: `255`.

list_member_spaces

List Community Member Spaces. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-member-spaces --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`community_member_id`	integer	No	Community member id (query input).
`user_email`	string	No	User email (query input).
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

cancel_community_member_subscription

Cancel Community Member Subscription. Changes community state and requires confirm=true for the user-requested action.

circle-cli cancel-community-member-subscription --help

Argument	Type	Required	Meaning and constraints
`subscription_id`	integer	Yes	Community Member Subscription ID minimum: `1`.
`ends_at`	string	Body	Cancellation timing: 'now' or 'at_period_end'.
`refund_type`	string	No	Optional refund type when canceling immediately: 'prorated' or 'full'.

export_community_member_subscriptions

Export Community Member Subscriptions. Changes community state and requires confirm=true for the user-requested action.

circle-cli export-community-member-subscriptions --help

Argument	Type	Required	Meaning and constraints
`member_email`	string	No	Filter by community member email (partial match)
`community_member_id`	integer	No	Filter by community member ID
`community_member_public_uid`	string	No	Filter by community member public UID
`billing_info_business_name`	string	No	Filter by billing info business name (partial match)
`paywall_price_type`	string	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`billing_interval`	string	No	Filter by paywall price billing interval (e.g. month, year)
`subscription_processor_id`	string	No	Filter by exact subscription processor ID
`currency`	string	No	Comma-separated list of currency codes
`paywall_ids`	string	No	Comma-separated list of paywall IDs
`status`	string	No	Comma-separated list of statuses (e.g. active,trial,canceled)
`scheduled_to_cancel`	boolean	No	Filter by whether the subscription is scheduled to cancel
`platform`	string	No	Comma-separated list of platforms (web, app_store, play_store)
`total_amount_paid_gte`	integer	No	Minimum total amount paid (in currency subunits)
`total_amount_paid_lte`	integer	No	Maximum total amount paid (in currency subunits)
`start_date_gte`	string	No	Only include subscriptions started on/after this date (ISO8601)
`start_date_lte`	string	No	Only include subscriptions started on/before this date (ISO8601)
`fields`	string	No	Comma-separated list of CSV columns to include
`timezone`	string	No	Timezone used to render dates in the CSV (defaults to Etc/UTC)

list_subscriptions

Community Member Subscriptions List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-subscriptions --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Records per page (max 100) minimum: `1`. maximum: `100`.
`query`	string	No	Free-text search
`member_email`	string	No	Filter by community member email (partial match)
`community_member_id`	integer	No	Filter by community member ID
`community_member_public_uid`	string	No	Filter by community member public UID
`billing_info_business_name`	string	No	Filter by billing info business name (partial match)
`paywall_price_type`	string	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`billing_interval`	string	No	Filter by paywall price billing interval (e.g. month, year)
`subscription_processor_id`	string	No	Filter by exact subscription processor ID
`currency`	string	No	Comma-separated list of currency codes
`paywall_ids`	string	No	Comma-separated list of paywall IDs
`status`	string	No	Comma-separated list of statuses (e.g. active,trial,canceled)
`scheduled_to_cancel`	boolean	No	Filter by whether the subscription is scheduled to cancel
`platform`	string	No	Comma-separated list of platforms (web, app_store, play_store)
`total_amount_paid_gte`	integer	No	Minimum total amount paid (in currency subunits)
`total_amount_paid_lte`	integer	No	Maximum total amount paid (in currency subunits)
`start_date_gte`	string	No	Only include subscriptions started on/after this date (ISO8601)
`start_date_lte`	string	No	Only include subscriptions started on/before this date (ISO8601)
`sort`	string	No	Sort field (one of: charges_quantity, subscription_term, renews_on, community_member_name, paywall_name, platform, status, created_at). Defaults to created_at
`direction`	string	No	Sort direction (asc or desc). Defaults to desc
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

resume_community_member_subscription

Resume Community Member Subscription. Changes community state and requires confirm=true for the user-requested action.

circle-cli resume-community-member-subscription --help

Argument	Type	Required	Meaning and constraints
`subscription_id`	integer	Yes	Community Member Subscription ID minimum: `1`.

list_member_access_groups

List Community Member's Access Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-member-access-groups --help

Argument	Type	Required	Meaning and constraints
`community_member_id`	integer	Yes	Community Member ID minimum: `1`.
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

ban_community_member

Ban Community Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli ban-community-member --help

Argument	Type	Required	Meaning and constraints
`member_id`	integer	Yes	Community member ID to ban minimum: `1`.

create_member

Create/Invite a community member. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Body	Email (body input).
`password`	string	No	Password (body input).
`skip_invitation`	boolean	No	Skip invitation (body input).
`avatar`	string	No	signed_id of the avatar returned from the direct upload endpoint
`name`	string	No	Name (body input).
`headline`	string	No	Headline (body input).
`is_flagged`	boolean	No	Is flagged (body input).
`preferences`	object	No	Preferences (body input).
`space_ids`	array	No	Space ids (body input). Array items: integer.
`space_group_ids`	array	No	Space group ids (body input). Array items: integer.
`member_tag_ids`	array	No	Member tag ids (body input). Array items: integer.
`community_member_profile_fields`	object	No	Profile fields key value pairs

list_members

List Community Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-members --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`status`	string	No	Filter by member status. Defaults to `active`. - `active`: members who have completed profile setup (`profile_confirmed_at` is set). - `inactive`: invited members who have not yet completed profile setup. This is the same set shown in the admin UI under Audience → Manage → Invited. - `all`: both of the above. Values: `active`, `all`, `inactive`.
`member_tag_ids`	array	No	Filter by Member Tag IDs (OR logic, comma-separated) Array items: integer.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_community_member

Delete Community Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-community-member --help

Argument	Type	Required	Meaning and constraints
`member_id`	integer	Yes	Community member ID to delete minimum: `1`.

remove_member

Deactivate a community member. Changes community state and requires confirm=true for the user-requested action.

circle-cli remove-member --help

Argument	Type	Required	Meaning and constraints
`member_id`	string	Yes	ID of the community member

get_member

Show a community member. Reads community data.

circle-cli get-member --help

Argument	Type	Required	Meaning and constraints
`member_id`	string	Yes	ID of the community member

update_member

Update a community member. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-member --help

Argument	Type	Required	Meaning and constraints
`member_id`	string	Yes	ID of the community member
`avatar`	string	No	signed_id of the avatar returned from the direct upload endpoint
`name`	string	No	Name (body input).
`headline`	string	No	Headline (body input).
`is_flagged`	boolean	No	Is flagged (body input).
`member_since`	string	No	Effective "member since" / joined date. Cannot be in the future. format: `date-time`.
`preferences`	object	No	Preferences (body input).
`space_ids`	array	No	Space ids (body input). Array items: integer.
`space_group_ids`	array	No	Space group ids (body input). Array items: integer.
`member_tag_ids`	array	No	Member tag ids (body input). Array items: integer.
`community_member_profile_fields`	object	No	Profile fields key value pairs

search_member

Search a community member. Reads community data.

circle-cli search-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Yes	Email of the community member

create_community_segment

Create a community segment. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-community-segment --help

Argument	Type	Required	Meaning and constraints
`title`	string	Body	Title (body input).
`visible`	boolean	Body	Visible (body input).
`rules`	object	Body	Rules (body input). Object requires: `rule_type`, `rules`.
`community_segment_consumer_attributes`	object	No	Community segment consumer attributes (body input).

list_segments

List Community Segments. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-segments --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`title`	string	No	Filter by title
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_community_segment

Delete a community segment. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-community-segment --help

Argument	Type	Required	Meaning and constraints
`segment_id`	string	Yes	ID of the community segment to delete

update_community_segment

Update a community segment. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-community-segment --help

Argument	Type	Required	Meaning and constraints
`segment_id`	string	Yes	ID of the community segment to update
`title`	string	Body	Title (body input).
`visible`	boolean	Body	Visible (body input).
`rules`	object	Body	Rules (body input). Object requires: `rule_type`, `rules`.
`community_segment_consumer_attributes`	object	No	Community segment consumer attributes (body input).

duplicate_community_segment

Duplicate a community segment. Changes community state and requires confirm=true for the user-requested action.

circle-cli duplicate-community-segment --help

Argument	Type	Required	Meaning and constraints
`segment_id`	string	Yes	ID of the community segment to duplicate
`title`	string	Yes	Title for the duplicated community segment

create_contact_note

Create Contact Note. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-contact-note --help

Argument	Type	Required	Meaning and constraints
`contact_id`	string	Yes	Contact ID or sqid
`tiptap_body`	object	Body	Rich text note in Tiptap document format Object requires: `body`.

list_contact_notes

List Contact Notes. Reads community data.

circle-cli list-contact-notes --help

Argument	Type	Required	Meaning and constraints
`contact_id`	string	Yes	Contact ID or sqid
`page`	integer	No	Page number minimum: `1`.

update_course_progress

Update Course Lesson Progress. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-course-progress --help

Argument	Type	Required	Meaning and constraints
`lesson_id`	integer	Body	Lesson id (body input).
`member_email`	string	Body	Member email (body input).
`status`	string	Body	Status (body input). Values: `incomplete`, `completed`.

create_course_lesson

Create a course lesson. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-course-lesson --help

Argument	Type	Required	Meaning and constraints
`section_id`	integer	Body	Section id (body input).
`name`	string	Body	Name (body input).
`status`	string	No	Status (body input). Values: `draft`, `published`.
`body_html`	string	No	Body html (body input).
`is_comments_enabled`	boolean	No	Is comments enabled (body input).
`is_featured_media_enabled`	boolean	No	Is featured media enabled (body input).
`is_featured_media_download_enabled`	boolean	No	Is featured media download enabled (body input).
`thumbnail`	string	No	signed_id of the lesson thumbnail image returned from the direct upload endpoint
`featured_media`	string	No	signed_id of the lesson featured media file returned from the direct upload endpoint
`rich_text_body`	object	No	Rich text body (body input).

list_course_lessons

List course lessons. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-course-lessons --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`section_id`	integer	No	Section ID
`space_id`	integer	No	Space ID
`status`	string	No	Status Values: `draft`, `published`.
`sort`	string	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest) Values: `oldest`, `newest`, `alphabetical`, `alphabetical_desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_course_lesson

Delete a course lesson. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-course-lesson --help

Argument	Type	Required	Meaning and constraints
`lesson_id`	integer	Yes	Course lesson ID minimum: `1`.

get_course_lesson

Show a course lesson. Reads community data.

circle-cli get-course-lesson --help

Argument	Type	Required	Meaning and constraints
`lesson_id`	integer	Yes	ID of the course lesson minimum: `1`.

update_course_lesson

Update a course lesson. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-course-lesson --help

Argument	Type	Required	Meaning and constraints
`lesson_id`	integer	Yes	ID of the course lesson minimum: `1`.
`name`	string	No	Name (body input).
`status`	string	No	Status (body input). Values: `draft`, `published`.
`body_html`	string	No	Body html (body input).
`is_comments_enabled`	boolean	No	Is comments enabled (body input).
`is_featured_media_enabled`	boolean	No	Is featured media enabled (body input).
`is_featured_media_download_enabled`	boolean	No	Is featured media download enabled (body input).
`thumbnail`	string	No	signed_id of the lesson thumbnail image returned from the direct upload endpoint
`featured_media`	string	No	signed_id of the lesson featured media file returned from the direct upload endpoint
`rich_text_body`	object	No	Rich text body (body input).

reorder_course_lessons

Reorder course lessons. Changes community state and requires confirm=true for the user-requested action.

circle-cli reorder-course-lessons --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Body	ID of the course space
`new_order`	array	Body	All course sections and lessons in their final order Array items: object.

create_course_section

Create a course section. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-course-section --help

Argument	Type	Required	Meaning and constraints
`name`	string	Body	Name (body input).
`space_id`	integer	Body	Space id (body input).

list_course_sections

List Course Sections. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-course-sections --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_id`	integer	No	Space ID of the course section
`sort`	string	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest) Values: `oldest`, `newest`, `alphabetical`, `alphabetical_desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_course_section

Delete a course section. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-course-section --help

Argument	Type	Required	Meaning and constraints
`section_id`	integer	Yes	Course section ID minimum: `1`.

get_course_section

Show a course section. Reads community data.

circle-cli get-course-section --help

Argument	Type	Required	Meaning and constraints
`section_id`	integer	Yes	ID of the course section minimum: `1`.

update_course_section

Update a course section. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-course-section --help

Argument	Type	Required	Meaning and constraints
`section_id`	integer	Yes	ID of the course section minimum: `1`.
`name`	string	Body	Name (body input).

create_direct_upload

Create Direct Upload. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-direct-upload --help

Argument	Type	Required	Meaning and constraints
`blob`	object	Body	Blob (body input). Object requires: `key`, `filename`, `content_type`, `byte_size`, `checksum`.

create_embed

Create Embed. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-embed --help

Argument	Type	Required	Meaning and constraints
`url`	string	Body	The URL to embed (e.g., YouTube, Vimeo, etc.)

get_embed

Get Embed. Reads community data.

circle-cli get-embed --help

Argument	Type	Required	Meaning and constraints
`sgid`	string	Yes	The sgid of the embed

create_event_attendee

Create Event Attendee. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-event-attendee --help

Argument	Type	Required	Meaning and constraints
`member_email`	string	No	Member Email
`event_id`	string	No	Event ID

delete_event_attendee

Delete Event Attendee. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-event-attendee --help

Argument	Type	Required	Meaning and constraints
`member_email`	string	No	Member Email
`event_id`	string	No	Event ID

list_event_attendees

List Event Attendees. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-event-attendees --help

Argument	Type	Required	Meaning and constraints
`event_id`	string	Yes	Event ID
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

create_event

Create Event. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-event --help

Argument	Type	Required	Meaning and constraints
`event`	object	Body	Event (body input). Object requires: `name`, `space_id`, `status`.
`space_id`	integer	Body	Space id (body input).

list_events

List Events. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-events --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_id`	integer	No	Filter events by event space ID
`filter_date_start_date`	string	No	Start date for filtering events (format: YYYY-MM-DD) format: `date`.
`filter_date_end_date`	string	No	End date for filtering events (format: YYYY-MM-DD) format: `date`.
`sort`	string	No	Sort events - oldest (by created_at), start_date (by starts_at ascending), start_date_desc (by starts_at descending), default is newest (by published_at) Values: `oldest`, `start_date`, `start_date_desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_event

Delete Event. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-event --help

Argument	Type	Required	Meaning and constraints
`event_id`	integer	Yes	Event ID minimum: `1`.
`space_id`	integer	Yes	Space ID

get_event

Get Event. Reads community data.

circle-cli get-event --help

Argument	Type	Required	Meaning and constraints
`event_id`	integer	Yes	Event ID minimum: `1`.

update_event

Update Event. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-event --help

Argument	Type	Required	Meaning and constraints
`event_id`	integer	Yes	Event ID minimum: `1`.
`event`	object	Body	Event (body input). Object requires: `name`, `space_id`, `status`.
`space_id`	integer	Body	Space id (body input).

duplicate_event

Duplicate Event. Changes community state and requires confirm=true for the user-requested action.

circle-cli duplicate-event --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Space ID minimum: `1`.
`event_id`	integer	Yes	Event ID minimum: `1`.
`event`	object	Body	Event (body input). Object requires: `space_id`.

get_filter_configuration

Get the filters currently shown on the member directory or a member space. Reads community data.

circle-cli get-filter-configuration --help

Argument	Type	Required	Meaning and constraints
`context`	string	Yes	Surface to inspect. Use member_directory for the community directory or member_space for a specific members space. Values: `member_directory`, `member_space`.
`space_id`	integer	No	Members space ID. Required when context is member_space.

create_filter_control

Create a member filter control. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-filter-control --help

Argument	Type	Required	Meaning and constraints
`key`	string	Body	Filter to control; profile_field requires profile_field_id Values: `contact_search`, `near_me`, `online`, `recently_joined`, `location`, `tags`, `profile_field`, `spaces`, `space_groups`, `global`.
`enabled`	boolean	Body	Whether to show the filter
`space_id`	integer	No	Member space ID; omit for the member directory
`profile_field_id`	integer	No	Profile field ID; allowed only when key is profile_field
`sort_key`	integer	No	Optional ordering position; lower values sort first

list_filter_controls

List member directory and member space filter controls. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-filter-controls --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	No	Only controls for this member space
`member_directory_only`	boolean	No	Only member-directory controls that are not scoped to a space
`enabled`	boolean	No	Only enabled or disabled controls
`key`	string	No	Only controls for this filter key Values: `contact_search`, `near_me`, `online`, `recently_joined`, `location`, `tags`, `profile_field`, `spaces`, `space_groups`, `global`.
`profile_field_id`	integer	No	Only controls for this profile field
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page (max 100) minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_filter_control

Delete a filter control. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-filter-control --help

Argument	Type	Required	Meaning and constraints
`filter_control_id`	integer	Yes	ID of the filter control to delete minimum: `1`.

get_filter_control

Get a filter control. Reads community data.

circle-cli get-filter-control --help

Argument	Type	Required	Meaning and constraints
`filter_control_id`	integer	Yes	Filter control ID minimum: `1`.

update_filter_control

Update a member directory or member space filter control. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-filter-control --help

Argument	Type	Required	Meaning and constraints
`filter_control_id`	integer	Yes	Filter control ID. Use list_filter_kit_controls if the ID is unknown. minimum: `1`.
`key`	string	No	Filter to control. Values: `contact_search`, `near_me`, `online`, `recently_joined`, `location`, `tags`, `profile_field`, `spaces`, `space_groups`, `global`.
`enabled`	boolean	No	Whether the filter is shown. Set false to hide it.
`space_id`	integer	No	Member space ID to move this control to.
`profile_field_id`	integer	No	Profile field ID for a profile_field control.
`sort_key`	integer	No	Ordering position; lower values sort first.

report_flagged_content

Report Flagged Content. Changes community state and requires confirm=true for the user-requested action.

circle-cli report-flagged-content --help

Argument	Type	Required	Meaning and constraints
`flagged_content`	object	Body	Flagged content (body input). Object requires: `content_id`, `content_type`, `reported_reason_type`, `reported_reason_body`.

list_flagged_content

List Flagged Contents. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-flagged-content --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`status`	string	No	Status. Default: 'all'. Values: `all`, `inbox`, `approved`, `rejected`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_form

Delete a form. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-form --help

Argument	Type	Required	Meaning and constraints
`form_id`	integer	Yes	Form ID minimum: `1`.

get_form

Show a form. Reads community data.

circle-cli get-form --help

Argument	Type	Required	Meaning and constraints
`form_id`	integer	Yes	Form ID minimum: `1`.

update_form

Update a form. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-form --help

Argument	Type	Required	Meaning and constraints
`form_id`	integer	Yes	Form ID minimum: `1`.
`name`	string	No	Name (body input).
`after_submission_action`	string	No	After submission action (body input). Values: `thank_you_page`, `redirect`.
`embed_display_format`	string	No	Embed display format (body input). Values: `inline`, `popup`.
`redirect_url`	string/null	No	Redirect url (body input).
`status`	string	No	Status (body input). Values: `draft`, `published`.
`thank_you_page_title`	string/null	No	Thank you page title (body input).
`thank_you_page_body`	string/null	No	Thank you page body (body input).
`popup_delay`	integer	No	Popup delay (body input).
`popup_frequency`	integer	No	Popup frequency (body input).
`embed_styles`	object/null	No	Embed styles (body input).
`standalone_page_styles`	object/null	No	Standalone page styles (body input).
`elements`	array	No	Elements (body input). Array items: object.

duplicate_form

Duplicate a form. Changes community state and requires confirm=true for the user-requested action.

circle-cli duplicate-form --help

Argument	Type	Required	Meaning and constraints
`form_id`	string	Yes	ID of the form to duplicate

list_forms

List Forms. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-forms --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`name`	string	No	Filter by form name
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

create_form_submission

Create a form submission. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-form-submission --help

Argument	Type	Required	Meaning and constraints
`form_id`	integer	Yes	Form ID minimum: `1`.
`elements`	array	Body	Elements (body input). Array items: object.
`submission_on_behalf_of`	string/null	No	Email of the contact on behalf of which the submission is being created

get_form_submissions

List form submissions. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli get-form-submissions --help

Argument	Type	Required	Meaning and constraints
`form_id`	integer	Yes	Form ID minimum: `1`.
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_leaderboard

Show Leaderboard. Reads community data.

circle-cli get-leaderboard --help

Argument	Type	Required	Meaning and constraints
`period`	string	No	Leaderboard period, default is all time Values: `30_days`, `7_days`.

create_image_post

Create Image Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-image-post --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Image space ID minimum: `1`.
`slug`	string	No	Slug (body input).
`status`	string	No	Status (body input). Values: `draft`, `published`, `scheduled`.
`is_liking_enabled`	boolean	No	Is liking enabled (body input).
`is_comments_enabled`	boolean	No	Is comments enabled (body input).
`topics`	array	No	Topics (body input). Array items: integer.
`tiptap_body`	object	No	Tiptap body (body input).
`gallery_attributes`	object	Body	Gallery attributes (body input).
`user_email`	string	No	email of the author (preferred over user_id)
`user_id`	integer	No	id of the author
`is_pinned`	boolean	No	whether the post should be pinned to the top

list_image_posts

List Image Posts. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-image-posts --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Image space ID minimum: `1`.
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_image_post

Delete Image Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-image-post --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Image space ID minimum: `1`.
`post_id`	integer	Yes	Image post ID minimum: `1`.

get_image_post

Show Image Post. Reads community data.

circle-cli get-image-post --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Image space ID minimum: `1`.
`post_id`	integer	Yes	Image post ID minimum: `1`.

duplicate_image_post

Duplicate Image Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli duplicate-image-post --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Image space ID minimum: `1`.
`post_id`	integer	Yes	Image post ID minimum: `1`.
`post`	object	No	Post (body input).

create_invitation

Create invitation link. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-invitation --help

Argument	Type	Required	Meaning and constraints
`name`	string	Body	Name for the invitation link
`redirect_space_id`	integer	No	ID of the space to open after signup
`access_group_ids`	array	No	Access group IDs to attach. Presence, including an empty array, selects access-group mode Array items: integer.
`member_tag_ids`	array	No	Member tag IDs to apply when the link is used Array items: integer.
`paywall`	object/null	No	Optional paywall configuration

list_invitations

List Invitation Links. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-invitations --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`name`	string	No	Filter by invitation link name
`status`	string	No	Filter by invitation link status Values: `active`, `revoked`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_invitation_link

Delete invitation link. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-invitation-link --help

Argument	Type	Required	Meaning and constraints
`invitation_id`	integer	Yes	Invitation link ID minimum: `1`.

update_invitation_link

Update invitation link. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-invitation-link --help

Argument	Type	Required	Meaning and constraints
`invitation_id`	integer	Yes	Invitation link ID minimum: `1`.
`name`	string	No	Name for the invitation link
`redirect_space_id`	integer/null	No	ID of the space to open after signup. Set to null to remove the existing redirect
`access_group_ids`	array	No	Access group IDs to attach; fully replaces the current set (empty array detaches all) Array items: integer.
`member_tag_ids`	array	No	Member tag IDs to apply when the link is used Array items: integer.
`paywall`	object/null	No	Paywall configuration. Set to null to remove the existing paywall configuration

revoke_invitation_link

Revoke invitation link. Changes community state and requires confirm=true for the user-requested action.

circle-cli revoke-invitation-link --help

Argument	Type	Required	Meaning and constraints
`invitation_id`	integer	Yes	Invitation link ID minimum: `1`.

list_live_rooms

List Live Rooms. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-live-rooms --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

list_live_room_transcripts

List Live Room Transcripts. Reads community data.

circle-cli list-live-room-transcripts --help

Argument	Type	Required	Meaning and constraints
`room_id`	integer	Yes	Live Room ID minimum: `1`.

search_locations

Search locations. Reads community data.

circle-cli search-locations --help

Argument	Type	Required	Meaning and constraints
`query`	string	Yes	Free-text location query (e.g. 'San Francisco, CA' or 'Berlin').

create_member_tag

Create Member Tag. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-member-tag --help

Argument	Type	Required	Meaning and constraints
`color`	string	No	Color (body input).
`display_format`	string	No	Display format (body input). Values: `label`, `icon`.
`emoji`	string	No	Emoji (body input).
`is_background_enabled`	boolean	No	Is background enabled (body input).
`is_public`	boolean	No	Is public (body input).
`name`	string	No	Name (body input).
`display_locations`	object	No	Display locations (body input).
`custom_emoji`	object	No	Custom emoji (body input).

list_member_tags

Member Tags List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-member-tags --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`name`	string	No	Name of the member tag
`is_public`	boolean	No	Whether the member tag is public
`sort`	string	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest) Values: `oldest`, `newest`, `alphabetical`, `alphabetical_desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_member_tag

Deletes a member tag. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-member-tag --help

Argument	Type	Required	Meaning and constraints
`tag_id`	integer	Yes	Member tag ID minimum: `1`.

get_member_tag

Shows a member tag's details. Reads community data.

circle-cli get-member-tag --help

Argument	Type	Required	Meaning and constraints
`tag_id`	integer	Yes	Member tag ID minimum: `1`.

update_member_tag

Update member tag. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-member-tag --help

Argument	Type	Required	Meaning and constraints
`tag_id`	integer	Yes	Member tag ID minimum: `1`.
`color`	string	No	Color (body input).
`display_format`	string	No	Display format (body input). Values: `label`, `icon`.
`emoji`	string	No	Emoji (body input).
`is_background_enabled`	boolean	No	Is background enabled (body input).
`is_public`	boolean	No	Is public (body input).
`name`	string	No	Name (body input).
`display_locations`	object	No	Display locations (body input).
`custom_emoji`	object	No	Custom emoji (body input).

send_message

Create Message. Changes community state and requires confirm=true for the user-requested action.

circle-cli send-message --help

Argument	Type	Required	Meaning and constraints
`rich_text_body`	object/null	No	Rich text body (body input).
`user_email`	string	No	User email (body input).
`user_emails`	array	No	User emails (body input). Array items: string.
`chat_room_uuid`	string	No	Chat room uuid (body input).
`parent_message_id`	integer	No	Parent message id (body input).

list_page_profile_fields

Get Page Profile Fields. Reads community data.

circle-cli list-page-profile-fields --help

Argument	Type	Required	Meaning and constraints
`page_name`	string	Yes	Page name Values: `signup`, `edit_profile`, `profile_view`, `community_view`.

get_payment_method_settings

Retrieves the community's payment method preferences. Reads community data.

circle-cli get-payment-method-settings --help

Argument	Type	Required	Meaning and constraints
None	Not applicable	No	Shared account/confirmation controls only.

export_paywall_affiliate_payouts

Export Paywall Affiliate Payouts. Changes community state and requires confirm=true for the user-requested action.

circle-cli export-paywall-affiliate-payouts --help

Argument	Type	Required	Meaning and constraints
`community_member_ids`	array	No	Community member IDs to scope the export to (max 20 per request). Omit to export all processing payouts. maxItems: `20`. Array items: integer.

mark_paywall_affiliate_payouts_paid

Mark Paywall Affiliate Payouts Paid. Changes community state and requires confirm=true for the user-requested action.

circle-cli mark-paywall-affiliate-payouts-paid --help

Argument	Type	Required	Meaning and constraints
`community_member_ids`	array	No	Community member IDs to scope the mark-paid to (max 20 per request). Omit to mark all processing payouts as paid. maxItems: `20`. Array items: integer.

start_paywall_affiliate_payouts

Start Paywall Affiliate Payouts. Changes community state and requires confirm=true for the user-requested action.

circle-cli start-paywall-affiliate-payouts --help

Argument	Type	Required	Meaning and constraints
`community_member_ids`	array	No	Community member IDs to scope the start to (max 20 per request). Omit to start all due payouts. maxItems: `20`. Array items: integer.

list_paywall_affiliates

Paywall Affiliates List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-paywall-affiliates --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Records per page (max 100) minimum: `1`. maximum: `100`.
`filters`	object	No	Filters
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

invite_paywall_affiliates

Invite Paywall Affiliates. Changes community state and requires confirm=true for the user-requested action.

circle-cli invite-paywall-affiliates --help

Argument	Type	Required	Meaning and constraints
`existing_member_ids`	array	Body	Community member IDs to invite (max 20 per request). Must belong to the current community. maxItems: `20`. Array items: integer.

update_paywall_affiliate

Update Paywall Affiliate. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-paywall-affiliate --help

Argument	Type	Required	Meaning and constraints
`affiliate_id`	integer	Yes	Affiliate ID minimum: `1`.
`status`	string	No	Status (body input).

delete_paywall_coupon

Deletes a paywall coupon. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-paywall-coupon --help

Argument	Type	Required	Meaning and constraints
`id`	integer	Yes	Paywall coupon ID minimum: `1`.

create_paywall_group

Create Subscription Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-paywall-group --help

Argument	Type	Required	Meaning and constraints
`name`	string	Body	Name (body input).
`currency_id`	integer	Body	ID of the currency the group's paywalls are priced in

update_paywall_group

Update Subscription Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-paywall-group --help

Argument	Type	Required	Meaning and constraints
`paywall_group_id`	integer	Yes	Subscription group ID minimum: `1`.
`name`	string	No	Name (body input).
`currency_id`	integer	No	ID of the currency the group's paywalls are priced in

search_paywalls

Search Paywalls. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli search-paywalls --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Records per page (max 100) minimum: `1`. maximum: `100`.
`name`	string	No	Filter by paywall name or display name (partial match)
`status`	string	No	Comma-separated list of statuses (e.g. draft,active,inactive)
`currency`	string	No	Comma-separated list of currency codes
`paywall_id`	string	No	Comma-separated list of paywall IDs to include
`exclude_paywall_id`	string	No	Comma-separated list of paywall IDs to exclude
`subscription_group_id`	string	No	Comma-separated list of subscription group IDs to include
`exclude_subscription_group_id`	string	No	Comma-separated list of subscription group IDs to exclude
`sort`	string	No	Sort field (one of: title, status, created_at). Defaults to created_at
`direction`	string	No	Sort direction (asc or desc). Defaults to desc. Only takes effect when sort is also given -- direction alone is ignored
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_paywall

Deletes a paywall. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-paywall --help

Argument	Type	Required	Meaning and constraints
`paywall_id`	integer	Yes	Paywall ID minimum: `1`.

archive_paywall

Archives a paywall. Changes community state and requires confirm=true for the user-requested action.

circle-cli archive-paywall --help

Argument	Type	Required	Meaning and constraints
`paywall_id`	integer	Yes	Paywall ID minimum: `1`.

publish_paywall

Publishes a paywall. Changes community state and requires confirm=true for the user-requested action.

circle-cli publish-paywall --help

Argument	Type	Required	Meaning and constraints
`paywall_id`	integer	Yes	Paywall ID minimum: `1`.

unarchive_paywall

Unarchives a paywall. Changes community state and requires confirm=true for the user-requested action.

circle-cli unarchive-paywall --help

Argument	Type	Required	Meaning and constraints
`paywall_id`	integer	Yes	Paywall ID minimum: `1`.

unfollow_post

Unfollow a post. Changes community state and requires confirm=true for the user-requested action.

circle-cli unfollow-post --help

Argument	Type	Required	Meaning and constraints
`post_id`	integer	Yes	Post ID minimum: `1`.
`community_member_id`	integer	Yes	Community Member ID

create_post

Create Basic Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-post --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Body	Space id (body input).
`status`	string	No	Status (body input). Values: `draft`, `published`, `scheduled`.
`name`	string	Body	Name (body input).
`slug`	string	No	Slug (body input).
`tiptap_body`	object	No	Tiptap body (body input).
`cover_image`	string	No	signed_id of the cover image
`internal_custom_html`	string	No	Internal custom html (body input).
`is_truncation_disabled`	boolean	No	Is truncation disabled (body input).
`is_comments_closed`	boolean	No	Is comments closed (body input).
`is_comments_enabled`	boolean	No	Is comments enabled (body input).
`is_liking_enabled`	boolean	No	Is liking enabled (body input).
`hide_meta_info`	boolean	No	Hide meta info (body input).
`hide_from_featured_areas`	boolean	No	Hide from featured areas (body input).
`meta_title`	string	No	Meta title (body input).
`meta_description`	string	No	Meta description (body input).
`opengraph_title`	string	No	Opengraph title (body input).
`opengraph_description`	string	No	Opengraph description (body input).
`published_at`	string	No	Published at (body input).
`created_at`	string	No	Created at (body input).
`topics`	array	No	Topics (body input). Array items: integer.
`skip_notifications`	boolean	No	Skip notifications (body input).
`is_pinned`	boolean	No	Is pinned (body input).
`user_email`	string	No	email of the author (preferred over user_id)
`user_id`	integer	No	id of the author

list_posts

List Basic Posts. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-posts --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_id`	integer	No	Basic type space ID
`space_group_id`	integer	No	Space Group ID
`status`	string	No	Post status Values: `draft`, `published`, `scheduled`, `all`.
`search_text`	string	No	Search text
`sort`	string	No	Sort by Values: `oldest`, `latest`, `alphabetical`, `likes`, `latest_updated`, `oldest_updated`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_post

Delete Basic Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-post --help

Argument	Type	Required	Meaning and constraints
`post_id`	string	Yes	Post id (path input).

get_post

Show Basic Post. Reads community data.

circle-cli get-post --help

Argument	Type	Required	Meaning and constraints
`post_id`	integer	Yes	Post ID minimum: `1`.

update_post

Update Basic Post. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-post --help

Argument	Type	Required	Meaning and constraints
`post_id`	string	Yes	Post id (path input).
`tiptap_body`	object	No	The Tiptap body will be updated only for posts that already contain a Tiptap body. If the post does not have a Tiptap body, the tiptap_body will be ignored.
`name`	string	No	Name (body input).
`cover_image`	string	No	signed_id of the cover image
`internal_custom_html`	string	No	Internal custom html (body input).
`is_truncation_disabled`	boolean	No	Is truncation disabled (body input).
`is_comments_closed`	boolean	No	Is comments closed (body input).
`is_comments_enabled`	boolean	No	Is comments enabled (body input).
`is_liking_enabled`	boolean	No	Is liking enabled (body input).
`hide_meta_info`	boolean	No	Hide meta info (body input).
`hide_from_featured_areas`	boolean	No	Hide from featured areas (body input).
`meta_title`	string	No	Meta title (body input).
`meta_description`	string	No	Meta description (body input).
`opengraph_title`	string	No	Opengraph title (body input).
`opengraph_description`	string	No	Opengraph description (body input).
`published_at`	string	No	Published at (body input).
`topics`	array	No	Topics (body input). Array items: integer.
`skip_notifications`	boolean	No	Skip notifications (body input).
`is_pinned`	boolean	No	Is pinned (body input).

get_post_summary

Get Post Summary. Reads community data.

circle-cli get-post-summary --help

Argument	Type	Required	Meaning and constraints
`post_id`	integer	Yes	Post ID minimum: `1`.

archive_profile_field

Archive Profile Field. Changes community state and requires confirm=true for the user-requested action.

circle-cli archive-profile-field --help

Argument	Type	Required	Meaning and constraints
`profile_field_id`	integer	Yes	Profile field ID minimum: `1`.

create_profile_field

Create Profile Field. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-profile-field --help

Argument	Type	Required	Meaning and constraints
`profile_field`	object	Body	Profile field (body input). Object requires: `label`, `field_type`, `key`, `pages_attributes`.

list_profile_fields

Profile Fields List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-profile-fields --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`label`	string	No	Filter by label (case-insensitive partial match)
`archived`	string	No	Set to 'true' to search archived profile fields, omit or set to 'false' for active fields
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_profile_field

Delete Profile Field. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-profile-field --help

Argument	Type	Required	Meaning and constraints
`profile_field_id`	integer	Yes	Archived profile field ID minimum: `1`.

update_profile_field

Update Profile Field. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-profile-field --help

Argument	Type	Required	Meaning and constraints
`profile_field_id`	integer	Yes	Profile field ID minimum: `1`.
`profile_field`	object	Body	Profile field (body input).

unarchive_profile_field

Unarchive Profile Field. Changes community state and requires confirm=true for the user-requested action.

circle-cli unarchive-profile-field --help

Argument	Type	Required	Meaning and constraints
`profile_field_id`	integer	Yes	Profile field ID minimum: `1`.

get_connect_settings

Get Connect settings. Reads community data.

circle-cli get-connect-settings --help

Argument	Type	Required	Meaning and constraints
None	Not applicable	No	Shared account/confirmation controls only.

update_connect_settings

Update Connect settings. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-connect-settings --help

Argument	Type	Required	Meaning and constraints
`connect`	object	No	Connect (body input).
`member_directory`	object	No	Member directory (body input).
`messaging`	object	No	Messaging (body input).

create_space_group_member

Create Space Group Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-space-group-member --help

Argument	Type	Required	Meaning and constraints
`space_group_id`	integer	Body	Space group id (body input).
`email`	string	Body	Email (body input).

delete_space_group_member

Destroy Space Group Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-space-group-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Yes	Email of the user
`space_group_id`	integer	Yes	ID of the space group

list_space_group_members

List Space Group Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-space-group-members --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_group_id`	integer	Yes	Space Group ID
`status`	string	No	Space group member status. By default, it returns all members. Values: `active`, `inactive`, `all`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_space_group_member

Show Space Group Member. Reads community data.

circle-cli get-space-group-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Yes	Email of the user
`space_group_id`	integer	Yes	ID of the space group

create_space_group

Create Space Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-space-group --help

Argument	Type	Required	Meaning and constraints
`name`	string	Body	Name (body input).
`slug`	string	Body	Slug (body input).
`is_hidden_from_non_members`	boolean	No	Is hidden from non members (body input).
`hide_members_count`	boolean	No	Hide members count (body input).
`allow_members_to_create_spaces`	boolean	No	Allow members to create spaces (body input).
`automatically_add_members_to_new_spaces`	boolean	No	Automatically add members to new spaces (body input).
`add_members_to_space_group_on_space_join`	boolean	No	Add members to space group on space join (body input).
`hide_non_member_spaces_from_sidebar`	boolean	No	Hide non member spaces from sidebar (body input).

list_space_groups

List Space Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-space-groups --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`name`	string	No	Filter by name
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_space_group

Delete Space Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-space-group --help

Argument	Type	Required	Meaning and constraints
`space_group_id`	integer	Yes	Space Group ID minimum: `1`.

get_space_group

Show Space Group. Reads community data.

circle-cli get-space-group --help

Argument	Type	Required	Meaning and constraints
`space_group_id`	integer	Yes	Space Group ID minimum: `1`.

update_space_group

Update Space Group. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-space-group --help

Argument	Type	Required	Meaning and constraints
`space_group_id`	integer	Yes	Space Group ID minimum: `1`.
`name`	string	No	Name (body input).
`slug`	string	No	Slug (body input).
`is_hidden_from_non_members`	boolean	No	Is hidden from non members (body input).
`hide_members_count`	boolean	No	Hide members count (body input).
`allow_members_to_create_spaces`	boolean	No	Allow members to create spaces (body input).
`automatically_add_members_to_new_spaces`	boolean	No	Automatically add members to new spaces (body input).
`add_members_to_space_group_on_space_join`	boolean	No	Add members to space group on space join (body input).
`hide_non_member_spaces_from_sidebar`	boolean	No	Hide non member spaces from sidebar (body input).
`moderator_community_member_ids`	array	No	Array of community member ids to add as moderators Array items: integer.

add_space_member

Add Space Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli add-space-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Body	Email (body input).
`space_id`	integer	Body	Space id (body input).

remove_space_member

Remove Space Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli remove-space-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Yes	Email
`space_id`	integer	Yes	Space ID

list_space_members

List Space Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-space-members --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`space_id`	integer	Yes	Space ID
`status`	string	No	Space member status. By default, it returns all members. Values: `active`, `inactive`, `all`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_space_member

Show Space Member. Reads community data.

circle-cli get-space-member --help

Argument	Type	Required	Meaning and constraints
`email`	string	Yes	Email
`space_id`	integer	Yes	Space ID

get_space_ai_summaries

Summarize a space. Reads community data.

circle-cli get-space-ai-summaries --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Space ID minimum: `1`.
`date_from`	string	No	Filters messages created after the provided ISO8601 timestamp format: `date-time`.
`first_unread_message_id`	integer	No	First unread message ID to include additional chat context

create_space

Create Space. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-space --help

Argument	Type	Required	Meaning and constraints
`name`	string	Body	Name (body input).
`slug`	string	Body	Slug (body input).
`cover_image`	string	No	signed_id of the cover image
`cover_image_visible`	boolean	No	Cover image visible (body input).
`cover_image_display_style`	string	No	Cover image display style (body input). Values: `normal`, `wide`.
`is_private`	boolean	No	Is private (body input).
`is_hidden_from_non_members`	boolean	No	Is hidden from non members (body input).
`is_hidden`	boolean	No	Is hidden (body input).
`locked_button_url`	string	No	Locked button url (body input).
`locked_button_label`	string	No	Locked button label (body input).
`locked_page_heading`	string	No	Locked page heading (body input).
`locked_page_description`	string	No	Locked page description (body input).
`is_post_disabled`	boolean	No	Is post disabled (body input).
`default_sort`	string	No	Default sort (body input).
`hide_sorting`	boolean	No	Hide sorting (body input).
`space_group_id`	integer	Body	Space group id (body input).
`topics`	array	No	Topics (body input). Array items: integer.
`custom_emoji`	object	No	Custom emoji (body input).
`space_type`	string	No	Space type (body input). Values: `basic`, `event`, `members`, `image`, `course`, `chat`.
`event_auto_rsvp_enabled`	boolean	No	Only for event spaces
`default_in_app_notification_setting`	string	No	Members will see an in-app notification when new events are posted Values: `never`, `all`.
`default_mobile_notification_setting`	string	No	Members will see a mobile notification when new events are posted Values: `never`, `all`.
`default_notification_setting`	string	No	Members will receive an email notification when new events are posted Values: `never`, `all`.
`course_setting`	object	No	Course space configuration
`thumbnail_image`	string	No	signed_id of the thumbnail image for event spaces
`default_mention_in_app_notification_setting`	string	No	Members will see an in-app notification when mentioned Values: `never`, `all`.
`default_mention_mobile_notification_setting`	string	No	Members will see a mobile notification when mentioned Values: `never`, `all`.
`hide_from_sidebar`	boolean	No	Hide space from sidebar navigation
`hide_right_sidebar`	boolean	No	Hide right sidebar in space
`require_topic_selection`	boolean	No	Require topic selection when posting
`display_view`	string	No	Default display view for the space Values: `posts`, `cards`, `list`, `thumbnail`, `feed`, `masonry`, `grid`, `calendar`.
`prevent_members_from_adding_others`	boolean	No	Prevent members from adding other members to the space
`hide_from_featured_areas`	boolean	No	Hide space from featured areas
`disable_member_post_covers`	boolean	No	Disable cover images on member posts
`hide_members_count`	boolean	No	Hide the member count display
`pinned_posts_label`	string	No	Custom label for pinned posts
`show_lock_icon_for_non_members`	boolean	No	Show lock icon for non-members
`hide_post_settings`	boolean	No	Hide post settings
`default_comment_sort`	string	No	Default sort order for comments Values: `oldest`, `latest`.
`default_member_sort`	string	No	Default sort order for members Values: `oldest`, `latest`, `alphabetical`.
`emoji`	string	No	Simple emoji string for the space
`default_tab`	string	No	Default tab to show when entering the space
`show_tab_bar`	boolean	No	Show the tab bar navigation
`show_next_event`	boolean	No	Show next event information for event spaces
`visible_tabs`	object	No	Visible tabs configuration for the space
`meta_tag_attributes`	object	No	SEO meta tag attributes

list_spaces

List Spaces. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-spaces --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`sort`	string	No	Sort by Values: `active`, `oldest`, `alphabetical`, `likes`, `latest_updated`, `oldest_updated`, `latest_profile_confirmed`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_space

Delete a space. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-space --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Space ID minimum: `1`.

get_space

Show a space. Reads community data.

circle-cli get-space --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Space ID minimum: `1`.

update_space

Update Space. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-space --help

Argument	Type	Required	Meaning and constraints
`space_id`	integer	Yes	Space ID minimum: `1`.
`name`	string	No	Name (body input).
`cover_image`	string	No	signed_id of the cover image
`cover_image_visible`	boolean	No	Cover image visible (body input).
`cover_image_display_style`	string	No	Cover image display style (body input). Values: `normal`, `wide`.
`is_private`	boolean	No	Is private (body input).
`is_hidden_from_non_members`	boolean	No	Is hidden from non members (body input).
`is_draft`	boolean	No	Only valid for course spaces; set to false to publish a course
`is_hidden`	boolean	No	Is hidden (body input).
`locked_button_url`	string	No	Locked button url (body input).
`locked_button_label`	string	No	Locked button label (body input).
`locked_page_heading`	string	No	Locked page heading (body input).
`locked_page_description`	string	No	Locked page description (body input).
`is_post_disabled`	boolean	No	Is post disabled (body input).
`default_sort`	string	No	Default sort (body input).
`hide_sorting`	boolean	No	Hide sorting (body input).
`space_group_id`	integer	No	Space group id (body input).
`topics`	array	No	Topics (body input). Array items: integer.
`custom_emoji`	object	No	Custom emoji (body input).
`event_auto_rsvp_enabled`	boolean	No	Only for event spaces
`default_in_app_notification_setting`	string	No	Members will see an in-app notification when new events are posted Values: `never`, `all`.
`default_mobile_notification_setting`	string	No	Members will see a mobile notification when new events are posted Values: `never`, `all`.
`default_notification_setting`	string	No	Members will receive an email notification when new events are posted Values: `never`, `all`.
`course_setting_attributes`	object	No	Course space configuration
`thumbnail_image`	string	No	signed_id of the thumbnail image for event spaces
`default_mention_in_app_notification_setting`	string	No	Members will see an in-app notification when mentioned Values: `never`, `all`.
`default_mention_mobile_notification_setting`	string	No	Members will see a mobile notification when mentioned Values: `never`, `all`.
`hide_from_sidebar`	boolean	No	Hide space from sidebar navigation
`hide_right_sidebar`	boolean	No	Hide right sidebar in space
`require_topic_selection`	boolean	No	Require topic selection when posting
`display_view`	string	No	Default display view for the space Values: `posts`, `cards`, `list`, `thumbnail`, `feed`, `masonry`, `grid`, `calendar`.
`prevent_members_from_adding_others`	boolean	No	Prevent members from adding other members to the space
`hide_from_featured_areas`	boolean	No	Hide space from featured areas
`disable_member_post_covers`	boolean	No	Disable cover images on member posts
`hide_members_count`	boolean	No	Hide the member count display
`pinned_posts_label`	string	No	Custom label for pinned posts
`show_lock_icon_for_non_members`	boolean	No	Show lock icon for non-members
`hide_post_settings`	boolean	No	Hide post settings
`default_comment_sort`	string	No	Default sort order for comments Values: `oldest`, `latest`.
`default_member_sort`	string	No	Default sort order for members Values: `oldest`, `latest`, `alphabetical`.
`emoji`	string	No	Simple emoji string for the space
`default_tab`	string	No	Default tab to show when entering the space
`show_tab_bar`	boolean	No	Show the tab bar navigation
`show_next_event`	boolean	No	Show next event information for event spaces
`visible_tabs`	object	No	Visible tabs configuration for the space
`meta_tag_attributes`	object	No	SEO meta tag attributes
`chat_room_show_history`	boolean	No	Show chat history to new members in chat spaces
`chat_room_description`	string	No	Description for the chat room in chat spaces

tag_member

Create Tagged Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli tag-member --help

Argument	Type	Required	Meaning and constraints
`member_tag_id`	integer	Body	Member tag id (body input).
`user_email`	string	Body	User email (body input).

untag_member

Delete Tagged Member. Changes community state and requires confirm=true for the user-requested action.

circle-cli untag-member --help

Argument	Type	Required	Meaning and constraints
`user_email`	string	Yes	User Email
`member_tag_id`	integer	Yes	Member Tag ID

list_tagged_members

List Tagged Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-tagged-members --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`member_tag_ids`	array	No	Filter by Member Tag IDs (OR logic, comma-separated) Array items: integer.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_tagged_member

Get Tagged Member. Reads community data.

circle-cli get-tagged-member --help

Argument	Type	Required	Meaning and constraints
`tagged_member_id`	string	Yes	Tagged Member ID

get_tax_settings

Get tax settings. Reads community data.

circle-cli get-tax-settings --help

Argument	Type	Required	Meaning and constraints
None	Not applicable	No	Shared account/confirmation controls only.

update_tax_settings

Update tax settings. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-tax-settings --help

Argument	Type	Required	Meaning and constraints
`tax_setting`	object	No	Tax setting (body input).

create_topic

Create a topic. Changes community state and requires confirm=true for the user-requested action.

circle-cli create-topic --help

Argument	Type	Required	Meaning and constraints
`name`	string	No	Name (body input).
`admin_only`	boolean	No	Toggles if only admins and moderators can select this topic
`space_ids`	array	No	Array of space IDs to be assigned to the topic Array items: integer.

list_topics

List topics. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-topics --help

Argument	Type	Required	Meaning and constraints
`page`	integer	No	Page number minimum: `1`.
`per_page`	integer	No	Number of records per page minimum: `1`. maximum: `100`.
`name`	string	No	query by name
`sort`	string	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest) Values: `oldest`, `newest`, `alphabetical`, `alphabetical_desc`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

delete_topic

Delete a topic. Changes community state and requires confirm=true for the user-requested action.

circle-cli delete-topic --help

Argument	Type	Required	Meaning and constraints
`topic_id`	integer	Yes	Topic ID minimum: `1`.

get_topic

Show topic details. Reads community data.

circle-cli get-topic --help

Argument	Type	Required	Meaning and constraints
`topic_id`	integer	Yes	Topic ID minimum: `1`.

update_topic

Update a topic. Changes community state and requires confirm=true for the user-requested action.

circle-cli update-topic --help

Argument	Type	Required	Meaning and constraints
`topic_id`	integer	Yes	Topic ID minimum: `1`.
`name`	string	No	Name (body input).
`admin_only`	boolean	No	Toggles if only admins and moderators can select this topic
`space_ids`	array	No	Array of space IDs to be assigned to the topic Array items: integer.

activate_workflow

Activate an automation (dynamic) workflow so it starts running automatically. Changes community state and requires confirm=true for the user-requested action.

circle-cli activate-workflow --help

Argument	Type	Required	Meaning and constraints
`id`	string	Yes	UUID of the workflow to activate format: `uuid`.

deactivate_workflow

Deactivate an automation (dynamic) workflow so it stops running automatically. Changes community state and requires confirm=true for the user-requested action.

circle-cli deactivate-workflow --help

Argument	Type	Required	Meaning and constraints
`id`	string	Yes	UUID of the workflow to deactivate format: `uuid`.

duplicate_workflow

Duplicate a workflow. Changes community state and requires confirm=true for the user-requested action.

circle-cli duplicate-workflow --help

Argument	Type	Required	Meaning and constraints
`id`	string	Yes	UUID of the workflow to duplicate

list_workflows

List a community's automations/workflows. Reads community data. Supports bounded all_pages; every page counts against the API quota.

circle-cli list-workflows --help

Argument	Type	Required	Meaning and constraints
`query`	string	No	Filter by workflow name (substring match).
`status`	string	No	Filter by status. Omit to include archived; use `all` to exclude archived; use `archived` for only archived. Values: `draft`, `active`, `inactive`, `archived`, `all`.
`workflow_type`	string	No	Filter by type: dynamic (Automation), bulk_action (Bulk action), scheduled (Scheduled). Values: `dynamic`, `bulk_action`, `scheduled`.
`page`	integer	No	Page number (min 1) minimum: `1`.
`per_page`	integer	No	Records per page (max 100) minimum: `1`. maximum: `100`.
`all_pages`	boolean	No	Bounded page retrieval; each page consumes quota.
`max_items`	integer	No	Max items (control input). minimum: `1`. maximum: `10000`. default: `1000`.

get_workflow

Get Workflow. Reads community data.

circle-cli get-workflow --help

Argument	Type	Required	Meaning and constraints
`id`	string	Yes	UUID of the workflow format: `uuid`.

list_accounts

Lists configured account labels, default choice and auth method without tokens, paths or network calls. No arguments.

9. Community workflows

Draft, inspect, then publish only when requested

Discover the intended basic space first. A basic post requires space_id and name; content uses tiptap_body and a nested Tiptap document rather than an invented plain body field. These illustrative IDs must be replaced with real discovered IDs:

circle-cli list-spaces --per-page 5 --agent
circle-cli create-post --space-id 7 --name "Community notes" --tiptap-body '{"body":{"type":"doc","content":[{"type":"paragraph","content":[{"type":"text","text":"Your actual post content."}]}]}}' --confirm --agent
circle-cli get-post --post-id 19 --agent

The wrapper defaults basic/image post creation to draft. Read that same post ID and inspect it in Circle. A later publishing/scheduling update needs the user's specific request and explicit status/confirmation. Review skip_notifications, timestamps and audience carefully. Do not overwrite a branded or complex document with a sample paragraph. See Tiptap concepts and rich text.

Members, invitations and messages

Search/read the intended member before access changes. create_member invites a member unless the supplied supported fields change that behavior; skip_invitation can suppress an invitation. Use documented member IDs, emails, access-group IDs and tags, not a user's password in a model prompt. remove_member deactivates a membership; delete_community_member is a distinct deletion operation. Read schemas before choosing one.

send_message uses rich_text_body and exactly one recipient route (user_email, user_emails or chat_room_uuid) per the pinned body union. Publishing, comments, messages, invitations, event reminders and workflow activation can contact people. Guard confirmation does not establish consent or successful delivery. Only perform the requested operation.

Events, courses and workflows

Events use a nested event object with event settings, location and reminder options, plus the operation's space input. Courses use current section/lesson IDs and documented bodies; progress updates have their own fields. Workflows use UUIDs, not the numeric IDs used by many other endpoints. Read and inspect the current workflow before confirmed activation. Deactivation, duplication and billing/subscription actions have different effects; tool availability never substitutes for the intended task.

10. Pagination, exports and uploads

Bounded pages

The 33 reviewed paginated reads use native page and per_page; no cursor is invented. all_pages starts at the requested page or page 1, keeps page size fixed, stops at max_items (default 1,000, maximum 10,000) or 100 requests, and refuses empty/repeated continuing pages. The local per_page cap is 100. Responses retain the provider's records/metadata and add collected/pages/truncated/resume.

circle-cli list-members --per-page 25 --agent
circle-cli list-members --all-pages --max-items 500 --per-page 25 --agent

When a cap cuts through a page, resume contains that page, the fixed per_page and the count to skip after retrieving it again. When a full page is consumed, resume points to the next page with skip 0. Preserve the same query/filter/sort and do not change page size: doing so changes offset boundaries. This is not a consistent snapshot; concurrent community changes can shift records. The helper returns continuation state but does not offer an invented --skip API argument. One bounded result is not a complete backup guarantee.

Exports and quota

Export tools are confirmed writes that may enqueue jobs or return download links; acceptance is not proof of completion. Preserve returned IDs/status and follow the documented account workflow. Keep membership/billing data and download URLs private. Every page/retry consumes allowance; a long Retry-After is surfaced instead of shortened into an early retry.

File metadata and direct uploads

create_direct_upload creates the documented upload metadata/slot using blob key, filename, MIME type, byte_size and a Base64 MD5 checksum. It does not read a local file or complete the storage PUT for you. Follow the upload protocol: create metadata, upload the exact intended file to the returned signed storage URL with its returned headers, then use the returned signed_id where the content schema accepts it. The provider concept page illustrates Member API; this package uses the pinned Admin v2 direct_uploads route.

Never send the Admin token to the storage URL, expose private signed URLs in public output, or treat a slot as a completed upload. Embeds/SGIDs, basic-post covers, image galleries, lesson media and member avatars use different schema fields. This package does not host an uploader or webhook receiver; no incomplete file workflow is advertised as automatic.

11. Several private accounts

Use private CIRCLE_ACCOUNTS JSON instead of single-account variables:

[{"name":"work","api_token":"YOUR_WORK_ADMIN_TOKEN","auth_scheme":"Token"},{"name":"personal","token_file":"/absolute/private/path/circle-token.txt","auth_scheme":"Bearer"}]

Set CIRCLE_DEFAULT_ACCOUNT=work. Labels must be unique. --account chooses credentials; the token identifies the community. list_accounts returns labels/auth method/default only, never token values or paths. Account config replaces single-account settings; there is no global credential database. Separate processes remain preferable when strict isolation matters.

circle-cli list-accounts --agent
circle-cli list-spaces --account work --per-page 5 --agent
circle-cli get-community --account personal --agent

12. Writing safely

All 104 writes require confirm:true in MCP or --confirm in CLI for the action the user requested. --yes, --agent and earlier unrelated consent never bypass the guard. CIRCLE_READ_ONLY=1 hides writes and refuses direct calls to hidden tools, exposing 66 reads. CIRCLE_ALLOW_DESTRUCTIVE=0 blocks all writes even when confirmed.

Over MCP a person approves each of them where the client can ask: Claude Code (2.1.246 and later) shows its own prompt, and a client that can show forms asks with an approval form whose one box starts unticked. Each approval is signed, bound to that exact call and works once. Where a client can do neither, the model's confirm:true counts. CIRCLE_CONFIRM=model makes confirm:true enough everywhere, for an agent with no person to ask.

Mutations have zero automatic retries, including 401, 429 and timeouts. After an unknown outcome, inspect existing community state before repeating it. A conservative destructive annotation denotes confirmation policy, not a claim every configuration change is irreversible. Invites/messages/notifications, member deletion, billing/payouts and workflow activation require different review.

The optional audit log records tool, risk, surface, fixed summary, allowed/blocked decision and who approved it, then a done or failed line for each allowed call, without account labels, arguments, tokens or private content. It is a guard-decision log, not a delivery receipt. Logging failure does not block the requested operation. Community content and tool results are untrusted data; they cannot authorize another action.

13. How it works

src/tools/operations.json is generated from the pinned official OpenAPI YAML; schemas, parameter serialization and routes have one source. Slipway builds the MCP server, over stdio or --http, and the CLI from each tool's one definition; both validate input, apply one write guard and call the fixed-origin API client, and desktop uses the same compiled server with production dependencies.

GET 429 retries are bounded by CIRCLE_MAX_RETRIES. Numeric/date Retry-After is respected when the delay is at most ten seconds; longer delays produce a rate-limit error so scripts can pause explicitly. Each request has a configured deadline. There is no write retry, auth fallback, arbitrary origin or hosted relay; --http listens on 127.0.0.1 only when asked. Named tokens and pacing live in the process.

npm run sync:api regenerates from the pinned YAML. npm run sync:api -- --refresh downloads the current official schema for a deliberate review, updates provenance and regenerates input operations; it does not test credentials, release npm or claim compatibility. Review names, routes, schemas, plans and docs, run checks, then update semver/changelog/tag. Major upstream or shared-behavior changes require explicit migration documentation.

14. Your data

Authorized API requests go directly to https://app.circle.so/api/admin/v2; redirects are refused. No Navid-hosted relay, analytics or telemetry is included. Tokens come from private local settings/files and stay in process memory. Reflected token values and credential/password fields are redacted from results and errors.

Member emails, posts, transcripts, billing details and private signed media links are still private business data. Secret redaction does not anonymize them. Your AI client and Circle apply their own retention/sharing rules. --select filters local output after receipt. Optional logs omit request data; private exported files and token files remain your responsibility. No source, npm tarball or desktop archive may include real credentials or private account instructions. Report vulnerabilities privately via SECURITY.md.

15. Environment variables

Private client/shell settings only; no automatic .env loading.

Variable	Default	Meaning
CIRCLE_API_TOKEN	Empty	Private Admin V2 token
CIRCLE_TOKEN_FILE	Empty	Regular token-only file up to 64 KB; takes precedence
CIRCLE_AUTH_SCHEME	Token	Explicit Token/Bearer scheme; no fallback
CIRCLE_ACCOUNTS	Empty	Private named credential array; replaces single account
CIRCLE_DEFAULT_ACCOUNT	First configured label	Default local account
CIRCLE_READ_ONLY	0	Hide/refuse all writes
CIRCLE_ALLOW_DESTRUCTIVE	1	0 blocks all writes
CIRCLE_AUDIT_LOG	None	Private guard-decision log
CIRCLE_REQUEST_TIMEOUT_MS	30000	Integer request deadline, 100–300000 ms
CIRCLE_MAX_RETRIES	2	GET 429 retries, 0–5
CIRCLE_MIN_REQUEST_INTERVAL_MS	200	Per-account/process pacing, 0–10000 ms
CIRCLE_CONFIRM	human	`model` lets confirm:true alone approve over MCP, for an agent with no person to ask
CIRCLE_SURFACE	full	`search` lists three tools that find, describe and run the rest
CIRCLE_TOOL_TIMEOUT_MS	None	Give up on any tool after this long
CIRCLE_HTTP_PORT, CIRCLE_HTTP_HOST, CIRCLE_HTTP_TOKEN	8787, 127.0.0.1, none	For `--http`; any host but 127.0.0.1 needs the bearer token
CIRCLE_HTTP_ALLOWED_ORIGINS	None	Comma-separated browser origins allowed to call `--http`; a page from any other site is refused
CIRCLE_DEBUG	0	1 prints debug lines on stderr

16. Updates and removal

npm install -g @thenavidm/circle-mcp-cli@latest
circle-cli --version
claude mcp remove --scope user circle
codex mcp remove circle
npm uninstall -g @thenavidm/circle-mcp-cli

Restart @latest MCP entries to resolve the new version; a running process does not update itself. Pin a reviewed version for reproducible automation. Read CHANGELOG.md and GitHub Releases before major updates. Manually installed desktop extensions need the new versioned .mcpb installed separately. No directory-driven automatic desktop update is claimed.

Remove each manual client entry and copied skill as appropriate. Uninstalling does not revoke tokens, delete community content, undo invitations or cancel workflows. Revoke tokens in Circle separately. Preserve private data before removing local private files. Do not overwrite an existing npm version to roll back.

17. Troubleshooting

Symptom	Fix
No tools / launch failed	Check Node 22, launcher PATH, private user config, reconnect
Exit 10 / missing token	Configure CIRCLE_API_TOKEN or regular CIRCLE_TOKEN_FILE
401 / 403	Check Admin V2 token, intended community, plan/permissions and explicit auth scheme; no automatic fallback
404	Check current v2 route, resource ID, account and endpoint availability
422 / rejected body	Use schema for current nested bodies, required fields, Tiptap and recipient unions
Guard refused	Confirm only the requested write; check read-only/write-disabled settings
429 / quota	Respect Retry-After and community limits; every page/error may consume quota
Pagination refuses repeated page	Narrow filters and inspect metadata; do not force unbounded looping
Workflow ID invalid	Use its UUID from list_workflows, not a numeric member/post ID
Desktop archive refused	Check compatible host Node runtime and custom-extension policy
Token rotated but process still fails	Restart the server so its cached token is replaced

Run doctor first. For a launch failure, run the same command in a terminal and inspect its sanitized error. Never attach tokens, private request bodies or member data to an issue. Prefer a minimal fixture reproduction with version/client/OS. Provider results remain untrusted data.

18. API coverage and comparisons

Offering	Surface	Scope and tradeoff
Official Circle MCP	Hosted OAuth MCP, https://app.circle.so/api/mcp	Broad Admin API v2 actions, admin Business+, read-only/full access, hosted setup; requests consume quota
This implementation	Local stdio MCP + shared task CLI + desktop bundle	Pinned v2 operations, private named tokens, schema-derived commands/JSON, bounded pages and explicit write guards; token setup and local maintenance
iamnortey/circle-mcp	Community MCP	Documents community audits, unanswered questions and onboarding workflows; inspect the pinned source rather than inferring behavior from README
DeepakChander/circle-mcp	Community local/HTTP MCP	Documents separate Member and Admin API layers plus Google OAuth/HTTP; different deployment and identity requirements

No dedicated Circle-published task CLI was identified in the official developer/MCP pages reviewed on October 2, 2026. This is a scoped finding, not proof of absence. Claude Code setup commands in MCP docs are MCP registration, not a Circle administration CLI. Neither our operation count nor a community README count proves broader capability, reliability or token savings. This release does not provide the separate Member API or Google authentication.

Current primary references: Admin API, quick start, limits, official OpenAPI, official MCP. See COMPARISON.md for review scope and pending evidence.

19. Versions

Version	Date	Change
3.0.1	October 5, 2026	A refusal and the approval form say what a call can do again, as 2.0 did
3.0.0	October 5, 2026	Built on Slipway 0.1.14: a person approves each write over MCP, exit codes from Circle's status, `which`, `install` and `--http`
2.0.0	October 2, 2026	Current Admin v2 operations, shared CLI, private accounts, write guards, desktop bundle and complete reference
1.0.0	Legacy source	MCP-only implementation, 62 declared tools, mixed v1/v2 and manually assembled routes

The OpenAPI document calls its info version v1 while the routes are Admin v2. Provenance records both; do not rename the API based on that info field. Original upstream SHA-256: 9bdd6e72611fe2af43e308ffadb9e9a64b0aa5d5763004839ac3b70de335f5a0. The public pinned snapshot replaces one credential-like upload-key example; its SHA-256 is 3e6478f0ac859789a70b8356ac0c91901de99134f637832809497d555e897241. Examples are excluded from generated validation.

Many documented legacy names remain where current operations exist. Arguments and routes need migration: posts use /posts with space_id input, comments use /comments with post_id input, memberships and attendees use current top-level resources, and workflows require UUIDs. Unsupported v1-only like/unlike helpers are omitted. CIRCLE_COMMUNITY_ID is no longer used. Legacy HTML/body shortcuts are not silently converted to Tiptap. See CHANGELOG.md for the exact legacy-name migration table. Preserve the existing AGPL license.

Build/typecheck, 36 tests and real local discovery are verified. These checks cover every write guard, nested body validation, pagination, auth header shape, retry policy, secret redaction and actual CLI exit codes. Public release/artifact/CI evidence is recorded after publication. Live provider outcomes and desktop GUI installation remain unverified; section 7 has the measured token costs.

20. FAQ

It exposes structured operations to an AI client. This package runs locally over stdio and connects directly to Circle.

circle-cli runs the same tools as shell commands through the shared MCP implementation. Scripts and shell agents can use it.

Yes. Its hosted OAuth MCP at https://app.circle.so/api/mcp provides broad Admin API v2 access for admins on eligible Business+ plans.

It adds a local task CLI, named private token settings, predictable JSON, schema-derived help and bounded page retrieval. No overall coverage or efficiency advantage is claimed.

No dedicated task CLI was found in the official developer/MCP pages reviewed on October 2, 2026. MCP setup through Claude Code is not a Circle task CLI; recheck current provider docs before making an absence claim.

The wrapper preserves AGPL-3.0-or-later. Circle plan access and API allowances remain separate. Installing npm does not upgrade a plan.

Open Settings > Developers > Tokens in the intended community as an admin. Create an Admin V2 token and save it privately.

No. Use private local shell/client settings or an owner-only regular token file outside repositories. Never put it in issues, chats or shared configs.

The pinned schema says Token; quick-start prose says Bearer. Token is the default, and an explicit private auth scheme setting supports Bearer. There is no automatic fallback or write resubmission; live-account validation remains pending.

No. It prints private token setup instructions without opening a browser or storing a credential. Official hosted MCP OAuth is a separate route.

The versioned .mcpb bundles production dependencies and uses a sensitive token setting or private token-file path. Host compatibility and organization custom-extension policy apply; GUI installation is separately unverified.

This package needs local stdio. A remote-URL-only client needs Circle’s official hosted MCP instead, subject to current client support.

Create basic/image post defaults to draft. Publishing or scheduling needs the specific requested status/update and confirmation. Inspect the same post before changing delivery or notification options.

The current operations support those requests, with explicit confirmation and valid account permissions. Read recipient/body schemas and review notification behavior; tool availability is not consent or proof of delivery.

No. Mutating requests have zero automatic retries or auth fallback. Inspect state after unknown outcomes before repeating any action.

all_pages is available only on the 33 native page/per_page reads, bounded by max_items and 100 requests. Every page consumes quota; continuation state does not guarantee a consistent snapshot.

The cap stopped partway through a page. Retrieve that same page with the same per_page/filter/sort and skip that many already-returned records locally. There is no invented skip API argument.

Use named private credentials and --account. The selected token identifies its community. list_accounts returns labels and auth method without tokens or paths.

No. It creates the metadata/slot. Complete the documented storage PUT for the exact intended file, then use its signed_id; never forward the Admin token to storage.

It depends on the client and the task. In Claude Code the CLI costs nothing until it is used, plus about 940 tokens for SKILL.md once, where the server costs about 2,500 tokens a message with tool search and 84,400 with every tool loaded. In Codex, finding the command that refunds a member's charge took a median of 82,915 input tokens over the CLI and 77,488 over MCP. Section 7 has how each was measured.

Questions

Open a sanitized issue with version/client/OS. Use SECURITY.md for private disclosure.

About the author

Navid Moazzez is a leading AI business strategist, and the host of the AI Creator Summit, watched by 100,000+ creators. He helps creators and founders master AI and build their own AI Operating System (AI OS) to automate their business and life. He creates useful free tools, MCP servers and CLIs that creators and founders can use in their own workflows.

Links

Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm

Dependencies

Dependency	Version range	Used for
`@thenavidm/slipway`	`^0.1.17`	The MCP server and the CLI from one definition of each tool, with the MCP TypeScript SDK
`ajv`	`^8.17.1`	JSON Schema input validation
`ajv-formats`	`^3.0.1`	JSON Schema input validation

Full third-party attribution is in THIRD_PARTY_NOTICES.md. Development tooling and its audit limitations are documented in SECURITY.md.

yaml is development-only API regeneration tooling. It is excluded from production bundles.

License

AGPL-3.0-or-later, preserving the existing license. See LICENSE, full AGPL text and THIRD_PARTY_NOTICES.md. Circle service/documentation terms remain separate.

Available Tools

170 tools

activate_workflowActivate an automation (dynamic) workflow so it starts running automaticallyA

Destructive

Activate an automation (dynamic) workflow so it starts running automatically. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	UUID of the workflow to activate
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered structurally. The description adds genuinely new context: it changes community state and mandates confirm=true before proceeding. It stops short of describing reversibility or post-activation effects.

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?

Two tight sentences with the action and outcome front-loaded and no filler. The confirm caveat is appended efficiently, though it slightly duplicates the title text.

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 non-idempotent mutation with no output schema, the description covers the core action and confirm gate but omits what activation entails (reversibility, side effects on community state, what 'dynamic' implies). Annotations carry the safety profile, so this is adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents id, account, and confirm. The description reiterates the confirm requirement but adds no syntax or format detail beyond what the schema provides, matching the baseline of 3.

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?

Specific verb (activate) plus resource (automation/dynamic workflow) with a clear outcome clause ('so it starts running automatically'). However, it never names its obvious counter-tool deactivate_workflow, so differentiation from siblings relies on inference rather than explicit contrast.

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

Usage Guidelines3/5

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

It gives one concrete gating condition ('requires confirm=true for the user-requested action'), which is useful usage context. But there is no explicit when-to-use vs deactivate/duplicate/list guidance or statement of prerequisites beyond confirm, so usage is only implied.

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

add_space_memberAdd Space MemberC

Destructive

Add Space Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`space_id`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description contributes one genuinely useful behavioral fact beyond that: the confirm=true gating requirement for user-requested actions. It does not say what state is destroyed or whether the change is reversible.

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

Conciseness3/5

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

Two short sentences, and the more informative confirmation requirement is placed second rather than front-loaded. The opening sentence is pure redundancy with the title, so the text is neither wasteful enough to score 2 nor efficient enough to score 4.

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

Completeness2/5

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

This is a destructive mutation with six parameters, a nested payload object, no output schema, and no required fields. The description covers only the confirmation gate, omitting the payload/file exclusivity rule and the account credential-selection semantics — a significant shortfall for a tool of this complexity.

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 coverage is a middling 67%, and the description only speaks to one of six parameters (confirm). It says nothing about the mutually exclusive body-shaping options (payload vs. payload_file vs. body flags) or the email/space_id pair inside payload, all of which the description could have clarified.

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

Purpose2/5

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

The first sentence, "Add Space Member," is a verbatim restatement of the title, which the rubric treats as tautology. The only added signal is the vague "Changes community state," which does not specify what resource is being modified or how this differs from siblings like create_space_group_member or remove_space_member.

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

Usage Guidelines2/5

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

The description states a confirmation gate ("requires confirm=true for the user-requested action") but gives no when-to-use vs alternatives guidance and no prerequisites. Sibling tools such as remove_space_member and get_space_member are not referenced, leaving the agent to infer selection from the name alone.

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

add_to_access_groupAdd Member to Access GroupA

Destructive

Add Member to Access Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`access_group_id`	Yes

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructive=true, readOnly=false, and idempotent=false, so the safety burden is partly lifted. The description still adds useful context beyond that: it mutates community state and requires an explicit confirm flag, which is the kind of gating detail annotations cannot express.

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?

Two short sentences, no waste, with the mutation warning and the confirm prerequisite front-loaded. Nothing redundant with the title.

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 six-parameter destructive tool with nested objects and no output schema, the description is thin: it omits the payload/payload_file mutual exclusion, the identify-by-email expectation, and what a successful add returns or whether it is reversible. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 67%, and the schema itself explains confirm, payload, payload_file, and account semantics. The description only echoes the confirm requirement and says nothing about access_group_id (undocumented in the schema) or the id/email binding, so it adds little beyond structured fields.

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?

States a specific verb (Add) and resource (Member to Access Group), which is clearly distinguishable from siblings like remove_from_access_group and create_access_group. It does not, however, explicitly name those alternatives to sharpen the distinction.

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

Usage Guidelines3/5

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

The description supplies one real usage rule — confirm=true is required for the user-requested action — which implies a gated-write workflow. It gives no guidance on when to prefer this over create_access_group, add_space_member, or other membership tools.

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

archive_access_groupArchive Access GroupB

Destructive

Archive Access Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`access_group_id`	Yes	Access Group ID

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds a useful behavioral fact ('Changes community state') and the confirm gating requirement, but says nothing about reversibility, side effects on members, or required permissions.

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?

Two short, front-loaded sentences with no padding. The second sentence is slightly generic boilerplate ('the user-requested action'), but the definition is appropriately sized.

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 destructive, non-idempotent mutation with no output schema, the snippet is minimally adequate: the agent knows to pass confirm=true. It omits reversibility, effects on access group members, and any prerequisite context, so it is complete only at the bare minimum.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, and access_group_id. The description restates the confirm=true requirement, which is a mild reinforcement but adds no semantics beyond what the schema provides; baseline 3 applies.

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 names a specific verb and resource ('Archive Access Group'), so the agent knows exactly what operation is performed. It does not differentiate from close siblings like unarchive_access_group, update_access_group, or delete-like operations, but the core purpose 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 Guidelines2/5

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

The only usage guidance is the confirm=true requirement tied to 'the user-requested action,' which is really a precondition rather than a when-to-use statement. There is no mention of when to archive versus unarchive or update a group, leaving the agent to infer the choice from the tool name alone.

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

archive_paywallArchives a paywallA

Destructive

Archives a paywall. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`paywall_id`	Yes	Paywall ID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the confirmation gate and notes it "changes community state," but does not say whether the action is reversible (unarchive_paywall exists) or what specifically is affected, so the added value is modest.

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?

Two short sentences with the core action front-loaded and no padding. The phrase "changes community state" is slightly vague filler relative to the concrete confirm requirement that follows, but overall it is tight.

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 a destructive, non-idempotent mutation with full annotation coverage, full schema coverage, and no output schema, the description covers the key operational requirement (explicit confirmation). It omits reversibility and any mention of the archive/unarchive pairing, which would have made it complete.

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

Parameters3/5

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

Schema description coverage is 100%, including a clear definition for confirm and the note that account selects credentials rather than a community ID. The description merely restates the confirm=true requirement, adding no syntax or meaning beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ("Archives a paywall"), which is unambiguous on its own. However, it does not distinguish this from close siblings such as unarchive_paywall, delete_paywall, or publish_paywall, so the agent must infer the boundary from names alone.

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

Usage Guidelines3/5

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

"Requires confirm=true for the user-requested action" implies the tool should only be invoked when the user explicitly asked to archive, which is useful implied guidance. It never names an alternative (unarchive_paywall, delete_paywall) or states exclusions, so the when-to-use versus sibling logic is left to inference.

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

archive_profile_fieldArchive Profile FieldC

Destructive

Archive Profile Field. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`profile_field_id`	Yes	Profile field ID

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the confirm=true requirement, a genuine behavioral constraint not in the annotations, but adds little else about reversibility or what 'changes community state' entails.

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

Conciseness3/5

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

Two short sentences, appropriately sized and front-loaded, but the opening sentence is pure title repetition and earns no place. The confirm hint is useful; the rest is filler.

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 destructive mutation with full annotation coverage and no output schema, the description gives the essential confirm precondition. However, it never states what archiving actually does to the field or whether it is reversible, leaving an agent to infer the effect from the name alone.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (account, confirm, profile_field_id) are already documented in the schema. The description's mention of confirm=true merely duplicates the schema's own description rather than adding new meaning.

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

Purpose2/5

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

The first sentence is the tool title restated verbatim ('Archive Profile Field'), which is tautological. It does not explain what archiving a profile field means (e.g., hides it from the profile while preserving data) nor distinguish it from siblings like delete_profile_field or unarchive_profile_field.

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

Usage Guidelines2/5

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

The only guidance is the confirm=true precondition for 'the user-requested action.' There is no when-to-use/when-not, no mention of the delete or unarchive alternatives among the siblings, and no prerequisites such as permissions.

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

ban_community_memberBan Community MemberC

Destructive

Ban Community Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`member_id`	Yes	Community member ID to ban

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is conveyed structurally. The description adds a confirm gate requirement, but it merely echoes the schema wording and says nothing about irreversibility, side effects (e.g., access removal), or permissions.

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?

Two short sentences, no filler, and the state-changing nature is front-loaded. It is efficient, though the brevity borders on under-specification for a destructive tool.

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

Completeness2/5

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

For a destructive, non-idempotent, open-world mutation with no output schema, the description omits the consequences of banning, whether it is reversible, and what distinguishes it from remove_member/delete_community_member. An agent has to guess at the blast radius before invoking it.

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

Parameters3/5

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

Schema description coverage is 100% and all three parameters (account, confirm, member_id) are documented in the schema itself. The description adds no syntax, format, or constraint detail beyond what the schema already provides, so the baseline of 3 applies.

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

Purpose3/5

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

"Ban Community Member" is essentially a restatement of the tool name/title, and the added clause "Changes community state" is vague. The verb+resource is inferable from the name, but the description does nothing to distinguish this from close siblings like remove_member or delete_community_member.

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

Usage Guidelines2/5

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

The only guidance is the confirm=true precondition, which is really a parameter rule rather than a when-to-use statement. There is no indication of when to ban versus removing or deleting a member, nor any prerequisite or scope conditions.

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

cancel_community_member_subscriptionCancel Community Member SubscriptionB

Destructive

Cancel Community Member Subscription. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`ends_at`	No	Cancellation timing: 'now' or 'at_period_end'.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`refund_type`	No	Optional refund type when canceling immediately: 'prorated' or 'full'.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`subscription_id`	Yes	Community Member Subscription ID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is known. The description adds that it 'changes community state' and imposes a confirm gate, but says nothing about reversibility, whether cancellation is immediate vs period-end, or refund implications.

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?

Two short sentences, front-loaded with the action and followed by the key constraint. The first sentence restates the title, which is mildly redundant but not wasteful.

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 destructive mutation with no output schema, the description covers the confirm gate but omits the meaningful behavioral choices (ends_at 'now' vs 'at_period_end', refund_type) that the schema documents. Adequate but leaves the agent to rely entirely on structured fields for operational nuance.

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

Parameters3/5

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

Schema description coverage is 100% and all seven parameters (including nested payload and payload_file) are documented in the schema. The description only echoes the confirm requirement, adding no meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb (Cancel) and resource (Community Member Subscription) that an agent can distinguish from the sibling resume_community_member_subscription. Clear, though it does not explicitly name the counterpart operation.

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

Usage Guidelines3/5

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

Provides a precondition ('requires confirm=true for the user-requested action') which implies usage, but gives no explicit when-to-use vs when-not, nor does it point to resume_community_member_subscription as the alternative.

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

create_access_groupCreate Access GroupB

Destructive

Create Access Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`access_group`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description still adds a genuine precondition not carried by the annotations: the call mutates community state and requires confirm=true before it will act on a user-requested action. It does not explain what side effects occur on related groups or members, which keeps it short of a 5.

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?

Two short sentences with no filler, and the state-changing/confirm requirement is front-loaded. The first sentence is pure restatement of the title, which is the only wasted space.

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

Completeness2/5

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

This is a destructive, non-idempotent, open-world mutation with five parameters, nested objects, no required fields and no output schema, yet the description omits the create-vs-attach distinction, the payload/payload_file exclusivity, and any sense of what is produced. The schema carries most of the burden, but the description is too thin for a tool of this complexity.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents account, confirm, payload, access_group and payload_file. The description adds nothing beyond confirming the confirm=true gate, and does not address the mutual exclusion between payload_file and payload/body flags. Baseline 3 applies.

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

Purpose3/5

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

The first sentence, 'Create Access Group', states an unambiguous verb+resource, but it is a verbatim restatement of the tool title and name, so it adds no information. It also gives no differentiation from close siblings such as add_to_access_group, update_access_group, or archive_access_group, which an agent must distinguish between.

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

Usage Guidelines2/5

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

The only usage cue is 'for the user-requested action' attached to confirm=true, which gestures at a precondition but never states when to choose this tool over add_to_access_group or create_space_group. No alternatives, no exclusions, no prerequisites beyond the confirm flag.

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

create_commentCreate CommentC

Destructive

Create Comment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`body`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`post_id`	No
`created_at`	No
`updated_at`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`parent_comment_id`	No
`skip_notifications`	No

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so 'Changes community state' largely restates them. The one genuinely new behavioral fact is that confirm=true is required, which goes beyond the annotations and helps the agent avoid a failed call, but effects like notification side effects (skip_notifications) and non-idempotency are left unexplained.

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

Conciseness3/5

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

Two short sentences, front-loaded, so it is not bloated. However, the first sentence duplicates the tool name/title and earns no place, while the second crams a guardrail into a single clause.

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

Completeness2/5

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

For a mutation tool with 10 zero-required parameters, nested payload structure, and no output schema, the description is far too thin. It omits which inputs are actually needed (post_id within payload), how to disable notifications, and what happens on success, leaving the agent to reconstruct behavior from the schema alone.

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?

With 10 parameters and only 40% schema description coverage, the description is expected to compensate and does not. It only gestures at the confirm flag and never clarifies the mutually exclusive input shapes (body flags vs payload vs payload_file) or the required post_id inside payload, all of which live only in the schema.

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

Purpose3/5

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

The description gives a specific verb and resource ('Create Comment'), but the first sentence merely restates the tool name and title, adding no scope detail. It does not distinguish this from siblings like delete_comment, get_comment, or list_comments, nor does it say where the comment lands (post_id vs parent_comment_id).

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

Usage Guidelines3/5

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

It implies the tool should only be invoked when the user explicitly asked for this action and adds a conditional ('requires confirm=true for the user-requested action'). That is real usage guidance, but it names no alternatives or preconditions for creating a top-level comment vs a reply, and no when-not-to-use cases.

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

create_community_segmentCreate a community segmentC

Destructive

Create a community segment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`rules`	No
`title`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`visible`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_segment_consumer_attributes`	No

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is largely covered. The description adds the mutation ('Changes community state') and the confirm=true gate, which is useful context, but does not explain what is destroyed, auth requirements, or side effects, and confirm is also documented in the schema.

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?

Two short sentences with the core action front-loaded and no filler. The terseness is efficient, though it borders on under-specification for a tool this complex.

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

Completeness2/5

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

For a destructive, non-idempotent mutation with 8 parameters, nested objects, multiple request-body input modes (payload vs. flags vs. payload_file), and no output schema, the description omits nearly all operational detail. An agent would need to reverse-engineer the body-mode alternatives and rules structure from the schema alone.

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?

With 8 parameters (including nested rules and payload objects) at 50% schema coverage, the description needed to compensate but instead mentions no parameters. The only referenced behavior (confirm=true) is already fully described in the schema, so the description adds nothing to parameter understanding.

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 first sentence states a precise verb and resource ('Create a community segment'), so an agent knows exactly what operation this performs. However, it is a near-verbatim restatement of the title and gives no differentiation from siblings like create vs. update_community_segment, duplicate_community_segment, or delete_community_segment.

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

Usage Guidelines2/5

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

The only usage-like hint is that confirm=true is required for the 'user-requested action', but there is no guidance on when to choose this tool over its close siblings (update/duplicate/delete_community_segment) and no stated preconditions or exclusions.

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

create_contact_noteCreate Contact NoteA

Destructive

Create Contact Note. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`contact_id`	Yes	Contact ID or sqid
`tiptap_body`	No	Rich text note in Tiptap document format
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructive=true, readOnly=false, openWorld=true and non-idempotent, so the safety profile is covered. The description adds useful context beyond that: it explicitly states the tool changes community state and gates execution behind confirm=true, which is a behavioral requirement not present in the annotations.

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?

Two short sentences, front-loaded with the action and then the gating rule. No filler, though the first sentence largely duplicates the title.

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?

With full schema coverage, complete annotations, and no output schema, the definition is nearly self-sufficient; the confirm requirement is the key extra behavioral note. It stops short of describing side effects or return behavior, but nothing critical to correct invocation is missing.

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

Parameters3/5

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

Schema description coverage is 100% and each parameter (account, confirm, payload, contact_id, tiptap_body, payload_file) is self-documented. The description references confirm only implicitly; the baseline of 3 is appropriate when the schema carries the parameter burden.

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?

States a clear verb+resource (create a contact note), which an agent can distinguish from the list_contact_notes read sibling. The first sentence is a near-restatement of the name, adding little beyond the title, but the purpose itself 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 Guidelines3/5

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

The description supplies one concrete precondition (confirm=true for the user-requested action), which is real guidance. However, it offers no when-to-use vs. alternatives reasoning, no prerequisites, and no exclusions relative to other note/post creation tools.

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

create_course_lessonCreate a course lessonC

Destructive

Create a course lesson. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`status`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`body_html`	No
`thumbnail`	No	signed_id of the lesson thumbnail image returned from the direct upload endpoint
`section_id`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`featured_media`	No	signed_id of the lesson featured media file returned from the direct upload endpoint
`rich_text_body`	No
`is_comments_enabled`	No
`is_featured_media_enabled`	No
`is_featured_media_download_enabled`	No

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. "Changes community state" largely restates that, but the confirm=true requirement is genuine behavioral context not present in the annotations, which earns some credit.

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?

Two tight sentences with the core action front-loaded and no filler. Efficient, though the second sentence mixes state-change and confirm semantics compactly rather than organizing them.

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

Completeness2/5

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

For a 14-parameter, 0-required, nested-object mutation tool with no output schema, the description is far too thin. It omits the payload vs body-flags vs payload_file exclusivity, section_id requirement, and draft/published status semantics that an agent needs to invoke it correctly.

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 43% across 14 parameters (payload nesting, rich_text_body, section_id, thumbnail, featured_media, body flags all undocumented), so the description is expected to compensate. Instead it mentions only confirm, leaving the bulk of parameters unexplained beyond the 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?

States a clear verb+resource ("Create a course lesson") that an agent can distinguish from update_course_lesson and delete_course_lesson by verb alone. However, it offers no sibling differentiation beyond the obvious verb, so it does not reach a 5.

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

Usage Guidelines2/5

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

The description never says when to use this versus update_course_lesson, create_course_section, or other creation siblings, nor any prerequisites. The only usage-adjacent note (confirm=true for the user-requested action) is a parameter rule rather than tool-selection guidance.

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

create_course_sectionCreate a course sectionB

Destructive

Create a course section. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`space_id`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency. The description adds a genuinely useful behavioral detail beyond them: that the call changes community state and requires confirm=true, which signals a safety gate. It still omits what specifically gets created/modified and any auth or side-effect scope.

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?

Two compact sentences, front-loaded with the core action followed by the state-change/confirm constraint. No filler, though it is arguably terse for a six-parameter mutation tool.

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 six-parameter mutation with a nested payload object and no output schema, the description covers the confirm gate but says nothing about the payload vs. payload_file vs. body-flag alternatives or required fields. It is minimally adequate but leaves meaningful gaps an agent must resolve from the schema.

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

Parameters3/5

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

Schema description coverage is 67%, above the 50% baseline, and the schema already explains account, confirm, payload, and payload_file. The description reinforces the confirm semantics ('requires confirm=true') but adds nothing for space_id, name, or how payload relates to the body flags, so it stays at the baseline.

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 ('Create a course section'), which is clear. However, it does not differentiate from close siblings such as create_course_lesson, update_course_section, or create_space, so the agent gets no help choosing among course-creating tools.

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

Usage Guidelines3/5

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

It implies a usage condition by tying the action to a user-requested action and requiring confirm=true, which gives a gating rule. But there is no explicit when-to-use versus siblings and no exclusions, so guidance is only implied.

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

create_direct_uploadCreate Direct UploadC

Destructive

Create Direct Upload. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`blob`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true and idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful fact not in the annotations: that confirm=true is required. It does not explain what state is changed, what is destroyed, or what credentials/response come back.

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

Conciseness3/5

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

Only two short sentences, so there is no bloat, but the first sentence is pure name restatement and earns nothing. It is terse rather than efficiently informative.

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

Completeness2/5

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

This is a 5-parameter mutation tool with nested objects (blob inside payload), no output schema, and 0 required params, so the description carries real explanatory burden. It says nothing about the blob/payload selection logic, the account credential scoping, the 5 MB payload_file limit, or what the caller receives back.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already documents blob, account, confirm, payload and payload_file. The description contributes nothing beyond echoing confirm, so baseline 3 is appropriate.

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

Purpose2/5

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

The first sentence is a verbatim restatement of the tool name ('Create Direct Upload'), which is a tautology. It never says what a 'direct upload' actually is or what object it creates (e.g., a blob/upload target), so an agent cannot distinguish this from siblings like create_image_post or create_post without opening the schema.

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

Usage Guidelines2/5

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

The description only says the tool 'changes community state' and that confirm must be true 'for the user-requested action' — a restatement of the confirm parameter's own schema text. It gives no when-to-use condition, no prerequisites (e.g., account selection), and names no alternatives among the many create_* siblings.

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

create_embedCreate EmbedC

Destructive

Create Embed. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`url`	No	The URL to embed (e.g., YouTube, Vimeo, etc.)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the mutation safety profile is covered. The description adds only that it changes community state and that confirm=true is required, but it does not say what specifically is altered or what a failed/partial call leaves behind. With annotations carrying the safety burden, this is adequate but thin.

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?

Two short sentences, front-loaded with the core fact and the confirm gate, with no padding. It is efficient, though the first sentence is largely redundant with the title.

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

Completeness2/5

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

For a destructive, non-idempotent creation tool with a nested payload object and three mutually exclusive body-input modes (flags, payload, payload_file), the description explains none of the mode relationships or mutation scope. No output schema exists, but the description still leaves the agent without enough context to invoke it confidently.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents url, account, confirm, payload, and payload_file. The description adds no syntax or format detail beyond the schema, so the baseline 3 applies.

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

Purpose2/5

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

"Create Embed" merely restates the tool name and title, adding only that it "changes community state." It does not distinguish the tool from siblings like get_embed, create_post, or create_image_post, nor does it specify what an embed is in this context (a content block? a URL attachment?).

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

Usage Guidelines2/5

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

The only usage signal is the confirm=true prerequisite for "the user-requested action." There is no guidance on when to use create_embed versus get_embed, create_post, or other content-creation siblings, and no exclusions or preconditions beyond the confirm gate.

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

create_eventCreate EventC

Destructive

Create Event. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`event`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`space_id`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the safety profile is covered. The description does add the valuable non-obvious constraint that confirm=true is required for the action, but it discloses nothing about what state changes, side effects, or notification emails the creation triggers for such a complex nested payload.

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?

Two short sentences with no filler, and the state-change/confirm warning is front-loaded. It is efficiently structured, though arguably terse given the tool's complexity rather than verbose.

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

Completeness2/5

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

This is a highly complex write tool with six top-level parameters, deeply nested objects (event settings, live room, recurring settings), no output schema, and no required params. Such a sparse two-sentence description leaves an agent without enough context to invoke it correctly.

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

Parameters3/5

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

Schema description coverage is 67%, above the 50% threshold, so the structured schema carries most parameter meaning. The description's only parameter-related content (confirm=true) duplicates the confirm field's own schema description, adding no new syntax or format detail for the many nested event attributes.

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

Purpose2/5

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

"Create Event" simply restates the tool name/title with no additional scope. It does not distinguish this tool from close siblings such as create_event_attendee, duplicate_event, or update_event, so an agent gains little beyond the name itself.

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

Usage Guidelines2/5

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

The only guidance offered is "requires confirm=true for the user-requested action," which is a call precondition, not a when-to-use statement. There is no mention of when to pick create_event over duplicate_event or update_event.

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

create_event_attendeeCreate Event AttendeeC

Destructive

Create Event Attendee. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`event_id`	No	Event ID
`member_email`	No	Member Email
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the mutation profile is covered. The description does add a genuinely new behavioral fact beyond annotations — the mandatory confirm=true gate and the notion that it 'changes community state' — but adds nothing about permissions, reversibility, or failure modes.

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?

Two short, front-loaded sentences with no padding. It is efficient, though the first sentence spends its space restating the name rather than conveying new information.

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?

With a rich 100%-covered schema and annotations that carry the safety profile, the description is minimally adequate, and no output schema means return values need not be explained. However, for a destructive mutation with a confirm gate, it leaves the semantics of the action and the 'user-requested action' phrasing unclear.

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

Parameters3/5

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

Schema description coverage is 100%, so all six parameters are documented structurally and the baseline is 3. The description only reinforces the confirm flag's meaning ('only when the user asked for exactly this action'), adding marginal value over the schema's own text.

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

Purpose2/5

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

The first sentence, "Create Event Attendee," is a verbatim restatement of the tool name and title, so it adds no information about what creating an attendee entails (inviting a member to an event?). The second sentence shifts to behavior rather than purpose, leaving the tool's actual effect underspecified.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus siblings such as create_event, update_event, delete_event_attendee, or list_event_attendees. The only usage-adjacent statement, "requires confirm=true for the user-requested action," is a gating rule, not a when-to-use/alternative comparison.

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

create_filter_controlCreate a member filter controlB

Destructive

Create a member filter control. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`key`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`enabled`	No	Whether to show the filter
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`sort_key`	No	Optional ordering position; lower values sort first
`space_id`	No	Member space ID; omit for the member directory
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`profile_field_id`	No	Profile field ID; allowed only when key is profile_field

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotence, so the safety envelope is covered. The description adds real value beyond that by disclosing that the call changes community state and that confirm=true is a hard gate tied to explicit user intent, which is not derivable from the annotations alone.

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?

Two short sentences, no padding, with the core action front-loaded before the safety constraint. The phrasing 'requires confirm=true for the user-requested action' is slightly circular but compact.

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 9-parameter mutation tool with a nested payload object and no output schema, the description is thin: it never explains what a filter control is, what happens on success, or how the account/space/global key choices interact. Annotations carry the safety profile and the schema carries parameter detail, so it is minimally viable but leaves conceptual gaps.

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

Parameters3/5

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

Schema description coverage is 89%, so the schema already documents all 9 parameters including the payload/body-flag mutual exclusion and the profile_field/profile_field_id dependency. The description adds nothing about parameters beyond restating the confirm requirement, so the baseline 3 is appropriate.

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 ('Create') and resource ('member filter control'), matching the title closely. It does not explicitly distinguish itself from the sibling update_filter_control or delete_filter_control, but 'Create' is unambiguous against them.

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

Usage Guidelines2/5

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

The only usage condition given is that confirm=true is required 'for the user-requested action'. There is no guidance on when to create a filter control versus updating an existing one, nor any reference to the sibling tools that would route the agent correctly.

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

create_form_submissionCreate a form submissionA

Destructive

Create a form submission. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	Form ID
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`elements`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`submission_on_behalf_of`	No	Email of the contact on behalf of which the submission is being created

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds a real behavioral detail beyond that: the operation mutates community state and is gated behind an explicit confirm=true flag tied to the user's request, which changes how an agent must behave before calling.

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?

Two short sentences with no filler, and the state-mutation warning plus the confirm requirement are front-loaded. Every clause earns its place.

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 7-parameter, nested-object mutation tool with no output schema, the description is minimally adequate. It omits the mutually exclusive body options (payload vs payload_file vs individual flags) and what the tool returns, which the agent must reconstruct entirely from the schema.

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

Parameters3/5

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

Schema description coverage is 86%, so parameter meaning is mostly carried by the schema, and the 3 baseline applies. The description only reinforces the 'confirm' semantics; it says nothing about the interplay between 'payload', 'payload_file' and 'elements' or the 'submission_on_behalf_of' behavior.

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 and resource ('Create a form submission'), which is unambiguous and clearly distinct from the read-oriented sibling 'get_form_submissions'. However, it is essentially a restatement of the tool name/title and adds no differentiating scope or detail about what kind of form or community is targeted.

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

Usage Guidelines3/5

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

It gives one concrete precondition — confirm=true must be set for the user-requested action — which is genuine usage guidance. But it offers no when-not conditions, no exclusions, and does not point to 'get_form_submissions' or 'update_form' as alternatives, so the agent must infer the rest.

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

create_image_postCreate Image PostC

Destructive

Create Image Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`slug`	No
`status`	No
`topics`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`user_id`	No	id of the author
`space_id`	Yes	Image space ID
`is_pinned`	No	whether the post should be pinned to the top
`user_email`	No	email of the author (preferred over user_id)
`tiptap_body`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`is_liking_enabled`	No
`gallery_attributes`	No
`is_comments_enabled`	No

TDQS

C2.3/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered structurally. The description adds the confirm=true gating requirement and that community state changes, which is genuine extra context, but it stops short of saying what is created/destroyed or what permissions are needed.

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

Conciseness3/5

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

The description is short and front-loads the behavioral note, but the first sentence is a wasted restatement of the title. It is not padded, yet one of its two sentences does not earn its place.

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

Completeness2/5

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

For a 15-parameter destructive mutation tool with nested objects, 53% schema coverage, and no output schema, the description is far too thin. It omits the confirm semantics details, parameter interactions, and any indication of success/failure behavior that an agent would need.

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?

The description explains none of the 15 parameters, including the required space_id, the status enum, the account selector, or the mutually exclusive payload/payload_file/body-flag options. With schema description coverage at only 53% and heavy nesting, the description should compensate but adds nothing about parameter meaning.

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

Purpose2/5

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

The description's first sentence, 'Create Image Post', is a verbatim restatement of the title, making it tautological. It names no scope, no distinguishing feature versus siblings like create_post, create_embed, or duplicate_image_post, so an agent gains nothing beyond what the title already says.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. With many sibling creation tools (create_post, create_event, create_embed, duplicate_image_post), the description never explains what selects this tool over them. The confirm=true remark concerns invocation hygiene, not tool selection.

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

create_invitationCreate invitation linkA

Destructive

Create invitation link. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name for the invitation link
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`paywall`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_tag_ids`	No	Member tag IDs to apply when the link is used
`access_group_ids`	No	Access group IDs to attach. Presence, including an empty array, selects access-group mode
`redirect_space_id`	No	ID of the space to open after signup

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds value beyond that by disclosing the confirm=true gating requirement and that community state changes, which are operational details the annotations do not express.

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?

Two short sentences with the purpose front-loaded and no filler. It is efficient, though it stops short of adding the operational detail a 9-parameter nested mutation tool would benefit from.

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 mutating tool with 9 parameters, nested objects and multiple mutually exclusive body-input modes (payload, payload_file, body flags), the description is thin. It covers the confirm gate but says nothing about the body-mode selection constraints documented only in the schema, and there is no output schema to compensate.

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

Parameters3/5

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

Schema description coverage is 89%, so the schema already documents name, account, confirm, payload and the paywall/nested fields thoroughly. The description's only parameter-related content (confirm=true) duplicates the schema's own confirm description, so it adds little beyond the structured data. Baseline 3 applies.

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 ("Create invitation link"), making it distinguishable from siblings like update_invitation_link, revoke_invitation_link and list_invitations. It does not, however, explicitly name an alternative or scope constraint for differentiation.

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

Usage Guidelines3/5

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

It gives one operational condition (confirm=true must be set when the user asked for exactly this action), which implies when the tool is appropriate. But there is no guidance on when to prefer this over update_invitation_link or revoke_invitation_link, leaving alternative selection to inference.

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

create_leadCreate a non-member contact (lead). To add a full community member instead, use create_community_member.A

Destructive

Create a non-member contact (lead). To add a full community member instead, use create_community_member.. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No	Display name of the contact.
`email`	No	Email address of the contact. Must not already belong to a member or an existing non-member contact in this community.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_tag_ids`	No	IDs of existing member tags to apply to the new contact. Use the member_tags endpoints to look these up.

TDQS

A4.1/5.0

Behavior4/5

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

Annotations already cover the safety profile (destructiveHint=true, idempotentHint=false, openWorldHint=true), and the description adds value by stating it 'changes community state' and requires 'confirm=true for the user-requested action'. That confirm gating is behavioral context not conveyed by the annotations.

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?

Two short sentences, front-loaded with the action and the alternative route. Deductions for the duplicated title sentence and the stray double period ('create_community_member..').

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 a 7-param mutation tool with nested objects and no output schema, the description conveys the mutation/destructive nature and the confirm requirement, and the schema carries full parameter detail. Adequate, though it could clarify how payload vs body flags vs payload_file are chosen.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (including confirm, payload, payload_file, member_tag_ids) is already documented in the schema. The description adds no syntax or format detail beyond that, so the baseline 3 is appropriate.

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 ('Create a non-member contact (lead)') and explicitly differentiates from the full-member path by naming create_community_member. An agent can distinguish lead vs member creation without opening either schema.

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?

Names the alternative tool and the condition that selects it ('To add a full community member instead'), which is the key routing decision. It does not add broader when/when-not exclusions or prerequisites, so it stops short of the top score.

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

create_memberCreate/Invite a community memberB

Destructive

Create/Invite a community member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`email`	No
`avatar`	No	signed_id of the avatar returned from the direct upload endpoint
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`headline`	No
`password`	No
`space_ids`	No
`is_flagged`	No
`preferences`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_tag_ids`	No
`skip_invitation`	No
`space_group_ids`	No
`community_member_profile_fields`	No	Profile fields key value pairs

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds only that it 'changes community state' and requires confirm, and the confirm rule is already stated in the schema's confirm field, so the marginal behavioral disclosure is thin.

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?

Two short sentences with no filler, and the state-change/confirm constraint is front-loaded right after the purpose. Nothing redundant.

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

Completeness2/5

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

For a 16-parameter, zero-required, nested-object mutation tool with no output schema, the description is far too thin. It omits the payload/body-flags/payload_file exclusivity rules and any indication of what a successful invite returns or requires.

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 38% across 16 parameters with nested payload/preferences objects, so the schema leaves substantial gaps. The description compensates by mentioning only confirm, saying nothing about the name/email payload, avatar signed_id, account credential selection, or the payload-vs-flags mutual exclusion.

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?

States a specific verb+resource ('Create/Invite a community member'), so an agent knows the operation. It does not differentiate itself from nearby siblings such as create_invitation, create_space_group_member, or update_member, leaving the boundary to be inferred from the name alone.

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

Usage Guidelines3/5

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

The only guidance is the confirm=true gating for user-requested actions, which is implied usage rather than an explicit when/when-not. No alternative is named and no prerequisite (permissions, community context) is given.

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

create_member_tagCreate Member TagC

Destructive

Create Member Tag. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`color`	No
`emoji`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`is_public`	No
`custom_emoji`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`display_format`	No
`display_locations`	No
`is_background_enabled`	No

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds that the call 'changes community state' and requires confirm=true, which is useful reinforcement but not new depth (confirmation is also documented in the schema).

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?

Two short sentences with the purpose and the confirm constraint front-loaded; no filler. It is appropriately sized, though the extreme brevity is a symptom of under-specification rather than tight writing.

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

Completeness2/5

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

A destructive, non-idempotent mutation with 12 parameters, nested objects, no output schema, and 33% schema coverage warrants far more explanation (required fields, payload vs body-flag mutual exclusion, return behavior). The two-sentence description leaves the agent substantially under-informed.

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?

With 12 parameters and only 33% schema description coverage, the description should compensate but instead omits all parameter semantics. The only param referenced (confirm) is already explained in the schema, so the description adds nothing for name, color, emoji, payload, or the nested display objects.

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

Purpose2/5

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

The description opens with 'Create Member Tag,' which is a verbatim restatement of the tool name and title. It adds no scope, target, or distinguishing detail versus update_member_tag, delete_member_tag, or tag_member, so it functions as a tautology.

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

Usage Guidelines2/5

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

It notes that confirm=true is required 'for the user-requested action,' which is a usage constraint, but gives no guidance on when to use this tool versus sibling tag operations (update/delete/tag_member). No prerequisites or exclusions are stated.

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

create_paywall_groupCreate Subscription GroupC

Destructive

Create Subscription Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`currency_id`	No	ID of the currency the group's paywalls are priced in
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real context beyond that: it mutates community state and enforces a confirm gate tied to the user's explicit request. It stops short of describing reversibility or permission requirements.

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?

Two short, front-loaded sentences with no filler. It is tight, though the first sentence is pure redundancy with the title rather than an information-bearing statement.

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 destructive, non-idempotent creation tool with a nested payload and no output schema, the confirm gate and state-change warning are useful, but an agent still lacks guidance on when this tool applies versus sibling group creators and what a successful result entails.

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

Parameters3/5

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

Schema description coverage is 83%, so the schema already documents account, confirm, currency_id, payload, and payload_file well. The description only echoes the confirm=true semantics already stated in the confirm parameter's own description, adding no new meaning.

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

Purpose2/5

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

The first sentence "Create Subscription Group" is a verbatim restatement of the title, adding no information beyond the tool name. It does not explain what a subscription/paywall group is or how it differs from sibling creators like create_access_group or create_space_group.

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

Usage Guidelines2/5

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

The description notes that confirm=true is required for the user-requested action, which is a mild usage constraint, but it gives no guidance on when to use this tool versus the many other create_* siblings or what preconditions must hold.

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

create_postCreate Basic PostC

Destructive

Create Basic Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`slug`	No
`status`	No
`topics`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`user_id`	No	id of the author
`space_id`	No
`is_pinned`	No
`created_at`	No
`meta_title`	No
`user_email`	No	email of the author (preferred over user_id)
`cover_image`	No	signed_id of the cover image
`tiptap_body`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`published_at`	No
`hide_meta_info`	No
`opengraph_title`	No
`meta_description`	No
`is_liking_enabled`	No
`is_comments_closed`	No
`skip_notifications`	No
`is_comments_enabled`	No
`internal_custom_html`	No
`opengraph_description`	No
`is_truncation_disabled`	No
`hide_from_featured_areas`	No

TDQS

C2.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, covering the safety profile. The description adds one genuinely useful behavioral requirement not carried by annotations: the confirm=true gate. Beyond that it repeats "changes community state," which the annotations already imply, and discloses nothing about rate limits or side effects like notifications.

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

Conciseness3/5

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

Two short sentences with no filler and the confirm requirement front-loaded alongside the action. However, for a 28-parameter tool with nested objects, this level of brevity reads as under-specification rather than effective conciseness.

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

Completeness1/5

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

A 28-param, nested-object, no-required-fields, no-output-schema write tool with 0% required parameters and low description coverage needs substantial guidance on which of the four body-input modes to use and how space_id/name are supplied. None of that is present, leaving an agent unable to construct a valid call from the description alone.

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?

With 28 parameters and only 25% schema description coverage, the description needs to compensate but does not. It mentions only confirm=true (the gate, itself already documented in the schema) and says nothing about the mutually exclusive payload/payload_file/body-flag mechanisms, the tiptap_body structure, or account/slug/topics/status.

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

Purpose2/5

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

The first sentence, "Create Basic Post," is a verbatim restatement of the tool title, which itself just rephrases the name create_post. It states a verb and resource but gives no scope or distinguishing detail to separate it from create_image_post, create_comment, or create_event in the sibling list.

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

Usage Guidelines2/5

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

"requires confirm=true for the user-requested action" implies the tool should only be called for a user-requested action, which is a faint usage hint. However, there is no guidance on when to use this versus create_image_post or duplicate_image_post, and no statement of prerequisites or when not to use it.

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

create_profile_fieldCreate Profile FieldC

Destructive

Create Profile Field. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`profile_field`	No

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false, so the safety profile is largely covered. The description reinforces the state-changing/destructive nature and mentions the confirm gate, but the confirm requirement is also documented in the schema's confirm parameter description, so it adds limited new context. No mention of return behavior, side effects on members, or rate limits.

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

Conciseness3/5

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

Only two short sentences and reasonably front-loaded, but the first sentence is pure tautology and the second largely duplicates what the confirm parameter schema already states. It is brief without being wasteful, yet barely earns its space.

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 tool with a deep nested schema (5 params, nested objects) and no output schema, the description is thin but the schema compensates with rich field-level descriptions. It omits a top-level illustration of the payload shape and the conditional requirements for choices/number options, which would help, but nothing critical to invocation is missing.

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

Parameters3/5

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

Schema description coverage is 80%, so the schema already carries the parameter burden (including nested profile_field, choices_attributes, and number_options_attributes semantics). The description adds nothing about parameters, so the baseline 3 is appropriate.

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

Purpose2/5

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

"Create Profile Field" merely restates the tool name and title; the only added content is "Changes community state," which is a generic behavior shared by all mutating siblings. Nothing distinguishes it from update_profile_field, delete_profile_field, or archive_profile_field. This is essentially tautological rather than a specific verb+resource+scope statement.

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

Usage Guidelines2/5

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

The description notes a confirm=true requirement but gives no when-to-use context and no differentiation from sibling profile-field tools (update/delete/archive). An agent gets no guidance on choosing this tool over its closest relatives or on prerequisites beyond the confirm flag.

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

create_spaceCreate SpaceC

Destructive

Create Space. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`slug`	No
`emoji`	No	Simple emoji string for the space
`topics`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`is_hidden`	No
`is_private`	No
`space_type`	No
`cover_image`	No	signed_id of the cover image
`default_tab`	No	Default tab to show when entering the space
`custom_emoji`	No
`default_sort`	No
`display_view`	No	Default display view for the space
`hide_sorting`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`show_tab_bar`	No	Show the tab bar navigation
`visible_tabs`	No
`course_setting`	No
`space_group_id`	No
`show_next_event`	No	Show next event information for event spaces
`thumbnail_image`	No	signed_id of the thumbnail image for event spaces
`is_post_disabled`	No
`hide_from_sidebar`	No	Hide space from sidebar navigation
`locked_button_url`	No
`hide_members_count`	No	Hide the member count display
`hide_post_settings`	No	Hide post settings
`hide_right_sidebar`	No	Hide right sidebar in space
`pinned_posts_label`	No	Custom label for pinned posts
`cover_image_visible`	No
`default_member_sort`	No	Default sort order for members
`locked_button_label`	No
`locked_page_heading`	No
`meta_tag_attributes`	No
`default_comment_sort`	No	Default sort order for comments
`event_auto_rsvp_enabled`	No	Only for event spaces
`locked_page_description`	No
`require_topic_selection`	No	Require topic selection when posting
`hide_from_featured_areas`	No	Hide space from featured areas
`cover_image_display_style`	No
`disable_member_post_covers`	No	Disable cover images on member posts
`is_hidden_from_non_members`	No
`default_notification_setting`	No	Members will receive an email notification when new events are posted
`show_lock_icon_for_non_members`	No	Show lock icon for non-members
`prevent_members_from_adding_others`	No	Prevent members from adding other members to the space
`default_in_app_notification_setting`	No	Members will see an in-app notification when new events are posted
`default_mobile_notification_setting`	No	Members will see a mobile notification when new events are posted
`default_mention_in_app_notification_setting`	No	Members will see an in-app notification when mentioned
`default_mention_mobile_notification_setting`	No	Members will see a mobile notification when mentioned

TDQS

C2.9/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds genuinely new context beyond that: it changes community state and requires confirm=true for a user-requested action, which is a meaningful gating requirement an agent must honor. It stops short of describing what side effects or related state changes occur.

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?

Two short sentences, front-loaded, with no filler. However, the opening sentence is pure restatement of the title, so the space it occupies is not fully earned. Still, the text is tight and appropriately sized.

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

Completeness2/5

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

For a destructive, non-idempotent tool with 50 parameters, nested objects, no output schema, and three mutually exclusive body-input modes, two sentences is far too thin. It omits required payload fields (space_group_id, name, slug), the exclusivity rules between payload/payload_file/body flags, and any notion of the return value. The description is incomplete for the tool's complexity.

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?

With 50 parameters, 58% schema coverage, 10 enums, and nested objects, the description is almost silent on parameters. The only parameter it mentions, confirm, is already fully documented in the schema. It never clarifies the critical payload vs. body-flags vs. payload_file distinction, nor the account selector, leaving the agent to reverse-engineer the schema.

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

Purpose3/5

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

The first sentence, 'Create Space,' is a verb+resource but essentially restates the tool name and title verbatim. It does not distinguish this tool from close siblings such as create_space_group, update_space, or create_event, all of which appear in the sibling list. An agent can infer the basic purpose from the name alone, so this is minimally viable rather than clarifying.

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

Usage Guidelines2/5

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

The description offers no when-to-use vs when-not guidance and never names an alternative (e.g., create_space_group for grouping, update_space for edits). The only usage-adjacent statement concerns the confirm flag, which is more of a parameter rule than a selection guideline. An agent gets no help choosing this tool over its siblings.

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

create_space_groupCreate Space GroupB

Destructive

Create Space Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`slug`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`hide_members_count`	No
`is_hidden_from_non_members`	No
`allow_members_to_create_spaces`	No
`hide_non_member_spaces_from_sidebar`	No
`automatically_add_members_to_new_spaces`	No
`add_members_to_space_group_on_space_join`	No

TDQS

B3.3/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, covering the safety profile. The description adds a specific operational requirement – confirm=true for user-requested actions – and notes that it changes community state, which is useful beyond the annotations. However, it stops short of explaining what state is changed or any side effects.

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?

The description is two sentences and front-loads the purpose before the behavioral note. The first sentence simply restates the title, but it is not verbose.

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

Completeness2/5

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

For a 12-parameter mutation tool with a nested payload object and no output schema, the description is far too sparse. It omits almost all parameter guidance and does not describe the effect on community state, leaving major gaps.

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 only 33%, so the description should compensate for undocumented parameters. Instead, it only restates the confirm parameter's intent already present in the schema, and says nothing about the other 11 parameters (name, slug, payload, flags).

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 clear verb+resource ('Create Space Group'), so the purpose is unambiguous. However, it does not differentiate from similar siblings like create_space or create_space_group_member, leaving the agent to infer scope from the name alone.

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

Usage Guidelines3/5

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

It gives a condition for using confirm=true ('for the user-requested action'), which is a useful usage rule. But it never says when to choose this tool over alternatives such as create_space or update_space_group, and offers no exclusions.

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

create_space_group_memberCreate Space Group MemberC

Destructive

Create Space Group Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`space_group_id`	No

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds two useful behavioral facts beyond the annotations: it changes community state and needs confirm=true. It does not, however, explain what is destroyed or why it is not idempotent.

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

Conciseness3/5

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

Two short sentences and no filler, so it is compact. The second sentence is front-loaded with the confirm constraint, but the overall statement is thin for a six-parameter mutation, so efficiency tips toward under-specification rather than optimal brevity.

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

Completeness2/5

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

For a destructive, non-idempotent tool with a nested payload object, six parameters, and no output schema, the description omits essentials: what a space group member is, the payload/payload_file exclusivity, and the effect on existing members. It is far too sparse for the complexity.

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

Parameters3/5

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

Schema description coverage is 67%, so the schema already documents the confirm, account, and payload/payload_file parameters. The description echoes the confirm=true requirement but adds no meaning for email, space_group_id, or the payload-vs-payload_file mutual exclusion.

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

Purpose2/5

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

The description is 'Create Space Group Member', which exactly restates the tool name and title without adding a verb+resource distinction. It gives no sense of how it differs from siblings like add_space_member, create_member, or add_to_access_group.

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

Usage Guidelines2/5

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

There is no when-to-use or when-not-to-use guidance. The 'requires confirm=true for the user-requested action' clause hints at a precondition but never routes the agent to an alternative tool or explains the relationship to add_space_member / delete_space_group_member.

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

create_topicCreate a topicB

Destructive

Create a topic. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`space_ids`	No	Array of space IDs to be assigned to the topic
`admin_only`	No	Toggles if only admins and moderators can select this topic
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already disclose readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation profile is covered. The description adds one genuinely useful fact beyond that — the confirm=true gate tied to user intent — but it does not say what state is mutated, whether it is reversible, or what permissions are needed.

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?

Two short sentences with no padding, and the confirmation requirement is front-loaded after the purpose. It is efficient, though extremely sparse for a 7-parameter tool.

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?

With 86% schema coverage and no output schema, the description is minimally sufficient, but this is a complex tool with a nested payload object and mutually exclusive body options (payload vs payload_file vs body flags) that the description never acknowledges. An agent must infer this complexity entirely from the schema.

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

Parameters3/5

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

Schema description coverage is 86%, so nearly every parameter (account, confirm, payload, space_ids, admin_only, payload_file) is already documented in the schema. The description adds no additional parameter meaning, which is the expected baseline when the schema does the heavy lifting.

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

Purpose3/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 ("Create a topic"), but it is essentially the title restated and does nothing to distinguish this tool from siblings like create_space, create_post, or create_event. An agent learns what happens but not why this tool over another creator.

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

Usage Guidelines3/5

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

"Requires confirm=true for the user-requested action" implies the tool should be used when the user explicitly asked for this action, which is a mild usage signal. However, it never names an alternative, states prerequisites, or explains when not to call it.

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

deactivate_workflowDeactivate an automation (dynamic) workflow so it stops running automaticallyA

Destructive

Deactivate an automation (dynamic) workflow so it stops running automatically. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	UUID of the workflow to deactivate
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description's added value is limited to 'changes community state' (partly redundant with destructiveHint) and the confirm gate, which the schema already documents. It doesn't say whether deactivation is reversible or what happens to in-flight runs.

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?

Two sentences, no padding, and the core purpose and the confirm requirement are both front-loaded. Every clause earns its place.

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 a mutation tool with no output schema, this covers purpose, state impact, and the confirmation gate, and annotations carry the safety profile. Only minor gaps remain (reversibility, side effects on running automations).

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters (id, account, confirm) are already documented with meaningful descriptions. The description only restates the confirm semantics, adding no syntax or format detail beyond the schema; baseline 3 applies.

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 (Deactivate) and resource (automation/dynamic workflow), plus the concrete effect (stops running automatically). Clear contrast with the sibling activate_workflow without needing its schema.

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?

Gives real usage context: changes community state and requires confirm=true only for a user-requested action, which tells the agent when invocation is appropriate. It stops short of naming activate_workflow as the inverse alternative or stating exclusions explicitly.

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

delete_commentDestroy CommentC

Destructive

Destroy Comment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`comment_id`	Yes

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds that the operation mutates community state and requires confirm=true, which is useful but largely duplicates the confirm parameter's schema description.

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?

Two short, front-loaded sentences with no redundant filler. Brevity is a virtue here, though the second sentence re-packages what the schema already says.

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

Completeness2/5

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

For a destructive, non-idempotent delete with no output schema, the description omits what is destroyed (the comment and any replies), whether it is recoverable, and error behavior. An agent lacks enough to call this confidently beyond the confirm flag.

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

Parameters3/5

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

Schema coverage is 67%: the account parameter is well documented as a credential selector and confirm is documented in the schema. The description echoes the confirm requirement but adds nothing about comment_id or whether the deletion is permanent, so it does not compensate for the remaining gap.

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

Purpose2/5

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

"Destroy Comment" simply restates the tool title and, implicitly, the name delete_comment. It never states the resource being acted on precisely (a single comment identified by comment_id) or what happens to it, so it reads as a tautology rather than a purpose statement.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus siblings such as delete_post, delete_topic, or update_comment. The only usage hint is the confirm=true requirement, which is a gating rule rather than a when-to-use criterion.

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

delete_community_memberDelete Community MemberB

Destructive

Delete Community Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`member_id`	Yes	Community member ID to delete

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds a state-change note and the confirm gate, but much of that duplicates the confirm parameter's own schema description, and it says nothing about permissions/scope of destruction beyond "changes community state."

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

Conciseness3/5

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

Only two short sentences, so it is compact, but the first sentence is pure title repetition that does not earn its place. The useful content (state change, confirm requirement) is present but not the front-loaded element.

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 destructive, non-idempotent mutation with no output schema, the description plus annotations convey the essential safety profile and the confirm requirement. It is minimally adequate but omits the sibling disambiguation (remove_member/ban_community_member) and any note on reversibility or scope that would make the delete decision safe.

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

Parameters3/5

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

Schema description coverage is 100% and the schema itself documents all three parameters (account, confirm, member_id), including the credential-selection nuance for account. The description adds no parameter meaning beyond what the schema already states, so the baseline of 3 applies.

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

Purpose3/5

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

The second sentence identifies the effect ("Changes community state") and the verb/resource is unambiguous (delete a community member), but the opening sentence "Delete Community Member" is a verbatim restatement of the title/name. Critically, it does not distinguish this tool from adjacent siblings such as remove_member, ban_community_member, or delete_member_tag, which an agent could easily confuse with a member deletion.

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

Usage Guidelines3/5

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

The only guidance is the conditional "requires confirm=true for the user-requested action," implying this is a user-confirmed destructive action. There is no explicit when-to-use vs. when-to-use-an-alternative statement, and the obvious competing tool remove_member is never mentioned, so routing remains inferred rather than guided.

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

delete_community_segmentDelete a community segmentA

Destructive

Delete a community segment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`segment_id`	Yes	ID of the community segment to delete

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the meaningful operational constraint that confirm=true must be set, plus the note that it changes community state. It still doesn't say the deletion is irreversible or what happens to members assigned to the segment.

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?

Two short sentences with the destructive action and the confirm gate front-loaded; nothing is padded or buried. 'Changes community state' is slightly vague filler, but the size is appropriate for the operation.

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 non-idempotent destructive tool with no output schema, the description covers the core action and the confirm precondition but omits consequences: permanence, effect on segment members, and whether any cleanup or reassignment is needed. That is a meaningful gap for an irreversible operation.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, and segment_id fully. The description only restates the confirm requirement, adding no syntax, format, or ID-sourcing detail beyond what the schema provides — baseline 3.

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 and resource ('Delete a community segment'), which is clear and unambiguous. It does not, however, distinguish this tool from its close siblings such as create_community_segment, update_community_segment, or duplicate_community_segment, so the agent gets no routing help beyond the name.

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

Usage Guidelines3/5

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

It gives one concrete usage condition — confirm=true is required for the user-requested action — which implies the confirmation workflow. But it never says when to pick this over update_community_segment or duplicate_community_segment, and gives no exclusions or alternative guidance.

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

delete_course_lessonDelete a course lessonA

Destructive

Delete a course lesson. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`lesson_id`	Yes	Course lesson ID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the destructive/non-reversible profile is covered structurally. The description's 'Changes community state' largely restates destructiveHint, and the confirm requirement duplicates the schema's own parameter description, so it adds only marginal behavioral context.

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?

Two short sentences, with the destructive nature and the confirm guard front-loaded. Nothing extraneous, though the second sentence is doing little work beyond the schema.

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 a destructive mutation tool with full annotation coverage and 100% schema description coverage, the definition supplies the essentials an agent needs. No output schema exists, so there is no return-value gap to fill.

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

Parameters3/5

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

Schema description coverage is 100%, so lesson_id, account, and confirm are already documented in-schema; the description only echoes the confirm semantics without adding new meaning. Baseline 3 is appropriate when the schema carries the parameter burden.

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?

States a specific verb (Delete) and resource (course lesson), and the tool name distinguishes it from delete_course_section and delete_course_lesson-adjacent siblings. It is clear but does not explicitly differentiate itself from the other course-mutation tools beyond the name.

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

Usage Guidelines3/5

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

The description notes the confirm=true prerequisite and ties it to a user-requested action, which is genuine usage guidance. However, it offers no when-to-use/when-not guidance relative to siblings like delete_course_section or archive-style alternatives.

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

delete_course_sectionDelete a course sectionA

Destructive

Delete a course section. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`section_id`	Yes	Course section ID

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds genuinely new behavioral context: the call mutates community state and is gated behind confirm=true, which is an authorization/guardrail detail not present in the annotations.

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?

Two short sentences, purpose first, then the guardrail, with no filler. Slight redundancy between the description and the confirm parameter text, but nothing wasted at the sentence level.

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 a three-parameter destructive tool with full schema coverage and no output schema, the description covers the what, the state change, and the confirmation gate. It omits what deletion cascades to (lessons, progress) or how to recover, which would be the only remaining gap worth filling.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains account, confirm, and section_id semantics in detail. The description only echoes the confirm requirement already documented on the parameter itself, adding no syntax, format, or edge-case meaning beyond it.

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?

States a specific verb and resource ('Delete a course section'), which is unambiguous against nearby siblings like delete_course_lesson and update_course_section. It does not, however, explicitly contrast itself with any alternative tool, so it stops short of a 5.

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

Usage Guidelines3/5

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

The line 'requires confirm=true for the user-requested action' gives a real precondition that gates invocation, which is more than most delete descriptors offer. It still offers no when-to-use/when-not framing against alternatives such as archiving or updating a section, so usage is implied rather than spelled out.

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

delete_eventDelete EventB

Destructive

Delete Event. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`event_id`	Yes	Event ID
`space_id`	Yes	Space ID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds real value by disclosing that the call changes community state and is gated behind confirm=true, but it omits consequences (what happens to attendees, whether deletion is reversible) and any permission requirements.

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?

Two short sentences, with the action and the confirm requirement front-loaded and no wasted prose. The first sentence merely restates the name/title, which is the one redundant element.

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 destructive, non-idempotent mutation with four parameters and no output schema, the description covers the confirm gate but says nothing about side effects on related records, permissions, or error conditions. It is adequate given the annotations, but not complete.

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

Parameters3/5

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

Schema description coverage is 100% and the schema itself explains confirm and account well, so the description does not need to document parameters. Its only parameter-related content (confirm=true) duplicates the schema, adding no new syntax or edge-case meaning.

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 and resource ("Delete Event") that clearly separates it from siblings such as delete_event_attendee, update_event, and duplicate_event. It is essentially the title restated plus one behavioral clause, so it is clear but not distinctive in wording.

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

Usage Guidelines3/5

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

It implies usage through the confirm=true gate ("for the user-requested action"), which tells the agent this is a deliberate, user-initiated action. However, it never says when to delete versus archive/update an event or how this differs from delete_event_attendee, so alternatives are left to inference.

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

delete_event_attendeeDelete Event AttendeeB

Destructive

Delete Event Attendee. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`event_id`	No	Event ID
`member_email`	No	Member Email
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description adds a modest amount of context (it changes community state, and a confirm flag is required), which reinforces rather than contradicts the annotations, but says nothing about reversibility, scope of the deletion, or error behavior.

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?

Two short sentences with no filler, and the destructive/mutation framing is front-loaded. However, the brevity comes at the cost of substance for an operation with six parameters and nested body options.

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

Completeness2/5

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

For a destructive deletion tool with six parameters, a nested payload object, and no output schema, the description omits how payload, payload_file, and the flat event_id/member_email flags relate, and how the account parameter selects credentials. It does not carry enough information for an agent to invoke this safely beyond the confirm gate.

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

Parameters3/5

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

Schema description coverage is 100%, so all six parameters are already documented in the schema, including the meaning of confirm and the payload-vs-body-flags distinction. The description only echoes the confirm requirement and adds no parameter detail beyond the schema, so baseline 3 applies.

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

Purpose3/5

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

The first sentence is a verb+resource restatement of the tool name/title ("Delete Event Attendee"), giving no scope detail beyond that. It is distinguishable from create_event_attendee and list_event_attendees by name alone, but the description itself adds nothing to sharpen that distinction.

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

Usage Guidelines3/5

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

The second sentence implies a usage condition: this is a mutation gated behind confirm=true being set only for a user-requested action. That is a real precondition, but there is no guidance on when to prefer this over delete_event or other attendee-management siblings, and no explicit when-not.

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

delete_filter_controlDelete a filter controlA

Destructive

Delete a filter control. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`filter_control_id`	Yes	ID of the filter control to delete

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds genuinely useful context beyond that: the operation mutates community state and is gated behind a confirm=true guard tied to an explicit user request.

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?

Two short sentences with no filler; the destructive action and the confirm gate are front-loaded so an agent sees the constraint immediately.

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 a destructive tool with no output schema, the description plus annotations convey the needed essentials (irreversible write, confirm gate, community-level impact). It stops short of describing downstream effects on filter configurations or dependent state, which would make it fully complete.

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

Parameters3/5

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

Schema description coverage is 100%, including a clear note that 'account' selects credentials rather than a remote community ID, so the schema carries the parameter semantics. The description's mention of confirm=true largely restates the schema's own wording, adding little beyond the baseline.

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?

States a specific verb+resource ('Delete a filter control'), which cleanly separates it from the sibling create_filter_control, update_filter_control, get_filter_control and list_filter_controls. It is clear but does not explicitly name those siblings or the scope of the deletion.

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

Usage Guidelines3/5

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

The description implies the when-to-use context via 'requires confirm=true for the user-requested action' and warns that community state changes, but it never names an alternative or an explicit exclusion (e.g., when to archive/lay aside vs delete). Usage is implied rather than spelled out.

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

delete_formDelete a formA

Destructive

Delete a form. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	Form ID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered structurally. The description adds 'Changes community state' and reiterates the confirm gate, but the confirm semantics are also captured in the schema, so net new behavioral disclosure is modest.

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?

Two short sentences, front-loaded with the action and followed by the key constraint. No filler or redundancy, though the phrasing could be slightly tighter.

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 a simple delete tool with no output schema and annotations carrying the destructive/idempotency profile, the description covers the essential action and the confirm requirement. Nothing critical for correct invocation is missing, though a note on irreversibility would improve it.

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

Parameters3/5

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

Schema description coverage is 100%, so account, confirm, and form_id are all documented in the schema itself, making the baseline 3 appropriate. The description only echoes the confirm parameter's requirement without adding syntax or format detail beyond the 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?

States a specific verb+resource ('Delete a form') that any agent can immediately map to a destructive operation. It does not distinguish itself from siblings like update_form or duplicate_form, but the verb 'delete' is unambiguous enough that differentiation is not strictly needed.

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

Usage Guidelines3/5

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

The description adds a precondition ('requires confirm=true for the user-requested action'), which tells the agent how to proceed once it has decided to use the tool. However, it gives no when-not guidance or mention of alternatives (e.g., archive vs delete), leaving usage context only implied.

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

delete_image_postDelete Image PostA

Destructive

Delete Image Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`post_id`	Yes	Image post ID
`space_id`	Yes	Image space ID

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds a genuinely useful behavioral detail beyond that: the operation mutates community state and is gated behind an explicit confirm=true flag, which tells the agent a confirmation step is required before the destructive action fires.

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?

Two short sentences with zero filler, and the destructive/mutation warning plus the confirm gate are front-loaded immediately after the tool name. 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 a destructive mutation with rich annotations and a fully documented schema, the description covers the key agent-facing facts: it changes community state and requires explicit confirmation. It stops short of saying what else is removed along with the image post (comments, reactions) or whether the deletion is recoverable, which would be the final useful detail.

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

Parameters3/5

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

Schema description coverage is 100%, with account, confirm, post_id and space_id all documented in the schema, so the baseline is 3. The description restates the confirm requirement but adds no syntax, format, or default information beyond what the schema already provides.

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?

States a specific verb and resource ("Delete Image Post"), so the agent knows exactly what operation is performed. It does not, however, distinguish this from the closely related sibling delete_post, leaving the image-post-vs-post boundary for the agent to infer.

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

Usage Guidelines3/5

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

The line about confirm=true being for "the user-requested action" implies when the tool is appropriate, and it is reinforced by the schema note to set confirm true only when the user asked for exactly this action. But there is no explicit when-to-use guidance and no mention of alternatives such as delete_post, so usage is only implied.

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

delete_invitation_linkDelete invitation linkB

Destructive

Delete invitation link. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`invitation_id`	Yes	Invitation link ID

TDQS

B3.1/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: that the call mutates community state and that confirm=true is a required guard for the user-requested action. Reversibility and rate limits remain undisclosed, so not a 5.

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?

Two short sentences, front-loaded with the action and followed by the behavioral constraint. Slightly redundant in restating the tool name, but no wasted padding.

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 destructive, non-idempotent mutation with no output schema, the description covers the confirm gate but omits what specifically changes in community state, whether the action is reversible, and how it differs from revoke_invitation_link. Adequate but with clear gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already explains account, confirm, and invitation_id. The description only echoes the confirm=true requirement already documented in the schema, adding no syntax or format detail. Baseline 3 is appropriate.

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

Purpose3/5

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

States a verb and resource ('Delete invitation link'), but this is essentially the title restated with no additional specificity. It does not distinguish itself from the very close sibling revoke_invitation_link (nor update_invitation_link), so an agent cannot tell from the description alone which removal operation applies.

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

Usage Guidelines2/5

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

No when-to-use or when-not-to-use guidance is given. The closest siblings, revoke_invitation_link and update_invitation_link, are the obvious alternatives an agent must choose between, and neither is mentioned. The confirm note is a call precondition, not usage guidance.

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

delete_leadDelete a non-member contact (lead). To delete a full community member instead, use destroy_community_member.A

Destructive

Delete a non-member contact (lead). To delete a full community member instead, use destroy_community_member.. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`lead_id`	Yes	Numeric id of the non-member contact to delete

TDQS

A4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the safety profile is covered. The description adds that it 'changes community state' and requires confirm=true, which is useful framing, but the confirm requirement is also documented in the schema, so the marginal addition is modest.

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?

Two short, front-loaded sentences that lead with the action and the routing. A stray double period ('destroy_community_member..') is a trivial blemish rather than a structural problem.

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?

For a 3-param destructive tool with full schema coverage, no output schema, and annotations carrying the safety profile, the description supplies action, routing, and the confirm guardrail. Nothing an agent needs to invoke it correctly is missing.

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

Parameters3/5

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

Schema description coverage is 100%, so the baseline is 3. The description restates the confirm requirement but adds no syntax or format detail beyond what the schema already documents for account, confirm, and lead_id.

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 (Delete) and resource (a non-member contact/lead) and explicitly distinguishes it from the member-deletion sibling. An agent can tell what it does and what it is not without opening the schema.

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?

Explicitly routes the agent: use this for a non-member contact, use destroy_community_member for a full member. That names the alternative and the selecting condition. Minor weakness: the named alternative doesn't exactly match the closest sibling (delete_community_member), and no other exclusions are given.

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

delete_member_tagDeletes a member tagA

Destructive

Deletes a member tag. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`tag_id`	Yes	Member tag ID
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds real context beyond that: the deletion 'changes community state' and mandates confirm=true, which tells the agent this is a state-mutating, confirmation-gated operation.

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?

Two short sentences, with the core action front-loaded. Slightly over-compressed: the second sentence packages two distinct facts (state change, confirm requirement) and could carry a bit more without bloating.

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 destructive, non-idempotent mutation with no output schema, the description covers the action and the confirm gate but omits whether deletion is permanent, what happens to members currently carrying the tag, and any permission requirements. Adequate but leaves gaps an agent might need before invoking.

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

Parameters3/5

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

Schema description coverage is 100%, so tag_id, account, and confirm are all documented in the schema itself, including the 'Set true only when the user asked for exactly this action' gloss on confirm. The description's confirm mention restates the schema rather than adding new syntax or format detail, so baseline 3 applies.

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?

States a specific verb+resource ('Deletes a member tag'), which cleanly separates it from siblings create_member_tag, update_member_tag, and list_member_tags. It does not name a sibling or scope the deletion (e.g. whether it detaches the tag from all members) for explicit differentiation.

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

Usage Guidelines3/5

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

The clause 'requires confirm=true for the user-requested action' gives a usable when-to-use hint tied to user intent. However, no alternatives or exclusions are stated (e.g. use untag_member to merely remove a tag from one member), so usage is implied rather than explicit.

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

delete_paywallDeletes a paywallB

Destructive

Deletes a paywall. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`paywall_id`	Yes	Paywall ID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, which carries most of the risk profile. "Changes community state" is a mild addition but is vague and largely restates the destructive annotation; nothing is said about irreversibility, cascading effects, or the required permission level.

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?

Two tightly packed sentences with the core action front-loaded and no filler. The second sentence bundles two distinct ideas (state change and confirm gating) but stays readable.

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 destructive, non-idempotent operation with full annotation coverage and complete parameter documentation, the essentials are present. It is still thin on the consequences of deletion versus archiving, which is the main decision an agent faces with this sibling set.

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

Parameters3/5

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

Schema description coverage is 100%, including a clear explanation of account and confirm, so the schema does the heavy lifting. The description repeats the confirm requirement without adding format, constraint, or edge-case detail beyond what the schema already provides.

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?

States a specific verb and resource ("Deletes a paywall"), which is unambiguous on its own. It does not, however, differentiate itself from the closely related siblings archive_paywall and unarchive_paywall, which an agent could easily confuse with an actual deletion.

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

Usage Guidelines3/5

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

The sentence about confirm=true gives implicit guidance on the user-requested action, but there is no explicit when-to-use framing and no routing to alternatives such as archive_paywall for reversible hiding. The agent must infer that this is the permanent-removal path.

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

delete_paywall_couponDeletes a paywall couponB

Destructive

Deletes a paywall coupon. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	Paywall coupon ID
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered by structured data. The description adds 'Changes community state' and the confirm gate, but says nothing about reversibility, side effects on existing redemptions, or failure conditions beyond what annotations imply.

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?

Two short sentences with no filler, and the behavioral constraint follows immediately after the purpose. The first sentence largely restates the title, so it is efficient but not maximally informative per word.

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 destructive, non-idempotent mutation with no output schema, the definition covers the essentials (what is deleted, the confirm requirement) but omits consequences an agent would want — whether deletion is permanent, what happens to subscribers on the coupon, and what the response contains.

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

Parameters3/5

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

Schema description coverage is 100% — id, account, and confirm are each documented inline, including the 'named private Circle account' nuance. The description adds no parameter-level meaning beyond the schema, so the baseline of 3 applies.

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 and resource ('Deletes a paywall coupon'), which is unambiguous and clearly distinct from nearby siblings like delete_paywall or delete_post. It does not, however, contrast itself with any related coupon tool or explain the scope of the deletion.

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

Usage Guidelines3/5

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

It gives one concrete precondition — 'requires confirm=true for the user-requested action' — which steers invocation but leaves the agent to infer when a coupon deletion is appropriate. No alternative or exclusion is named, and no prerequisite (e.g. coupon must be unused) is given.

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

delete_postDelete Basic PostB

Destructive

Delete Basic Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`post_id`	Yes

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds useful context by stating it 'changes community state' and requires confirm=true, but it doesn't disclose whether deletion is permanent, whether it can be undone, or what permissions are needed.

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?

Two short sentences that are front-loaded with the action and its gating requirement; there is minimal waste, though the opening sentence merely restates the title.

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 destructive mutation tool with good annotation coverage and no output schema, the description is roughly adequate but thin. It omits permanence, reversibility, and permission requirements, and does not address what the post_id expects, so an agent has gaps for a state-changing operation.

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

Parameters3/5

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

Schema description coverage is 67%: account and confirm carry descriptions while post_id does not. The description only echoes the confirm=true requirement already present in the schema, adding no format or semantic detail beyond what structured fields provide, so a baseline 3 is appropriate.

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 names a specific verb (Delete) and resource (Basic Post), and the term 'Basic Post' hints at a distinction from the sibling delete_image_post. However it does not explicitly state how it differs from other post-mutation siblings like update_post or archive operations, leaving some differentiation to inference.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus alternatives; siblings such as delete_image_post, delete_comment, and update_post are never referenced. The only contextual cue is the confirm=true requirement, which gates the action but does not help the agent choose between tools.

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

delete_profile_fieldDelete Profile FieldA

Destructive

Delete Profile Field. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`profile_field_id`	Yes	Archived profile field ID

TDQS

A3.6/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the invocation-blocking requirement that confirm=true must be set, which is a behavior beyond the annotation set; 'Changes community state' is largely redundant with destructiveHint=true, keeping this from a 5.

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?

Two short sentences, no filler, with the destructive nature and the confirm requirement front-loaded. Minor redundancy: the first sentence merely echoes the tool title.

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 destructive, non-idempotent deletion with no output schema, the description leaves key facts unstated: whether the deletion is permanent or recoverable via archive_profile_field, and what happens to data attached to the field. It is adequate but has a notable gap around reversibility.

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

Parameters3/5

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

Schema description coverage is 100%, so account, confirm, and profile_field_id are already documented with meaning and constraints. The description restates the confirm requirement but adds no syntax, format, or edge-case detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb+resource ('Delete Profile Field'), so an agent immediately knows it removes a profile field. However, it does nothing to distinguish itself from the sibling archive_profile_field / unarchive_profile_field tools, which is the one distinction that actually matters here (permanent delete vs. reversible archive).

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

Usage Guidelines3/5

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

The description ties confirm=true to 'the user-requested action,' which impliedly tells the agent when the tool is legitimate to call (only on explicit user request). It gives no guidance on when to prefer deletion over archiving, nor any prerequisites beyond the confirm gate.

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

delete_spaceDelete a spaceA

Destructive

Delete a space. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`space_id`	Yes	Space ID

TDQS

A3.5/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true and non-idempotent, so the safety profile is largely covered. The description adds that the call 'changes community state' and is gated by confirm=true, which is useful context, but it says nothing about irreversibility or downstream effects beyond what annotations supply.

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?

Two short sentences with the core action front-loaded and no padding. The second sentence is slightly redundant with the schema's confirm description, keeping it from a 5.

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 a destructive 3-param tool with full schema coverage and annotations carrying the safety profile, the description covers the action, the state change, and the confirm gate. Nothing critical is missing, though a note on irreversibility would round it out.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents account, confirm, and space_id. The description's mention of confirm=true restates what the schema param description already says, adding no new semantic detail; baseline 3 is appropriate.

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?

States a specific verb and resource ('Delete a space'), making the operation immediately clear. It doesn't explicitly distinguish itself from close siblings like delete_space_group or delete_space_group_member, so it falls just short of a 5.

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

Usage Guidelines3/5

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

The description implies usage by stating the operation requires confirm=true 'for the user-requested action', which hints at the precondition for invoking it. But it names no alternatives and gives no explicit when-not-to-use guidance relative to the many delete_* siblings.

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

delete_space_groupDelete Space GroupB

Destructive

Delete Space Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`space_group_id`	Yes	Space Group ID

TDQS

B3.1/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, so the safety profile is covered. The description adds that the action 'changes community state' and gates it behind confirm=true, which is real extra context, but it is vague about what state changes and silent on irreversibility or cascade effects on group members.

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?

Two short sentences with no filler, and the confirm precondition is front-loaded alongside the destructive action. Slightly terse for a destructive operation, but structurally clean and appropriately sized.

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 destructive, non-idempotent tool with no output schema, the description covers the action and the confirm gate but omits what a delete actually destroys (member assignments, associated spaces) and whether it is reversible. Adequate, but the agent must guess at blast radius.

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

Parameters3/5

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

Schema description coverage is 100%, so account, confirm, and space_group_id are all documented in the schema itself (including the confirm semantics). The description only echoes the confirm requirement, adding no syntax or format meaning beyond the schema. Baseline 3 applies.

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

Purpose3/5

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

The description states a verb and resource ('Delete Space Group'), but that is a literal restatement of the tool name and title, adding no distinguishing detail. With siblings like delete_space, delete_space_group_member, and archive_access_group in the list, the agent gets no help telling them apart. Minimum-viable rather than clear-and-differentiated.

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

Usage Guidelines3/5

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

The sentence 'requires confirm=true for the user-requested action' implies a usage precondition (only when the user explicitly asked), which is useful. However, it names no alternatives and gives no when-not guidance relative to delete_space, delete_space_group_member, or member-removal tools, so the routing decision is left to inference.

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

delete_space_group_memberDestroy Space Group MemberC

Destructive

Destroy Space Group Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email of the user
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`space_group_id`	Yes	ID of the space group

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds minor context ("Changes community state" and the confirm gate), but does not say the removal is irreversible or what permissions are needed.

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?

Two short sentences with the confirm constraint front-loaded and no filler. It is tight, though thin for a destructive operation.

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?

With full schema coverage and annotations carrying the destructive/idempotency hints, the description is minimally adequate. For a destructive member deletion it should still note irreversibility or required permissions, which it omits.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents email, account, confirm, and space_group_id. The description only echoes the confirm requirement, adding nothing beyond the schema's own wording, so the baseline 3 applies.

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

Purpose2/5

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

The first sentence, "Destroy Space Group Member," is a verbatim restatement of the title, making it a tautology of the name rather than an independent statement of purpose. It offers no detail distinguishing it from siblings like delete_community_member, remove_member, or remove_space_member.

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

Usage Guidelines2/5

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

The only guidance is "requires confirm=true for the user-requested action," which hints at the confirm workflow but does not state when to use this tool versus the many overlapping remove/delete-member siblings. No exclusions or routing are provided.

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

delete_topicDelete a topicB

Destructive

Delete a topic. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`topic_id`	Yes	Topic ID

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, and non-idempotency, so the safety profile is covered. The description adds two useful pieces of context beyond the annotations: that community state changes and that confirm=true is enforced. It still omits whether deletion is permanent or cascades to related content.

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?

Two short sentences with essentially zero waste, and the destructive action is front-loaded. The trailing phrase 'for the user-requested action' is slightly vague but does not bloat the definition.

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 destructive mutation with no output schema, the description plus annotations cover the core: what it does, that it is destructive, and the confirm gate. It is adequate but leaves open the consequences of deletion (permanence, affected related entities), which an agent facing a destructive call would benefit from knowing.

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

Parameters3/5

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

Schema description coverage is 100%, with topic_id, account, and confirm all documented in the schema itself. The description restates the confirm requirement but adds no syntax or format meaning beyond what the schema provides, so the baseline 3 applies.

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?

States a specific verb+resource ('Delete a topic') that unambiguously distinguishes it from sibling create_topic, update_topic, and get_topic. No sibling is named, but the name/verb pairing leaves no ambiguity about what it does.

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

Usage Guidelines3/5

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

The confirm=true clause implies a when-to-use condition (only for user-requested deletion), which is a genuine usage hint. However, no alternatives (e.g. archive vs delete) or prerequisites are described, so guidance remains implied rather than explicit.

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

duplicate_community_segmentDuplicate a community segmentB

Destructive

Duplicate a community segment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`title`	Yes	Title for the duplicated community segment
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`segment_id`	Yes	ID of the community segment to duplicate

TDQS

B3.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the mutation and irreversibility profile is covered structurally. The description adds the confirmation gate ('Changes community state and requires confirm=true'), which is useful but overlaps the confirm parameter description, and it says nothing about what the duplicate copies or whether the source segment is affected.

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?

Two short sentences, front-loaded with the operation and followed by the confirmation constraint. No wasted words, though the second sentence is somewhat terse.

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?

No output schema, so the description does not need to explain return values, and annotations plus the schema cover safety and parameters. However, for a destructive duplicate operation the definition omits what the new segment inherits and whether the source is untouched, leaving a moderate gap.

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

Parameters3/5

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

Schema description coverage is 100%, so both required and optional parameters are documented in the schema itself. The description adds no parameter-level detail (e.g., what is copied vs. overridden by the new title), so the baseline of 3 applies.

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?

States a specific verb ('duplicate') and resource ('community segment'), so an agent can distinguish it from create_community_segment, update_community_segment, and delete_community_segment. It stops short of explicitly differentiating itself from those siblings, but the operation 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 Guidelines3/5

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

The description notes that confirm=true is required 'for the user-requested action,' which implies a usage precondition. It offers no guidance on when to duplicate vs. create a new segment, or any other alternative, so the guidance is only partial.

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

duplicate_eventDuplicate EventC

Destructive

Duplicate Event. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`event`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`event_id`	Yes	Event ID
`space_id`	Yes	Space ID
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false and destructiveHint=true, so the mutation profile is covered structurally. The description adds the useful confirm=true gate, which is genuine context beyond the annotations, but it omits what the duplicate copies (attendees, content) and how the source event relates to the target space.

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

Conciseness2/5

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

It is short, but the first sentence is pure filler restating the title. This is under-specification disguised as brevity — the space saved is spent nowhere useful.

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

Completeness2/5

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

For a 7-parameter, nested-object mutation tool with no output schema, this is inadequate: it never explains that event_id identifies the source and event.space_id the destination, nor how payload, payload_file, and the body flags interact (the schema forbids mixing them).

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

Parameters3/5

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

Schema description coverage is 86%, so the schema already documents confirm, event_id, space_id, account, and the payload/payload_file alternatives. The description's confirm note merely restates the schema's own wording and adds nothing about the event_id-to-event.space_id relationship or the payload vs payload_file choice.

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

Purpose2/5

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

The first sentence, "Duplicate Event," is a tautology that simply restates the tool title. The only other content — "Changes community state and requires confirm=true" — is behavioral, not purpose, so the description never states what is being duplicated or how it differs from siblings like duplicate_form, duplicate_workflow, or duplicate_image_post.

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

Usage Guidelines2/5

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

There is no guidance on when to use duplicate_event versus update_event or create_event. The phrase "for the user-requested action" gestures at when to set confirm, but it does not tell the agent which action, nor any prerequisites or exclusions.

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

duplicate_formDuplicate a formA

Destructive

Duplicate a form. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	ID of the form to duplicate

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds real value beyond that by disclosing that the operation changes community state and requires confirm=true, an operational gate not visible in annotations.

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?

Two short sentences with the action stated first and the state-change/confirmation requirement immediately after. Nothing is padded or redundant.

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 a form-duplication tool with full annotation coverage and no output schema, the definition gives the agent enough to call it correctly, including the confirmation gate. It stops short of describing what the duplicate inherits (settings, submissions, naming), which would be useful but is not strictly required to invoke it.

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

Parameters3/5

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

Schema description coverage is 100%, including a note that 'account' selects credentials rather than a remote ID, so the schema does the heavy lifting. The description only reinforces the confirm semantics already documented in the schema, adding no new parameter detail — baseline 3 applies.

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 and resource ('Duplicate a form'), which cleanly separates it from create_form, update_form, and delete_form. It doesn't need to name a sibling explicitly because the resource noun does the differentiating within a large duplicate_* family already present in the toolset.

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

Usage Guidelines3/5

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

The confirm=true clause implies this is a user-requested action, but there is no explicit when-to-use guidance relative to create_form (e.g., 'use this instead of recreating a form manually') and no stated prerequisites beyond confirmation. Usage is inferable but not spelled out.

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

duplicate_image_postDuplicate Image PostC

Destructive

Duplicate Image Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`post`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`post_id`	Yes	Image post ID
`space_id`	Yes	Image space ID
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, idempotentHint=false, openWorldHint=true, and readOnlyHint=false, so the mutation and non-idempotency profile is covered. "Changes community state" is vague and adds little beyond that, though the confirm=true gating is a useful behavioral constraint (albeit mirrored in the schema). Nothing here discloses what is copied, what is created, or permission requirements.

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?

Two short sentences with no padding, front-loaded with the action and followed by the gating constraint. Efficient, though the first sentence is pure name restatement and earns little.

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

Completeness2/5

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

For a 7-parameter, nested-object destructive mutation with no output schema, the description is thin: it omits what the duplication produces, how account selection and confirm interact with the payload/payload_file/body-flag options, and any permission requirements. High schema coverage and the safety annotations partially compensate, but the description does not.

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

Parameters3/5

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

Schema description coverage is 86%, so the schema already documents the parameters well, establishing the baseline of 3. The description's only parameter note (confirm=true) duplicates the schema's own confirm description and adds no syntax, format, or interaction detail (e.g., how payload, payload_file, and body flags interact).

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

Purpose3/5

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

The description's first sentence, "Duplicate Image Post," simply restates the tool name/title and adds no semantic detail beyond it. An agent can infer this creates a copy of an existing image post, but nothing distinguishes it from siblings like create_image_post, duplicate_event, or duplicate_form. It is minimally clear but goes no further.

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

Usage Guidelines2/5

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

The only usage-relevant claim is that confirm=true is required, which the schema already documents verbatim for the confirm parameter. There is no guidance on when to choose this over create_image_post or update_post, and no prerequisites or exclusions are offered.

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

duplicate_workflowDuplicate a workflowA

Destructive

Duplicate a workflow. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`id`	Yes	UUID of the workflow to duplicate
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.

TDQS

A3.7/5.0

Behavior4/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, openWorldHint=true, and idempotentHint=false. The description adds the non-obvious confirmation guard ('requires confirm=true for the user-requested action') and notes that community state changes, which goes beyond the structured fields. It does not say what the duplicate inherits or whether the original is untouched, so it falls short of a 5.

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?

Two short sentences with the purpose front-loaded and no filler. The phrasing 'for the user-requested action' is slightly vague but does not bloat the text.

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?

With no output schema, the description could ideally say what the returned duplicate looks like or how it is named, but the safety profile is fully carried by annotations and the confirm prerequisite is disclosed. Nearly complete for a simple duplication tool.

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

Parameters3/5

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

Schema description coverage is 100%, so all three parameters are already documented in the schema. The description only reinforces the confirm semantics, adding no syntax or format detail beyond that. Baseline 3 applies when the schema does the work.

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?

States a specific verb and resource (duplicate a workflow), which is clear enough to distinguish it from sibling duplicators like duplicate_event and duplicate_form by resource. It does not explicitly differentiate itself from those siblings, so it lands just below the top score.

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

Usage Guidelines3/5

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

The description hints at a pre-condition for invocation (confirm=true for the user-requested action) but gives no guidance on when to choose this over alternatives or on any prerequisites like source workflow state. Usage is implied rather than explained.

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

export_community_member_chargesExport Community Member ChargesB

Destructive

Export Community Member Charges. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`fields`	No	Comma-separated list of CSV columns to include
`status`	No	Comma-separated list of statuses (e.g. paid,refunded,partial_refunded)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`currency`	No	Comma-separated list of currency codes
`platform`	No	Comma-separated list of platforms (web, app_store, play_store)
`timezone`	No	Timezone used to render dates in the CSV (defaults to Etc/UTC)
`amount_gte`	No	Minimum charge amount (in currency subunits)
`amount_lte`	No	Maximum charge amount (in currency subunits)
`paywall_ids`	No	Comma-separated list of paywall IDs
`member_email`	No	Filter by community member email (partial match)
`processor_id`	No	Filter by exact processor (charge) ID
`created_at_gte`	No	Only include charges created on/after this date (ISO8601)
`created_at_lte`	No	Only include charges created on/before this date (ISO8601)
`paywall_price_type`	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`community_member_id`	No	Filter by community member ID
`invoice_processor_id`	No	Filter by exact invoice processor ID
`subscription_processor_id`	No	Filter by exact subscription processor ID
`billing_info_business_name`	No	Filter by billing info business name (partial match)
`community_member_public_uid`	No	Filter by community member public UID

TDQS

B3.2/5.0

Behavior4/5

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

Annotations declare readOnlyHint=false, destructiveHint=true and idempotentHint=false, so the agent knows this mutates. The description adds a valuable, non-obvious disclosure that an 'export' actually changes community state and requires an explicit confirm=true, reconciling the surprising safety profile. It stops short of saying what state is changed or whether the export is reversible.

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

Conciseness3/5

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

Two sentences, appropriately short and front-loaded, but the first is pure title repetition and earns no place. The behavioral warning is placed second, which is reasonable, but half the description is redundant.

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?

With 20 optional parameters and no output schema, the description leaves the agent without any sense of what the export returns (presumably a CSV governed by the fields parameter) or how the result is delivered. The critical confirm/state-change behavior is covered, so it is minimally complete but not rich.

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

Parameters3/5

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

Schema description coverage is 100%, so all 20 parameters (fields, status, date filters, amount bounds, etc.) are already documented in the schema. The description adds no syntax, format, or defaulting detail beyond it. Baseline 3 applies when the schema carries the full parameter burden.

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

Purpose3/5

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

The first sentence is a verbatim restatement of the title ('Export Community Member Charges'), which is tautological. The second sentence adds that it is a state-changing operation, which is genuinely informative, but the description never distinguishes this tool from the very similar sibling export_community_member_subscriptions or from list_charges. Purpose is discernible but not differentiated.

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

Usage Guidelines3/5

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

It gives one concrete usage rule — confirm=true is required, and only when the user asked for exactly this action — which mirrors the schema's confirm description. However, there is no guidance on when to choose this export over export_community_member_subscriptions or list_charges, and no prerequisites or filtering context.

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

export_community_member_subscriptionsExport Community Member SubscriptionsB

Destructive

Export Community Member Subscriptions. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`fields`	No	Comma-separated list of CSV columns to include
`status`	No	Comma-separated list of statuses (e.g. active,trial,canceled)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`currency`	No	Comma-separated list of currency codes
`platform`	No	Comma-separated list of platforms (web, app_store, play_store)
`timezone`	No	Timezone used to render dates in the CSV (defaults to Etc/UTC)
`paywall_ids`	No	Comma-separated list of paywall IDs
`member_email`	No	Filter by community member email (partial match)
`start_date_gte`	No	Only include subscriptions started on/after this date (ISO8601)
`start_date_lte`	No	Only include subscriptions started on/before this date (ISO8601)
`billing_interval`	No	Filter by paywall price billing interval (e.g. month, year)
`paywall_price_type`	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`community_member_id`	No	Filter by community member ID
`scheduled_to_cancel`	No	Filter by whether the subscription is scheduled to cancel
`total_amount_paid_gte`	No	Minimum total amount paid (in currency subunits)
`total_amount_paid_lte`	No	Maximum total amount paid (in currency subunits)
`subscription_processor_id`	No	Filter by exact subscription processor ID
`billing_info_business_name`	No	Filter by billing info business name (partial match)
`community_member_public_uid`	No	Filter by community member public UID

TDQS

B3.3/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false and openWorldHint=true. The description usefully reconciles the misleading 'Export' name by stating it 'changes community state' and adds the confirm gate as required context, but it never says what is destroyed or altered, nor what the export actually returns.

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?

Two short sentences, front-loaded with the resource and immediately followed by the mutation/confirm constraint. No wasted words, though the second clause is somewhat boilerplate.

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

Completeness2/5

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

For a 20-parameter export tool with no output schema and a near-identical sibling (export_community_member_charges), the description omits output format, whether the export is synchronous, and what state the mutation actually affects. It is too thin given the tool's complexity.

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

Parameters3/5

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

All 20 parameters have full schema descriptions, so the schema already carries the meaning and baseline is 3. The description adds nothing about filters, defaults, or the CSV column semantics beyond what the schema documents.

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?

Names a specific verb (Export) and resource (Community Member Subscriptions), which is enough to separate it from most siblings. However it does not distinguish itself from the closely related export_community_member_charges, and 'Export' suggests a plain read while the tool actually mutates state.

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

Usage Guidelines3/5

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

It states the confirm=true gate is tied to a user-requested action, which is a usable invocation rule. But there is no guidance on when to prefer this over list_subscriptions, export_community_member_charges, or other alternatives.

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

export_paywall_affiliate_payoutsExport Paywall Affiliate PayoutsC

Destructive

Export Paywall Affiliate Payouts. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_member_ids`	No	Community member IDs to scope the export to (max 20 per request). Omit to export all processing payouts.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds the useful, non-obvious fact that the call requires confirm=true, but it never explains what the destructive aspect actually does (what state changes, what is exported, where the export lands), leaving the most consequential behavior unexplained.

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?

Two short sentences with the action stated first and the confirmation requirement second; nothing is padded. It is efficient, though the first sentence is pure duplication of the title rather than new information.

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

Completeness2/5

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

For a destructive, non-idempotent, open-world tool with no output schema and a nested payload object, the description is too thin: it never explains what the export produces, where results go, or what 'changes community state' means for payouts. An agent would have to guess at the observable outcome of the call.

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

Parameters3/5

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

Schema description coverage is 100%, so all five parameters are documented in the schema, including the account/credential distinction, the max-20 community_member_ids scoping, and the payload vs payload_file mutual exclusion. The description adds no parameter meaning beyond the schema, so the baseline of 3 applies.

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

Purpose3/5

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

The description states a verb ('Export') and a resource ('Paywall Affiliate Payouts'), but the first sentence is a verbatim restatement of the tool title and adds no scope detail. It does nothing to distinguish this export from siblings such as start_paywall_affiliate_payouts, mark_paywall_affiliate_payouts_paid, or list_paywall_affiliates, so the agent cannot tell which payout-related tool to pick from the description alone.

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

Usage Guidelines2/5

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

The only guidance is the confirm=true gate, which is an execution precondition rather than a statement of when this tool is appropriate versus its payout siblings. There is no mention of when to use export vs list or vs the start/mark-paid flows, and no exclusions.

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

get_access_group_community_memberShow Access Group Community MemberC

Read-onlyIdempotent

Show Access Group Community Member. Reads community data.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`access_group_id`	Yes	Access Group ID

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered by structured data. The description's only behavioral claim, 'Reads community data', merely duplicates readOnlyHint and adds nothing about what is fetched or what authorization context is required.

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

Conciseness3/5

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

Two short, front-loaded sentences with no padding, so it is not verbose. However the second sentence does not earn its place because it carries no information beyond what the annotations and title already convey.

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

Completeness2/5

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

With no output schema, the description should at least indicate what a member record returns or how access_group_id plus email identify it, and it says nothing. Annotations cover the safety profile, but the retrieval semantics remain unexplained for a three-parameter, two-required lookup.

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

Parameters3/5

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

Schema description coverage is 100%, with all three parameters documented (including the useful 'account' note about named private Circle accounts). That establishes the baseline of 3, and the description contributes no additional parameter meaning beyond the schema.

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

Purpose2/5

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

The description is essentially the title with a trailing clause: 'Show Access Group Community Member. Reads community data.' It restates the name rather than stating a distinct verb+resource outcome. It also fails to differentiate from close siblings such as get_member, list_access_group_community_members, and add_to_access_group.

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

Usage Guidelines2/5

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

There is no guidance on when to use this instead of get_member or list_access_group_community_members, and no prerequisites or exclusions are given. The only hint of usage is the vague word 'Reads', which implies retrieval but selects nothing.

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

get_commentShow CommentC

Read-onlyIdempotent

Show Comment. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`comment_id`	Yes

TDQS

C2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. "Reads community data" merely repeats the readOnly annotation and adds no new behavioral context such as auth requirements or behavior when the comment is missing.

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

Conciseness2/5

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

The two short fragments are economical but amount to under-specification rather than conciseness. Nothing is front-loaded because there is essentially no content to load.

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

Completeness2/5

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

With no output schema, the description should at least hint at what a fetched comment contains or include constraints on comment_id lookup. As written it is nearly empty for a tool with a required, undocumented identifier parameter.

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 only 50%: the account parameter is documented but comment_id is not. The description supplies no parameter meaning at all, so it fails to compensate for the undocumented required comment_id.

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

Purpose2/5

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

"Show Comment" simply restates the tool name and title, which is tautological. "Reads community data" is a vague generic statement that does not identify the resource type (comment) or distinguish this from list_comments, create_comment, or get_post.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus its obvious siblings (list_comments, create_comment, delete_comment). No prerequisites, no conditions, no exclusions are stated.

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

get_communityGet community detailsC

Read-onlyIdempotent

Get community details. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so safety is fully covered. The description's only behavioral claim ("Reads community data") merely restates readOnlyHint and adds no new context such as auth requirements or what the read returns.

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

Conciseness3/5

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

The description is short and front-loaded, but the second sentence ("Reads community data") is pure redundancy for an operation already flagged readOnlyHint. It does not earn its place.

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 parameterless-input read tool with full annotation coverage and no output schema, the definition is minimally viable but leaves "community details" undefined and gives no hint about what is returned or whether it requires an account context.

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

Parameters3/5

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

Schema description coverage is 100% and the single parameter has a strong description clarifying that "account" selects credentials rather than a remote community ID. The tool description itself contributes nothing to parameter meaning, so the baseline 3 applies.

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

Purpose3/5

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

States a specific verb and resource ("Get community details"), so the agent knows it is a read of community data. However, it offers no differentiation from siblings such as update_community, list_accounts, or the many other community-scoped getters, and the second sentence adds nothing.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, no prerequisites, and no mention of the account parameter's role in selection. The agent must infer usage entirely from the name.

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

get_connect_settingsGet Connect settingsC

Read-onlyIdempotent

Get Connect settings. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.2/5.0

Behavior2/5

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

Annotations already declare readOnly, idempotent, non-destructive and openWorld. The description adds only 'Reads community data', which is consistent but vague and adds essentially nothing about auth, scope, or what open-world access means here.

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

Conciseness2/5

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

It is short and front-loaded, but the second sentence is a vague filler that does not earn its place, and the overall brevity leaves the tool under-specified rather than concise.

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

Completeness2/5

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

With no output schema, the description should convey what the returned settings contain, but it only says 'Reads community data'. For a settings-retrieval tool it leaves the agent without enough to know what it will get back.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema already documents the single optional 'account' parameter and its credential-selection semantics. The description adds no parameter detail, so the baseline of 3 applies.

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

Purpose2/5

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

The first sentence is a verbatim restatement of the tool name and title, and the second sentence ('Reads community data') is too generic to clarify what 'Connect settings' actually are. It names a resource but does not distinguish this from the sibling update_connect_settings or explain what settings are retrieved.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of the sibling update_connect_settings that would be the mutating alternative. The agent must infer usage entirely from the name.

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

get_course_lessonShow a course lessonB

Read-onlyIdempotent

Show a course lesson. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`lesson_id`	Yes	ID of the course lesson

TDQS

B3.2/5.0

Behavior3/5

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

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is fully covered. The description adds only a vague scope note ("reads community data") and says nothing about auth requirements, rate limits, or which lesson fields come back. Modest value on top of rich annotations.

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?

Two very short sentences with the purpose front-loaded and no padding. However, "Reads community data" earns little and the overall terseness trends toward under-specification rather than genuine concision.

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 2-parameter read-only tool with no output schema and strong annotations, this is close to adequate, but it never says what a fetched lesson contains (video, text, section linkage) or whether the account resolves community scope. An agent can call it, but with more inference than necessary.

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

Parameters3/5

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

Schema description coverage is 100%: lesson_id is documented as the lesson ID and account as a named private Circle account selecting credentials. The description adds no parameter semantics, so the baseline 3 applies.

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?

"Show a course lesson" gives a specific verb plus resource, and the singular "lesson" naturally separates it from list_course_lessons and the create/update/delete_course_lesson siblings. It stops short of explicitly naming how it differs from get_course_section, so it is clear but not fully differentiated.

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

Usage Guidelines2/5

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

No when-to-use guidance is given: nothing says to pick this over list_course_lessons (to browse) or update_course_lesson (to edit). "Reads community data" describes mechanics, not the condition or context for invoking the tool.

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

get_course_sectionShow a course sectionC

Read-onlyIdempotent

Show a course section. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`section_id`	Yes	ID of the course section

TDQS

C2.9/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, covering the safety profile fully. 'Reads community data' restates the readOnly hint and adds nothing about credential resolution, response shape, or failure modes.

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?

Two short sentences with the tool purpose front-loaded and no padding. However, the second sentence is close to content-free, so it is concise without being maximally informative.

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?

A simple two-parameter read tool whose schema, annotations, and rich sibling set carry most of the load, so minimal prose is tolerable. Still, there is no return-value expectation or relationship to course/lesson hierarchy, leaving the description adequate at best.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (account, section_id) are already documented in the schema, including the non-obvious point that 'account' selects credentials rather than a remote ID. The description adds no parameter meaning, which is the baseline expectation.

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?

States a specific verb ('Show') and resource ('a course section'), so it is distinguishable from the singular/plural sibling list_course_sections. It does not explicitly name that sibling, so it stops short of a 5.

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

Usage Guidelines2/5

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

No when-to-use guidance and no mention of alternatives such as list_course_sections (for enumerating) or update_course_section (for mutation). The agent must infer the retrieval use case from the verb alone.

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

get_embedGet EmbedC

Read-onlyIdempotent

Get Embed. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`sgid`	Yes	The sgid of the embed
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered by structured data. The description's "Reads community data" adds nothing beyond that, not even which fields come back or whether the embed is public.

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

Conciseness3/5

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

Only two short sentences, so nothing is bloated and it is front-loaded, but the first sentence is pure duplication of the title and the second carries no information, leaving it under-specified rather than genuinely concise.

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

Completeness2/5

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

No output schema and no annotations explaining return behavior, yet the description never says what a fetched embed contains or what the sgid identifier refers to. For a two-parameter read tool, an agent has to guess at the result shape.

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

Parameters3/5

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

Schema description coverage is 100%: sgid is documented in the schema and the account parameter's semantics (selects credentials, not a remote community ID) are unusually well explained in the schema itself. The description adds no parameter meaning, so the baseline 3 applies.

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

Purpose2/5

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

"Get Embed" merely restates the tool name/title, and "Reads community data" is too vague to distinguish this from siblings like get_community, get_post, or get_space. Nothing identifies what an "embed" is or which resource is fetched.

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

Usage Guidelines1/5

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

No when-to-use, when-not-to-use, or alternative is given. With ~120 siblings including create_embed and get_community, the agent gets no routing help at all.

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

get_eventGet EventC

Read-onlyIdempotent

Get Event. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`event_id`	Yes	Event ID

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no note on what is returned, whether the read is scoped to the account credential, or error behavior for unknown event IDs.

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

Conciseness3/5

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

Two short fragments with no padding, so it is certainly concise and front-loaded. However, the brevity is achieved by omitting content rather than by economy, leaving the structure technically clean but uninformative.

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

Completeness2/5

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

For a simple 2-parameter read tool with no output schema, the description should at minimum say what an event object represents or where the event_id comes from. Given no output schema exists, the description is the only place a return-shape hint could live, and it supplies none.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented — including the useful 'account selects credentials, not a remote community ID' note in the schema itself. The description contributes no additional parameter meaning, which is the baseline 3 case.

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

Purpose2/5

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

The description is essentially a restatement of the title 'Get Event' plus the vague filler 'Reads community data.' It does not distinguish this tool from the many other getters in the sibling list (get_member, get_post, get_space, get_comment), and 'community data' tells the agent nothing about what an event record contains.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus list_events, update_event, delete_event, or list_event_attendees. No prerequisites, no mention of the required event_id being sourced from a prior list call. The agent gets zero routing help.

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

get_filter_configurationGet the filters currently shown on the member directory or a member spaceB

Read-onlyIdempotent

Get the filters currently shown on the member directory or a member space. Reads community data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`context`	Yes	Surface to inspect. Use member_directory for the community directory or member_space for a specific members space.
`space_id`	No	Members space ID. Required when context is member_space.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and non-destructive. The description adds 'currently shown', implying the returned filters reflect the live UI state rather than persisted configuration, which is a useful behavioral nuance. It does not add further details like permissions or output shape, so it only modestly surpasses the annotation baseline.

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?

Two short sentences, front-loaded with the action and scope. The second sentence 'Reads community data' is somewhat redundant with the annotations but not harmful.

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 a simple read tool with full schema coverage and safety annotations, the description covers what is fetched and where. It does not need to explain return values (no output schema), and the conditional space_id requirement is documented in the schema.

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

Parameters3/5

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

Schema coverage is 100%, so the schema fully documents context, space_id, and account. The description adds no parameter syntax or format information, so baseline 3 is appropriate.

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 'Get' and resource 'filters currently shown on the member directory or a member space', so the agent knows what it returns. However, it does not distinguish this tool from siblings like get_filter_control or list_filter_controls, which also deal with filters.

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

Usage Guidelines2/5

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

No guidance on when to use this versus get_filter_control or list_filter_controls. The only extra sentence, 'Reads community data', is not usage context and leaves the agent to infer the appropriate scenario.

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

get_filter_controlGet a filter controlB

Read-onlyIdempotent

Get a filter control. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`filter_control_id`	Yes	Filter control ID

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds little behavioral context beyond confirming that it reads community data, but it does not contradict the annotations and provides a minimum of useful scoping information.

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?

The description is very short and front-loaded with the core action. However, the first sentence largely repeats the tool title and name, so it earns less than a maximally efficient definition would.

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 simple two-parameter read tool with rich annotations and full schema coverage, the description is minimally adequate. It omits when-to-use guidance and any indication of the returned filter control, though no output schema exists to cover return semantics.

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

Parameters3/5

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

Schema description coverage is 100%, so all parameter meaning is already documented in the input schema. The description adds no parameter-level detail beyond what the schema provides, making the baseline score of 3 appropriate.

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 clear verb+resource ('Get a filter control') and adds a data-scope note ('Reads community data'). It is specific enough to identify the operation, but it does not explicitly differentiate this tool from siblings like get_filter_configuration or list_filter_controls.

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

Usage Guidelines2/5

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

There is no guidance about when to use this tool versus alternatives such as list_filter_controls, get_filter_configuration, or update_filter_control. The only usage-like phrase, 'Reads community data,' indicates the data domain but not selection criteria.

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

get_formShow a formC

Read-onlyIdempotent

Show a form. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`form_id`	Yes	Form ID

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered by structured data. "Reads community data" largely duplicates readOnlyHint and adds no new behavioral detail such as which community/account context is resolved or what is returned.

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

Conciseness3/5

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

Two very short sentences, front-loaded, with no wasted words. However, the brevity reflects under-specification rather than efficient information density; it is minimal but thin.

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

Completeness2/5

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

The tool is simple (2 params, no output schema) and annotations carry the safety profile, but the description omits any differentiation from the cluster of form-related siblings (list_forms, update_form, delete_form, duplicate_form, get_form_submissions). An agent would have to guess this is the single-form fetch rather than a list or submission endpoint.

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

Parameters3/5

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

Schema description coverage is 100%: form_id and account are both documented in the schema, including the useful note that account selects credentials rather than a remote community ID. The description adds nothing about parameters, so the baseline of 3 applies.

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

Purpose2/5

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

"Show a form" merely restates the tool name and title (get_form / "Show a form") without a distinct verb-resource relationship an agent can act on. "Reads community data" hints at scope but does not say what a "form" is or how this differs from siblings like list_forms or get_form_submissions. It is close to a tautology.

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool versus alternatives such as list_forms, get_form_submissions, update_form, or duplicate_form, all of which are present in the sibling list. No prerequisites, no exclusions, no context.

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

get_form_submissionsList form submissionsB

Read-onlyIdempotent

List form submissions. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`form_id`	Yes	Form ID
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, destructiveHint=false, covering the safety profile. The description adds the quota/proxy caveat ('every page counts against the API quota') and mentions community data, but omits pagination semantics, error behavior, and rate limits beyond the quota note.

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?

Three short sentences, front-loaded with the purpose. Minimal waste, though the quota note repeats a point already made in the all_pages schema description.

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 read-only list tool with full annotation coverage and full schema coverage, the description is adequate but thin. It lacks return shape hints, pagination continuation guidance (mentioned only in schema for max_items), and does not help the agent choose between this and sibling form tools.

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

Parameters3/5

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

Schema description coverage is 100%, so the schema carries the parameter documentation burden. The description's mention of 'bounded all_pages' adds minor context but is largely redundant with the schema's own description of all_pages.

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?

States a specific verb+resource ('List form submissions'), which is clear on its own. It doesn't explicitly distinguish itself from sibling list_forms or get_form, but the resource (submissions) is distinct enough that an agent can infer differentiation.

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

Usage Guidelines2/5

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

No indication of when to use this vs. siblings like list_forms or get_form, no prerequisites, no exclusions. The only usage hint is the note about all_pages quota consumption, which is behavioral rather than routing guidance.

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

get_image_postShow Image PostC

Read-onlyIdempotent

Show Image Post. Reads community data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`post_id`	Yes	Image post ID
`space_id`	Yes	Image space ID

TDQS

C2.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered elsewhere. The lone sentence "Reads community data" adds no behavioral context beyond what the annotations provide — no note on required permissions, error behavior, or what a missing post returns.

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

Conciseness2/5

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

Two short fragments are brief but not concise in the meaningful sense — they are under-specified rather than efficient. Neither sentence carries information the agent can act on.

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

Completeness2/5

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

For a tool requiring both space_id and post_id with no output schema, the description should at least hint at what is retrieved (media, caption, author, comments). Instead it provides nothing an agent needs beyond what the name and schema already imply.

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

Parameters3/5

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

Schema description coverage is 100% (account, post_id, space_id are all documented, including the non-obvious note that account selects credentials rather than a community ID). With the schema doing all the work, the description's silence on parameters meets the baseline of 3 but adds no value.

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

Purpose2/5

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

"Show Image Post" merely restates the tool name and title, and "Reads community data" is a vague generic gloss that applies to dozens of siblings. Nothing distinguishes it from get_post, list_image_posts, or duplicate_image_post.

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

Usage Guidelines2/5

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

There is no when-to-use guidance at all — no mention of when to prefer this over list_image_posts (for enumeration) or get_post (for text posts). The agent is left to infer the context entirely from the name.

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

get_leaderboardShow LeaderboardC

Read-onlyIdempotent

Show Leaderboard. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`period`	No	Leaderboard period, default is all time
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive and open-world behavior, so "Reads community data" adds nothing beyond the structured fields. No mention of scope of data returned, whether results are public vs. credentialed, pagination, or result size.

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

Conciseness3/5

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

At two short sentences it is certainly concise and front-loaded, but the second sentence ("Reads community data") is pure filler that duplicates the readOnly annotation and earns no place. Brevity here reflects under-specification rather than efficiency.

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

Completeness2/5

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

With two parameters, no output schema, and no annotations covering what the leaderboard actually contains, the description should explain what is being ranked and what the periods mean. It explains neither, leaving the agent unable to judge relevance or interpret results.

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

Parameters3/5

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

Schema description coverage is 100% – the schema explains the period enum's default (all time) and clarifies that account selects credentials rather than a community ID. The description adds no parameter meaning, so the baseline 3 for fully documented schemas applies.

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

Purpose2/5

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

"Show Leaderboard" simply restates the tool name and title, and "Reads community data" is a generic add-on that could describe almost any tool in this server. Nothing distinguishes it from siblings like get_member or list_members, and the resource being ranked is never named (members? posts? courses?).

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

Usage Guidelines1/5

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

There is no guidance on when to use this tool, when not to, or what alternative exists. An agent cannot infer from this text whether the leaderboard covers engagement, spending, or course progress, or in which context it should be requested.

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

get_memberShow a community memberC

Read-onlyIdempotent

Show a community member. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`member_id`	Yes	ID of the community member

TDQS

C2.6/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false, and openWorldHint, so the safety profile is fully covered structurally. The added sentence 'Reads community data' merely restates what readOnlyHint already states and discloses nothing beyond it (no per-account scoping behavior, no lookup failure semantics).

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

Conciseness3/5

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

It is short and front-loaded, which is good, but the second sentence is pure redundancy against the annotations and does not earn its place. The definition is under-specified rather than efficiently concise.

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 simple read tool with full annotation coverage, a complete schema, and no output schema, a minimal description is tolerable. Still, it omits any routing context among the numerous member-related siblings, leaving the agent to disambiguate from names alone.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (account and member_id) are already documented in the schema, including the account-selects-credentials nuance. The description adds no parameter meaning, so the baseline 3 applies.

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

Purpose3/5

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

The description conveys a retrieve operation on a single community member, so the verb+resource are identifiable. However, 'Show a community member' nearly restates the title, and it does nothing to distinguish this tool from siblings like get_community_member, search_member, or list_members.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of alternatives, and no prerequisites. An agent cannot tell from the text why it would call get_member versus search_member or list_members; it must infer from the name alone.

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

get_member_tagShows a member tag's detailsC

Read-onlyIdempotent

Shows a member tag's details. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`tag_id`	Yes	Member tag ID
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.9/5.0

Behavior2/5

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

The annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description's 'Reads community data' largely restates the read-only nature without adding new behavioral context such as permissions required, error behavior, or rate limits.

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?

The description is short and front-loaded with the core action. The second sentence, 'Reads community data,' is somewhat redundant but does not bloat the definition.

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 simple read-by-ID tool with full schema coverage and rich annotations, the description is minimally adequate. However, it omits usage guidance and sibling differentiation, which leaves an agent with some ambiguity in tool selection.

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

Parameters3/5

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

Schema description coverage is 100%, and both parameters are fully documented in the schema. The description adds no parameter-level meaning beyond what the schema already provides, so the baseline score of 3 applies.

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 clear verb and resource: 'Shows a member tag's details.' It is easy to distinguish from siblings like create_member_tag, update_member_tag, and delete_member_tag, though it does not explicitly differentiate itself from list_member_tags or get_tagged_member.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives such as list_member_tags or get_tagged_member. It also lacks any exclusions or prerequisite context, leaving the agent to infer usage entirely from the name.

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

get_payment_method_settingsRetrieves the community's payment method preferencesC

Read-onlyIdempotent

Retrieves the community's payment method preferences. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.9/5.0

Behavior2/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety and idempotency profile is fully covered. The description adds 'Reads community data,' which is a generic restatement rather than new behavioral context like authentication requirements, rate limits, or return format.

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?

The description is two short sentences, front-loaded with the core purpose. The second sentence 'Reads community data' is somewhat redundant given the verb 'Retrieves' and the readOnlyHint, but it is brief and not harmful.

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?

With no output schema, the description should ideally explain return values or structure, but it does not. Annotations cover the safety profile, and the parameter is documented, so the definition is minimally adequate but leaves gaps in explaining what the tool returns or any constraints.

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

Parameters3/5

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

Schema description coverage is 100%, and the single parameter 'account' is fully documented in the schema. The description does not mention the parameter, so it adds no meaning beyond the schema, but the baseline is 3 when schema coverage is high.

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 clearly states a specific verb (Retrieves) and resource (community's payment method preferences), matching the title. However, it does not differentiate from any sibling tools, as no other tool in the list handles payment method preferences, leaving it without explicit sibling differentiation.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. There is no mention of prerequisites, context, or exclusion criteria, leaving usage entirely to inference.

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

get_postShow Basic PostC

Read-onlyIdempotent

Show Basic Post. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`post_id`	Yes	Post ID

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so safety is covered structurally. The description adds nothing beyond that — no auth requirements, no scoping (e.g., which community the post belongs to), no error behavior, no note on what 'basic' excludes.

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

Conciseness3/5

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

It is short and front-loaded, but the second sentence ('Reads community data') carries no informational weight. Brevity here reflects under-specification rather than disciplined conciseness.

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

Completeness2/5

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

With no output schema, the description should convey what post fields are returned and what 'basic' means versus the summary sibling. It provides none of that, leaving the agent unable to anticipate the response for a read tool.

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

Parameters3/5

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

Schema description coverage is 100%, with post_id and the account credential-selection nuance both documented in the schema, so the baseline is 3. The description adds no parameter meaning beyond the schema.

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

Purpose2/5

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

The description restates the title ('Show Basic Post') with a generic tagline ('Reads community data'), which is essentially a tautology. While 'get_post' indicates a retrieve-a-post operation, nothing distinguishes it from siblings like get_post_summary, list_posts, or get_image_post.

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

Usage Guidelines1/5

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

There is no when-to-use, when-not-to-use, or alternative-selection guidance at all. The agent has no basis for choosing get_post over list_posts or get_post_summary.

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

get_post_summaryGet Post SummaryC

Read-onlyIdempotent

Get Post Summary. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`post_id`	Yes	Post ID

TDQS

C2.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false. The description adds no behavioral context beyond restating that it reads data, such as auth requirements, rate limits, or what happens with private versus public posts.

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

Conciseness2/5

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

The description is very short, but the second sentence "Reads community data" is vague and does not earn its place. It is under-specified rather than appropriately concise.

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

Completeness2/5

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

For a read tool with no output schema, the description should clarify what a "post summary" contains or when to request it. Instead it gives no return-value context and no usage context, leaving the agent to infer everything from the schema and annotations.

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

Parameters3/5

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

Schema description coverage is 100%, and both parameters are documented in the input schema. The description adds no meaning beyond the schema, so the baseline of 3 applies.

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

Purpose2/5

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

The description repeats the title ("Get Post Summary") and adds only the vague phrase "Reads community data." It does not specify what kind of summary is returned, nor does it distinguish this tool from siblings like get_post or list_posts.

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

Usage Guidelines2/5

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

There is no guidance on when to use get_post_summary versus get_post, list_posts, or any other sibling. The only usage signal is the generic verb "Reads," which does not explain context, prerequisites, or alternatives.

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

get_spaceShow a spaceC

Read-onlyIdempotent

Show a space. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`space_id`	Yes	Space ID

TDQS

C2.7/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint, so safety is covered. The only added phrase, "Reads community data," is vague and adds no behavioral detail such as authentication, error behavior when the ID is missing, or scope of data returned. Minimal value beyond annotations.

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?

Two short sentences, front-loaded with the operation, with no wasted words. It is efficient, though the brevity comes at the cost of substance rather than being elegantly dense.

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 simple read tool with fully documented parameters and no output schema, the description is minimally sufficient. However, it never states what the response contains or the identity of the "account"-scoped context, leaving the agent to rely entirely on schema and annotations.

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

Parameters3/5

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

Schema description coverage is 100%, so account and space_id are already documented in the schema (account even notes it selects credentials, not a remote community ID). The description adds nothing beyond this, so the baseline of 3 applies.

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

Purpose3/5

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

"Show a space" restates the title with a verb+resource, so the basic operation is discernible, but it does not explain what a space is, what is returned, or how it differs from siblings like get_space_group, list_spaces, or get_space_member. "Reads community data" is vague filler that adds no real specificity.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_spaces (to find a space) or get_space_group/get_space_member for adjacent resources. The agent must infer the role of this tool from the name alone.

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

get_space_ai_summariesSummarize a spaceC

Read-onlyIdempotent

Summarize a space. Reads community data.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`space_id`	Yes	Space ID
`date_from`	No	Filters messages created after the provided ISO8601 timestamp
`first_unread_message_id`	No	First unread message ID to include additional chat context

TDQS

C2.5/5.0

Behavior2/5

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

Annotations already declare readOnly, idempotent, openWorld and non-destructive, so the safety profile is covered. The description adds almost nothing beyond that — 'Reads community data' is vague and arguably inconsistent with a space-scoped tool; it says nothing about generation cost/latency, caching, or freshness of the AI summary.

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

Conciseness3/5

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

Two short, front-loaded sentences with no bloat, which is good, but the second sentence ('Reads community data') carries little information and borders on filler rather than earning its place.

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

Completeness2/5

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

With no output schema and four parameters, the description should explain what the summary returns and how it relates to the space/message filters (e.g., date_from scoping). Instead it omits return-value expectations and the AI-generation nature entirely, leaving the agent under-informed for a non-trivial tool.

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

Parameters3/5

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

Schema description coverage is 100%, so all four parameters (account, space_id, date_from, first_unread_message_id) are already documented in the schema. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

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

Purpose3/5

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

The description states a clear verb+resource ('Summarize a space'), but it is essentially a verbatim restatement of the title and does not distinguish this tool from neighbors like get_space or get_post_summary. It never clarifies that these are AI-generated summaries or what a 'space summary' comprises, so an agent cannot tell it apart from a generic retrieval call.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus list_spaces/get_space/get_post_summary, and no mention of prerequisites or when summaries are unavailable. The only hint of context is the vague 'Reads community data.'

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

get_space_groupShow Space GroupC

Read-onlyIdempotent

Show Space Group. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`space_group_id`	Yes	Space Group ID

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so safety is covered. The description adds nothing beyond that profile: it does not explain credential selection via the 'account' parameter, what constitutes a space group, or any auth/rate-limit behavior, making 'Reads community data' largely redundant with readOnlyHint.

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

Conciseness3/5

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

It is brief and front-loaded, but neither sentence earns its place: the first duplicates the title and the second duplicates the readOnly annotation. Shortness here is under-specification rather than disciplined concision.

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 low-complexity, single-resource read with fully documented params and rich annotations, the schema and annotations carry most of the load, and no output schema exists to explain returns. Minimum viability is met, but the description contributes nothing about the fetched space group that would help an agent interpret or choose it.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters (account, space_group_id) are already documented in the schema, including that 'account' selects credentials rather than a remote ID. The description adds no parameter detail, so the baseline 3 applies.

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

Purpose2/5

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

The first sentence repeats the title verbatim ('Show Space Group'), and the second ('Reads community data') is a vague domain restatement rather than a specific outcome. It does not distinguish this tool from close siblings like get_space_group_member, list_space_groups, or get_space, so an agent learns little beyond the name.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool, no prerequisites, and no mention of alternatives such as list_space_groups or get_space_group_member. Only a faint implication of read usage exists via 'Reads community data'.

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

get_space_group_memberShow Space Group MemberC

Read-onlyIdempotent

Show Space Group Member. Reads community data.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email of the user
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`space_group_id`	Yes	ID of the space group

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, non-destructive, and openWorld. The description's 'Reads community data' only re-states the read-only annotation and adds no new behavioral context such as auth requirements, what a missing member returns, or scope of the lookup.

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

Conciseness3/5

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

It is short with no wasted clauses, but the brevity stems from under-specification rather than efficient communication; the two fragments carry almost no actionable information.

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

Completeness2/5

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

For a lookup tool with no output schema, the description should indicate what is returned (membership record? role?) and how the email/space_group_id pair is interpreted. Neither is addressed, leaving the agent with only the schema to work from.

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

Parameters3/5

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

Schema description coverage is 100% and all three parameters are documented in the schema (email, account, space_group_id). The description contributes nothing beyond this, so the baseline 3 applies.

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

Purpose2/5

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

The first sentence merely restates the tool title ('Show Space Group Member'), and 'Reads community data' is a generic tagline that does not specify the resource being fetched or distinguish it from siblings like list_space_group_members, get_space_member, or get_space_group.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus list_space_group_members (which lists) or get_space_member (which fetches a space member by different keys). No prerequisites or context for selection are given.

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

get_space_memberShow Space MemberC

Read-onlyIdempotent

Show Space Member. Reads community data.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`space_id`	Yes	Space ID

TDQS

C2.2/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false, so the safety profile is fully covered. The description adds only 'Reads community data,' which repeats the read-only nature without revealing anything new—no auth requirements, rate limits, return shape, or edge cases.

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

Conciseness2/5

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

Two fragments; the second sentence ('Reads community data') is redundant with the title and annotations and does not earn its place. The brevity reflects under-specification rather than efficient communication.

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

Completeness2/5

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

For a simple lookup, annotations and schema cover safety and inputs, but the description leaves sibling disambiguation, prerequisites, and return-value expectations unstated. With no output schema, some indication of what is returned would help the agent call it correctly.

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

Parameters3/5

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

Schema description coverage is 100%, with the account parameter even explaining its credential-selection role. The description adds no parameter meaning, so baseline 3 applies.

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

Purpose2/5

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

The description merely restates the title ('Show Space Member') and adds the vague phrase 'Reads community data,' which does not name a specific verb beyond the title or distinguish it from sibling getters like get_member or get_space_group_member. It is a tautological description.

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

Usage Guidelines2/5

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

No guidance on when to use this tool instead of alternatives such as list_space_members, get_member, or get_space_group_member. There are no prerequisites, exclusions, or context signals to route the agent.

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

get_tagged_memberGet Tagged MemberC

Read-onlyIdempotent

Get Tagged Member. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`tagged_member_id`	Yes	Tagged Member ID

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is fully covered there. The description's "reads community data" simply echoes the readOnly annotation and adds no extra context such as error behavior, pagination, or what the returned tagged-member record contains.

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

Conciseness3/5

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

Two extremely short sentences with no padding or wasted words, and the purpose is front-loaded. However, this is brevity through omission rather than disciplined conciseness, so it earns only a middling score.

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

Completeness2/5

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

For a read tool with no output schema, the description should at minimum explain what a "tagged member" is relative to plain members and tags. With no return-format, no field, and no relationship context, an agent cannot confidently distinguish this call from get_member or list_tagged_members.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are documented in the schema itself (including the useful note that account selects credentials, not a remote community ID). The description contributes nothing about parameters, but the baseline of 3 applies when the schema carries the full burden.

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

Purpose2/5

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

"Get Tagged Member. Reads community data." restates the tool name/title almost verbatim and adds only the generic gloss "reads community data." It never clarifies what a tagged member is or how this differs from sibling readers like get_member, list_tagged_members, or get_member_tag.

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

Usage Guidelines2/5

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

There is no when-to-use guidance, no mention of the sibling tools it competes with (list_tagged_members, tag_member, untag_member), and no stated prerequisites beyond the schema-level requirement of tagged_member_id.

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

get_tax_settingsGet tax settingsC

Read-onlyIdempotent

Get tax settings. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.9/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The phrase 'Reads community data' adds a mild, vague note about scope but says nothing about permissions, remote-vs-local behavior, or return contents beyond what the annotations imply.

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?

Two very short sentences with the purpose front-loaded and zero filler. However, the second sentence ('Reads community data.') is so generic that it barely earns its place.

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 simple, fully-annotated read with one documented optional parameter and no output schema, the definition is minimally adequate. It omits any hint of what tax settings are returned or when an account must be supplied, leaving a thin but survivable gap.

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

Parameters3/5

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

There is a single optional parameter with 100% schema description coverage, so the schema already explains that 'account' selects credentials rather than a remote community ID. The description adds nothing about it, which is the expected baseline when the schema does the work.

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

Purpose3/5

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

The description states a verb ('Get') and resource ('tax settings'), but it is essentially a verbatim restatement of the title with no distinguishing detail. It never mentions the obvious sibling update_tax_settings, so an agent gets no help telling the read path apart from the write path.

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

Usage Guidelines2/5

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

There is no when-to-use guidance and no mention of the sibling update_tax_settings as an alternative. The agent must infer the read-vs-write distinction entirely from the tool name.

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

get_topicShow topic detailsC

Read-onlyIdempotent

Show topic details. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`topic_id`	Yes	Topic ID

TDQS

C2.4/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is fully covered. "Reads community data" merely restates the readOnly hint rather than adding context such as authentication requirements, credential selection via the account parameter, or visibility/rate-limit behavior. No contradiction, but no added value.

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

Conciseness3/5

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

Two short sentences that are front-loaded, but the second sentence ("Reads community data") is redundant filler given the readOnly annotation. Minimal size is a virtue here, yet the content per sentence is low.

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 simple, idempotent read tool with a fully documented two-parameter schema and complete annotations, the description is adequate to invoke it correctly. However, with no output schema, it could at least hint at what a topic's details include or note the required topic_id scope, leaving it only minimally sufficient.

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

Parameters3/5

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

Schema description coverage is 100%, so both parameters are already documented, including the non-obvious distinction that account selects credentials rather than a remote community ID. The description adds nothing beyond the schema, so the baseline of 3 applies.

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

Purpose2/5

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

"Show topic details" is a verbatim restatement of the tool title and name, contributing no information beyond them. "Reads community data" is a generic addendum that does not identify which resource is read or how this differs from sibling getters like get_post, get_space, or get_event. This is effectively a tautology.

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

Usage Guidelines2/5

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

There is no statement of when to use this tool versus alternatives (get_post, get_space, list_topics, update_topic) and no prerequisites or exclusions. The agent must infer usage solely from the name.

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

get_workflowGet WorkflowC

Read-onlyIdempotent

Get Workflow. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`id`	Yes	UUID of the workflow
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.1/5.0

Behavior2/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds nothing beyond that, and "Reads community data" is an inaccurate characterization of what is fetched, so it contributes no useful behavioral context.

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

Conciseness3/5

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

It is short and front-loaded, but the brevity stems from under-specification rather than economy — the second sentence is filler that conveys no actionable information.

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

Completeness2/5

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

For a simple id-based read this is under-developed: with no output schema, the description should at least say what a workflow object represents or what the call returns. Instead it supplies a misleading generic phrase and leaves the agent to infer the tool's role from the name alone.

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

Parameters3/5

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

Schema description coverage is 100% and both parameters (id, account) are documented in the schema, including the non-obvious note that account selects credentials rather than a remote community ID. The description adds nothing here, so the baseline 3 applies.

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

Purpose2/5

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

"Get Workflow" merely restates the tool name and title, and the only added clause — "Reads community data" — is vague and arguably misleading, since a workflow is not community data. It does not distinguish this tool from siblings like list_workflows, duplicate_workflow, or activate_workflow beyond the obvious singular/plural.

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

Usage Guidelines1/5

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

No when-to-use guidance whatsoever: no statement that this is the single-record fetch to use when you already have a workflow UUID, and no mention of the list_workflows/duplicate_workflow alternatives. The agent must infer everything from the name.

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

import_chat_room_messageImport Chat Room MessageC

Destructive

Import Chat Room Message. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`sent_at`	No	Timestamp for the imported message. Required and must not be in the future.
`user_email`	No	Email of the community member who is the message sender
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`chat_room_uuid`	No	UUID of the target chat room (from a chat space)
`rich_text_body`	No	TipTap rich text body, wrapped as `{ body: <tiptap_doc> }`
`parent_message_id`	No	ID of the parent message when creating a thread reply

TDQS

C2.7/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds the confirm=true requirement, which is useful behavioral context beyond the annotations, but it does not explain what community state is changed, what side effects occur, or whether the operation is reversible. With annotations carrying most of the burden, this is a minimal but non-contradictory addition.

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

Conciseness3/5

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

The description is short and front-loaded, but the first sentence is a pure restatement of the title and does not earn its place. The second sentence is useful but minimal. It is concise, though not maximally structured because it wastes one sentence on tautology and omits key operational details.

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

Completeness2/5

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

For a destructive, open-world mutation tool with nine parameters, a nested payload object, no output schema, and no required fields, the description is far too thin. It does not explain the import source, return behavior, permissions, idempotency semantics beyond annotations, or how to choose it over sibling message-creation tools. Annotations and schema cover safety and parameters respectively, but the description leaves major operational gaps.

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

Parameters3/5

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

Schema description coverage is 100%, meaning every parameter including the nested payload object is fully documented in the input schema. The description only mentions confirm=true, which is already explained in the schema, and adds no syntax, format, or structural detail beyond what the schema provides. Per the rubric, a baseline of 3 is appropriate when the schema does the heavy lifting.

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

Purpose3/5

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

The first sentence merely restates the tool title/name, so it adds no purpose information beyond structured fields. The second sentence says the tool 'Changes community state' but does not clarify what 'import' means, where the message comes from, or how it differs from siblings like send_message or create_comment. The verb+resource are technically present, but the description remains vague about the actual operation.

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

Usage Guidelines2/5

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

The only usage-like guidance is that confirm=true is required 'for the user-requested action,' which is a parameter-setting rule rather than a when-to-use statement. There is no guidance on when to choose this tool over alternatives such as send_message, create_comment, or other chat/message tools in the sibling list. No prerequisites or exclusions are provided.

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

invite_paywall_affiliatesInvite Paywall AffiliatesC

Destructive

Invite Paywall Affiliates. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`existing_member_ids`	No	Community member IDs to invite (max 20 per request). Must belong to the current community.

TDQS

C2.8/5.0

Behavior3/5

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

Annotations already declare destructiveHint=true, openWorldHint=true and idempotentHint=false, so the mutation profile is covered. The description adds one genuinely useful piece beyond the annotations: the confirm=true safety gate and the fact that community state is changed. It does not describe what specifically is altered or the non-idempotent invite semantics.

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

Conciseness3/5

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

Two short sentences, so it is not bloated, but the first sentence earns nothing since it merely repeats the title. Front-loading is fine; the content is thin rather than padded.

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 5-parameter, nested-payload, no-output-schema destructive tool, the description covers the confirm gate but omits the three mutually exclusive body input modes (payload vs payload_file vs flags) and the credential-selecting account param. The schema carries these, so it is minimally complete but not rich.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter (including the nested payload, payload_file mutual-exclusion rules, and existing_member_ids max of 20) is already documented. The description only echoes the confirm parameter, adding no meaning beyond the schema, so the baseline 3 applies.

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

Purpose2/5

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

The first sentence is a verbatim restatement of the tool title/name with zero elaboration, which is the definition of a tautology. The action is inferable from the name, but the description itself contributes nothing to distinguish it from siblings like create_invitation or update_paywall_affiliate.

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

Usage Guidelines3/5

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

It states a precondition ('requires confirm=true for the user-requested action'), which is a usage-relevant gate, so usage is implied rather than absent. However it never says when to pick this tool over related invite/affiliate tools, and no alternatives or exclusions are named.

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

list_access_group_community_membersList Access Group Community MembersC

Read-onlyIdempotent

List Access Group Community Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`access_group_id`	Yes	Access Group ID

TDQS

C2.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a quota caveat ('every page counts against the API quota'), but this is already stated in the schema's all_pages description, so it adds limited new behavioral context.

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

Conciseness3/5

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

The definition is short and front-loaded with the tool name, but the first sentence merely repeats the title and 'Reads community data' restates the readOnly annotation. Only the quota sentence earns its place, making the overall structure adequate but padded.

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 read-only list tool with rich annotations and a fully documented six-parameter schema, the description is minimally adequate. It does not clarify what a 'member' record contains (no output schema exists) or how results differ from sibling listing tools, leaving some contextual gaps.

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

Parameters3/5

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

Schema description coverage is 100%, so every parameter is documented in the schema itself. The description mentions all_pages and quota but adds no syntax, defaults, or meaning beyond what the schema already provides, matching the baseline of 3.

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

Purpose2/5

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

The first sentence is a verbatim restatement of the tool title, and 'Reads community data' is vague filler. It does not differentiate this tool from close siblings like get_access_group_community_member or list_member_access_groups, leaving an agent to infer scope from the name alone.

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

Usage Guidelines2/5

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

There is no guidance on when to use this tool versus the singular get_access_group_community_member or other listing tools such as list_member_access_groups. The description gives no context or prerequisites for invocation.

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

list_access_groupsList Access GroupsB

Read-onlyIdempotent

List Access Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`ids`	No	Filter by access group ids
`name`	No	Filter by access group name
`page`	No	Page number
`status`	No	Filter by access group status
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.4/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, so the safety profile is covered. The description adds value beyond that by disclosing that all_pages is bounded and that every page consumes API quota, a real cost consideration an agent should know before paging.

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?

Three short, front-loaded fragments with no padding; the operational warnings come after the purpose. Minor waste in restating the tool name as the first sentence, but overall tight.

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 an 8-parameter paginated list tool with no output schema, the description covers the pagination-quota interaction but says nothing about what is returned, how filtering combinations behave, or the account/credential parameter. Adequate but with clear gaps given the tool's complexity.

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

Parameters3/5

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

Schema description coverage is 100%, so the eight parameters are already documented in the schema, including the all_pages/max_items quota semantics. The description reinforces the all_pages quota cost but adds no new parameter-level meaning, making the baseline 3 appropriate.

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?

States a specific verb and resource ('List Access Groups'), so the agent knows it is a read-list operation on access groups. However, it offers no differentiation from close siblings like list_access_group_community_members or list_member_access_groups, which an agent could easily confuse with this tool.

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

Usage Guidelines2/5

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

The description says nothing about when to use this tool versus the many sibling list/search tools, nor does it state prerequisites or filtering context. The only guidance is a caveat about all_pages behavior, which is operational rather than selection-oriented.

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

list_accountsList configured accountsA

Read-onlyIdempotent

List private account labels, default selection and configured token method. No credentials, token paths or community content; no network request.

ParametersJSON Schema

Name	Required	Description	Default
No parameters

TDQS

A3.9/5.0

Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive/non-open-world, and the description adds genuinely new context: it excludes credentials and token paths and makes no network request, which reassures the agent about privacy and side effects. It stops short of describing ordering or the exact response shape.

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?

A single compact sentence that front-loads what is returned and follows with the exclusion list. Every clause earns its place with no filler.

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?

With no output schema, the description carries the burden of describing return values, and it does so by naming the three categories returned plus what is excluded. It could mention ordering or structure, but it is otherwise sufficient for a parameterless read tool.

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?

The tool takes zero parameters, so the baseline is 4; there is nothing for the description to clarify beyond the empty schema, and it does not need to.

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?

States a specific verb (List) and enumerates the concrete resource fields it returns: account labels, default selection, and configured token method. This is far more specific than a tautology, though there is no close sibling in the provided list to explicitly differentiate against.

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

Usage Guidelines3/5

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

The description implies this is a read-only config introspection tool and scopes what it does not cover (credentials, token paths, community content), but it gives no explicit when-to-use or when-not-to-use guidance relative to alternatives.

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

list_chargesCommunity Member Charges ListC

Read-onlyIdempotent

Community Member Charges List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sort field. Defaults to created_at.
`query`	No	Free-text search
`status`	No	Comma-separated list of statuses (e.g. paid,refunded,partial_refunded)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`currency`	No	Comma-separated list of currency codes
`per_page`	No	Records per page (max 100)
`platform`	No	Comma-separated list of platforms (web, app_store, play_store)
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`direction`	No	Sort direction. Defaults to desc.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`amount_gte`	No	Minimum charge amount (in currency subunits)
`amount_lte`	No	Maximum charge amount (in currency subunits)
`paywall_ids`	No	Comma-separated list of paywall IDs
`member_email`	No	Filter by community member email (partial match)
`processor_id`	No	Filter by exact processor (charge) ID
`created_at_gte`	No	Only include charges created on/after this date (ISO8601)
`created_at_lte`	No	Only include charges created on/before this date (ISO8601)
`paywall_price_type`	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`community_member_id`	No	Filter by community member ID
`invoice_processor_id`	No	Filter by exact invoice processor ID
`subscription_processor_id`	No	Filter by exact subscription processor ID
`billing_info_business_name`	No	Filter by billing info business name (partial match)
`community_member_public_uid`	No	Filter by community member public UID

TDQS

C2.4/5.0

Behavior3/5

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

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, openWorld), so the description's contribution is the quota/bounded-read context: 'Supports bounded all_pages; every page counts against the API quota.' That is genuinely useful, but it says nothing about continuation state, max_items interaction, or result shape.

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

Conciseness3/5

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

Very short and front-loaded, which is good, but the opening sentence is redundant with the title and therefore does not earn its place. Only the final clause carries unique information.

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

Completeness2/5

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

For a 24-parameter list tool with no output schema, the description is far too thin. It omits pagination behavior (page/per_page interplay with all_pages and max_items), the continuation state mentioned only in the schema, and any indication of what the response contains.

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

Parameters3/5

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

Schema description coverage is 100% across all 24 parameters, so the schema fully documents parameter meaning and the baseline is 3. The description only touches all_pages at a high level and adds no syntax, defaults, or field semantics beyond what the schema already states.

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

Purpose2/5

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

The first sentence is effectively a restatement of the tool title/name ('list_charges' -> 'Community Member Charges List'), and 'Reads community data' is a vague verb that doesn't specify it enumerates charge records. It does not differentiate this tool from closely related siblings such as export_community_member_charges or list_subscriptions.

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

Usage Guidelines2/5

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

No guidance on when to use this tool versus alternatives, even though the sibling set contains an obvious near-duplicate (export_community_member_charges). The all_pages sentence describes behavior, not selection criteria, so an agent gets no routing help.

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

list_commentsList CommentsB

Read-onlyIdempotent

List Comments. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`post_id`	No	Post ID
`per_page`	No	Number of records per page
`space_id`	No	Space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`search_text`	No	Search text

TDQS

B3.2/5.0

Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral note that every page consumes API quota, but says nothing about pagination termination, continuation tokens, or result shape.

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?

Three short, front-loaded sentences with no padding; the quota caveat appears early. The clause 'Reads community data' is slightly filler given the readOnly annotation, keeping it below a 5.

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?

With annotations carrying the safety profile and the schema carrying full parameter documentation, the description supplies the one behavioral fact an agent most needs (quota cost of paging). For an 8-parameter, no-output-schema list tool this is reasonably complete, though bulk-listing intent versus single-comment retrieval remains implicit.

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

Parameters3/5

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

Schema description coverage is 100%, so all eight parameters are already documented in the schema, including the all_pages/max_items quota semantics. The description adds no syntax or format detail beyond that baseline, so a 3 is appropriate.

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?

States a specific verb and resource ('List Comments'), and distinguishes itself implicitly from the sibling mutation/read tools create_comment, delete_comment and get_comment. It does not explicitly name an alternative sibling, so it falls short of a 5.

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

Usage Guidelines2/5

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

No when-to-use guidance and no alternatives named. The agent must infer that this is the bulk-retrieval counterpart to get_comment and that search/comments-wide retrieval uses search_text, with no explicit statement of that routing.

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

list_contact_notesList Contact NotesC

Read-onlyIdempotent

List Contact Notes. Reads community data.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`contact_id`	Yes	Contact ID or sqid

TDQS

C2.3/5.0

Behavior2/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is fully covered. 'Reads community data' is consistent but redundant with readOnlyHint and adds no new behavioral context (no pagination behavior, no return shape). No contradiction, but no added value either.

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

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded and free of padding, but the second sentence is vague filler rather than substance. It is concise without being informative, so it sits at an adequate rather than strong level.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read-only list tool with rich annotations and full schema coverage, the main missing pieces are the relationship to create_contact_note and any hint about pagination or note content. With no output schema present, the description does nothing to fill the remaining gap, leaving it incomplete for an agent choosing among ~100 siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so contact_id, page, and account are already documented in the schema (account's 'selects credentials, not a remote community ID' note is notably clear). The description adds no syntax or format detail beyond what the schema provides, making 3 the correct baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The sentence 'List Contact Notes' merely restates the tool name and title without adding a verb-resource distinction or scope. 'Reads community data' is a vague qualifier that could describe nearly any sibling read tool. Nothing distinguishes it from list_comments, list_member_tags, or the sibling create_contact_note.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no alternatives are named. An agent would not know from the description that create_contact_note exists for writing, or that this is the read counterpart scoped to a single contact. Usage is only implied by the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_course_lessonsList course lessonsB

Read-onlyIdempotent

List course lessons. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest)
`status`	No	Status
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	No	Space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`section_id`	No	Section ID

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, covering the safety profile. The description adds that it 'reads community data' and warns that every page consumes quota, which is useful context, but the quota/all_pages details largely restate the schema parameter descriptions rather than adding new behavioral nuance.

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?

Three short sentences with the purpose front-loaded and no wasted filler. The opening sentence only restates the title, which is a minor redundancy but the rest is tight.

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?

With annotations covering the safety profile and the schema at 100% coverage, the description is roughly adequate for a 9-param read tool and no output schema exists. It still omits default pagination behavior and the relationship to sibling list/get tools, leaving the picture incomplete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all nine parameters are already documented in the schema. The description adds no parameter semantics beyond what is provided there, making the baseline 3 appropriate.

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 ('List course lessons'), which is clearly distinct from the singular get_course_lesson sibling. However, it does not explicitly differentiate itself from related list tools like list_course_sections, so it stops short of full sibling routing.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes quota behavior for all_pages but gives no guidance on when to use this tool versus alternatives such as get_course_lesson or list_course_sections. No prerequisites or exclusions are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_course_sectionsList Course SectionsB

Read-onlyIdempotent

List Course Sections. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	No	Space ID of the course section
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.1/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint/idempotentHint/openWorldHint/destructiveHint=false, so the safety profile is covered. The description adds quota behavior beyond that: "every page counts against the API quota" and "supports bounded all_pages" — genuinely useful operational context about rate/cost implications.

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?

Three short sentences, front-loaded with the purpose and quota constraint. However, the opening sentence duplicates the tool name/title and carries no added value.

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?

With no output schema, the description could say something about what a returned section contains, and it never clarifies list-vs-get selection. Quota and bounded-pagination context is present, but return-value shape and sibling routing are absent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters (page, sort, account, per_page, space_id, all_pages, max_items), including the all_pages quota note. The description echoes rather than extends this, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List Course Sections" restates the tool name/title almost verbatim, so the purpose is clear (list, course sections) but the description adds no differentiation from siblings like get_course_section or list_course_lessons. The appended "Reads community data" hints at scope but does not distinguish this tool's role.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no mention of alternatives (get_course_section, list_course_lessons, search), and no prerequisites or exclusions. "Reads community data" is context, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_event_attendeesList Event AttendeesB

Read-onlyIdempotent

List Event Attendees. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`event_id`	Yes	Event ID
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly/idempotent/non-destructive/openWorld, so the safety profile is covered. The description goes beyond them by disclosing that pagination is bounded and that 'every page counts against the API quota' – a real rate/quota trait not present in the structured data. It stops short of noting auth/credential needs, which the schema partially hints at via 'account'.

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?

Three short, front-loaded sentences with no filler; the quota constraint is stated compactly. The only inefficiency is the redundant first sentence that repeats the title instead of leading with substantive 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 a simple read-only list tool with 100% schema coverage and annotations covering safety, the description supplies the key operational caveat (quota-consuming paging). With no output schema, the return shape (attendee fields, continuation state) is only partially implied via the schema's max_items note, a minor omission.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters, including the quota/continuation semantics of all_pages and max_items. The description adds only the quota reminder for all_pages, marginally reinforcing but not extending schema meaning. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence verbatim restates the tool title/name ('List Event Attendees'), which is tautological. 'Reads community data' adds a mild read-vs-write signal distinguishing it from create_event_attendee/delete_event_attendee, but it offers no differentiation from the many other list_* siblings. The purpose is inferable mainly from the name, not the description.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description never says when to use this tool versus alternatives like get_event, list_events, or search_member, nor any prerequisite. The only usage-flavored content is a pagination note ('bounded all_pages'), which is about mechanics rather than selection. No when/when-not guidance exists.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_eventsList EventsC

Read-onlyIdempotent

List Events. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sort events - oldest (by created_at), start_date (by starts_at ascending), start_date_desc (by starts_at descending), default is newest (by published_at)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	No	Filter events by event space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`filter_date_end_date`	No	End date for filtering events (format: YYYY-MM-DD)
`filter_date_start_date`	No	Start date for filtering events (format: YYYY-MM-DD)

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, covering the safety profile. The description adds a quota-cost warning for pagination, which is genuine value beyond annotations, but omits return format, rate limits, and any auth/scope behavior.

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?

Two short sentences, front-loaded with the action and followed by the quota caveat. Efficient, though the opening sentence duplicates the title rather than earning its place.

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 nine-parameter read tool with no output schema, the description is thin but the schema and annotations carry most of the load. It omits any mention of the pagination/sort semantics or what a caller receives, leaving modest gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all nine parameters are already documented in the schema, including the all_pages quota note and max_items continuation state. The description adds nothing about parameter syntax or interaction, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence 'List Events' merely restates the tool name/title, and 'Reads community data' is generic filler. The verb+resource is nonetheless identifiable, but nothing distinguishes it from siblings like get_event, list_event_attendees, or search, which also touch events.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes that all_pages is supported and quota-consuming, but gives no when-to-use guidance, no conditions for choosing this over get_event or list_event_attendees, and no exclusions. Usage is only implied by the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_filter_controlsList member directory and member space filter controlsB

Read-onlyIdempotent

List member directory and member space filter controls. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`key`	No	Only controls for this filter key
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`enabled`	No	Only enabled or disabled controls
`per_page`	No	Number of records per page (max 100)
`space_id`	No	Only controls for this member space
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`profile_field_id`	No	Only controls for this profile field
`member_directory_only`	No	Only member-directory controls that are not scoped to a space

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive and openWorld, so safety is covered. The description adds genuinely new context the annotations lack: that all_pages is bounded and that each page consumes API quota, which is a cost/rate-limit disclosure an agent needs before paging.

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?

Three short sentences with the resource scope front-loaded and the quota warning last. Efficient, though the middle sentence 'Reads community data' is largely redundant with the readOnlyHint annotation.

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?

Given 10 optional parameters, rich annotations and no output schema, the description covers pagination cost but says nothing about what a filter control contains or how results relate to the filter key/space scoping parameters. Adequate but with clear gaps for a tool of this breadth.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every one of the 10 parameters (including the key enum and max_items continuation semantics) is already documented in the schema. The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

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?

States a specific verb + resource ('List member directory and member space filter controls'), which is clearer than the name alone and scopes which controls are covered. It does not explicitly differentiate itself from sibling read tools like get_filter_configuration or get_filter_control, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance. Nothing tells the agent how this differs from get_filter_control (single) or get_filter_configuration, and no prerequisites are stated. Only the all_pages cost caveat is present, which is behavioral rather than usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_flagged_contentList Flagged ContentsB

Read-onlyIdempotent

List Flagged Contents. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`status`	No	Status. Default: 'all'.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds a genuinely useful operational fact — that every page counts against the API quota and all_pages is bounded — but says nothing about error behavior, rate limits, or what the returned continuation state looks like.

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?

Three short clauses, front-loaded with the purpose before the operational caveat. Efficient overall, though the 'Reads community data' fragment is close to filler and could be folded into the first sentence.

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?

There is no output schema, so the description ideally would hint at the return shape (flagged items plus continuation state) and default paging behavior. It covers the quota cost and bounded paging, but an agent still lacks a clear picture of what comes back from a six-parameter optional-argument list tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and all six parameters are documented in the schema itself, including the quota and continuation semantics for all_pages/max_items. The description only reiterates the all_pages/quota point, adding no syntax or format detail beyond the schema, so the baseline 3 applies.

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?

States a specific verb and resource (list flagged contents) and clarifies it reads community data, which separates it from the write-side sibling report_flagged_content. It does not explicitly name or contrast with that sibling, so it lands just short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No statement of when to use this versus report_flagged_content or any other listing tool, and no prerequisites or exclusion conditions. The only guidance is operational ('supports bounded all_pages'), which is behavior rather than selection advice.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_formsList FormsA

Read-onlyIdempotent

List Forms. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	Filter by form name
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, destructive=false, and openWorld. The description adds genuinely new behavioral context beyond those: pagination is bounded, every page consumes API quota, and all_pages is not a snapshot or guaranteed complete backup. That quota warning and the 'not a backup' caveat are meaningful additions.

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?

Three short sentences, no filler, with the resource and the two key behavioral caveats (bounded pages, quota cost) front-loaded. Nothing repeats the structured fields.

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?

With no output schema, the description is still adequate: annotations carry the safety profile and the schema carries parameter details, while the description contributes the quota/pagination caveats. It leaves vague what 'community data' encompasses and gives no default-page behavior, so not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented, including all_pages and max_items semantics. The description only echoes the quota angle for all_pages rather than adding syntax, defaults, or interaction details beyond the schema, so the baseline of 3 applies.

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?

States a specific verb and resource ('List Forms') and adds a scope note ('Reads community data'). It doesn't differentiate itself from siblings like get_form or get_form_submissions, but the name and phrasing make the operation unambiguous.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus get_form, get_form_submissions, or search-style siblings, and no prerequisites or exclusions. The only usage-adjacent sentence is about all_pages quota behavior, not about selecting this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_image_postsList Image PostsC

Read-onlyIdempotent

List Image Posts. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	Yes	Image space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful non-annotation context: that all_pages is bounded and every page consumes API quota. It stops short of describing rate limits, auth/account requirements, or result shape.

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?

Three short sentences, front-loaded with the resource and followed by the quota caveat. Nothing is wasted, though the opening sentence duplicates the name rather than spending the space on scope or differentiation.

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?

With a fully described schema and complete annotations, the description needs only light support, and the quota/bounded-pagination note partially covers that. However, for a paginated listing tool it omits any guidance on filtering scope, defaults, or how to relate it to the sibling list_posts, leaving gaps an agent would have to infer.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents page, per_page, space_id, account, all_pages and max_items. The description only reinforces all_pages semantics, adding no format or default detail beyond what the schema fields already provide; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List Image Posts" restates the tool name and title almost verbatim, and "Reads community data" is vague. The verb+resource is clear enough that an agent knows it enumerates image posts, but nothing distinguishes it from siblings like list_posts, list_spaces, or list_live_rooms beyond the noun.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no alternative is named. The note about bounded all_pages hints at a usage mode but never states which conditions should lead an agent to pick this tool over list_posts.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_invitationsList Invitation LinksC

Read-onlyIdempotent

List Invitation Links. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	Filter by invitation link name
`page`	No	Page number
`status`	No	Filter by invitation link status
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so the safety profile is covered. The description adds the quota cost of paging and that all_pages is bounded, but that same information already appears verbatim in the all_pages and max_items schema descriptions, so the added value over structured fields is limited.

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?

Three terse sentences with the resource first and the quota constraint front-loaded before the paging caveat. Efficient, though the first sentence duplicates the title without adding information.

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?

With no output schema and seven parameters, the description is thin but the 100%-covered input schema and read-only annotations carry most of the burden. It never states what an invitation link record contains or how filtered results order, leaving a modest gap for a listing tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so every parameter including name, status, account, and paging is already documented in the schema. The description adds no field-level meaning beyond what the schema provides, which is the expected baseline when schema does the work.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by restating the title ('List Invitation Links') and adds only 'Reads community data', which is a vague scope qualifier. The verb+resource is clear enough to distinguish it from create_invitation or delete_invitation_link, but it offers no differentiation from other list_* siblings beyond the resource noun already in the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives or what prerequisites exist. The all_pages note is a pagination caveat, not usage guidance, and no sibling is named for comparison.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_live_roomsList Live RoomsC

Read-onlyIdempotent

List Live Rooms. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description adds a genuinely useful behavioral note that paging consumes API quota, which annotations do not convey, but omits return shape or pagination continuation behavior.

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?

Two short sentences with no padding and the core scope front-loaded. It is efficient, though terseness comes at the cost of omitting return-value and sibling context rather than adding it.

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 simple read-only list tool with full annotation coverage and complete parameter documentation, this is minimally adequate. However, with no output schema, the description could have explained what a 'Live Room' record contains or how to disambiguate from list_live_room_transcripts, and it does not.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all five parameters (page, account, per_page, all_pages, max_items) are already documented in the schema. The description's mention of bounded all_pages and quota adds no syntax or meaning beyond what the schema provides, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description restates the title verbatim ('List Live Rooms') plus a vague 'Reads community data' clause. It identifies the resource but does not distinguish this from the closely related sibling list_live_room_transcripts, leaving the agent to infer the boundary.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this tool versus alternatives, and no prerequisites or exclusions are stated. The only actionable hint ('Supports bounded all_pages') is about a parameter, not about tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_live_room_transcriptsList Live Room TranscriptsC

Read-onlyIdempotent

List Live Room Transcripts. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`room_id`	Yes	Live Room ID

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=true, so the safety profile is fully covered. The description's only contribution, 'Reads community data,' is vague filler that adds no behavioral detail beyond the annotations (e.g., pagination, room scope, auth via the account credential).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, which is good, but the second sentence ('Reads community data.') is low-value filler rather than earned content. It is concise without being informative.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a read tool with no output schema, the description could have described what transcripts are returned or pagination behavior, but instead offers only a generic 'reads community data' phrase. With annotations and schema covering their parts, the description still leaves the return shape entirely undocumented.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and both parameters are documented in the schema, so the baseline of 3 applies. The description adds nothing about required room_id or how the account credential selection works, so no credit above baseline.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence is a verbatim restatement of the tool title/name ('List Live Room Transcripts'), adding no distinguishing information. It does not differentiate this tool from the sibling list_live_rooms, nor explain what a 'transcript' comprises.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisites, and no mention of alternatives such as list_live_rooms. The agent must infer usage entirely from the tool name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_member_access_groupsList Community Member's Access GroupsB

Read-onlyIdempotent

List Community Member's Access Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`community_member_id`	Yes	Community Member ID

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already cover the safety profile (readOnly, idempotent, non-destructive, open-world), so the bar is lower, yet the description adds real behavioral context: it is a read of community data, all_pages is bounded, and every page consumes API quota. It stops short of describing rate-limit specifics or return shape.

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?

Three short sentences, with the core action front-loaded before the pagination caveat. Very little waste, though the final quota clause is terse enough to read as a fragment rather than a complete behavioral note.

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?

No output schema exists, so the description could have described what a result contains (access group records) but does not. It covers the pagination/quota dimension adequately but leaves usage context and return expectations to inference for a tool with six parameters.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are documented in the schema, giving a baseline of 3. The description adds marginal meaning for all_pages (quota cost per page) but says nothing extra about account, page, per_page, max_items, or community_member_id.

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 and resource: 'List' + 'Community Member's Access Groups', which is a distinct scope from the sibling list_access_groups (community-wide) and get_access_group_community_member. It does not explicitly name those siblings to disambiguate, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use, when-not-to-use, or alternative guidance is given. An agent must infer from context whether this or list_access_groups / get_access_group_community_member is the right call, and no prerequisites (e.g. required membership) are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_membersList Community MembersC

Read-onlyIdempotent

List Community Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`status`	No	Filter by member status. Defaults to `active`. - `active`: members who have completed profile setup (`profile_confirmed_at` is set). - `inactive`: invited members who have not yet completed profile setup. This is the same set shown in the admin UI under Audience → Manage → Invited. - `all`: both of the above.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`member_tag_ids`	No	Filter by Member Tag IDs (OR logic, comma-separated)

TDQS

C2.8/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

The annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=true, so safety is covered. The description adds a genuinely new trait the annotations do not carry: that all_pages is bounded and that every page consumes API quota, which matters for a 7-parameter paginated reader.

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?

Three short sentences, front-loaded with the resource and immediately followed by the quota caveat. No filler, though the terseness leaves real gaps rather than being optimally sized.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter paginated list tool with no output schema and no output description, the definition says nothing about the returned shape, continuation state, or how page/per_page/all_pages/max_items interact in practice. The quota sentence is a start but far short of what an agent needs.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including detailed enum semantics for status, account credential selection, and max_items continuation behavior. The description adds nothing beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence, 'List Community Members,' is a verbatim restatement of the title, and 'Reads community data' adds no specificity. Nothing distinguishes it from the many sibling list/get/search member tools such as search_member, get_member, list_tagged_members, or list_space_members.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no exclusion conditions, and no mention of alternatives like search_member or the access-group/space-scoped member listers. The all_pages/quota note is behavioral caution, not usage routing.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_member_spacesList Community Member SpacesC

Read-onlyIdempotent

List Community Member Spaces. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`user_email`	No
`community_member_id`	No

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and non-destructive behavior, so the safety profile is covered. The description adds a genuine behavioral detail beyond the annotations: pagination consumes API quota and all_pages is bounded. It stops short of explaining rate limits, auth context, or what the response contains.

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?

Three short sentences, front-loaded with the resource and free of filler. The tradeoff is that the brevity comes at the cost of substance, since one sentence is pure title restatement.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 7-parameter listing tool with no output schema, the description should carry more of the load: it does not explain what a returned 'member space' looks like, how pagination state is surfaced, or what the two undocumented filter parameters do. Only the quota/pagination caveat is covered.

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?

With 71% schema coverage and 7 parameters, the description adds essentially nothing beyond the schema: the all_pages/quota note is already present in the schema's own description of that field. Notably, user_email and community_member_id have no schema description at all, and the tool description does not compensate for that gap or explain how filtering parameters interact.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence merely restates the tool title ('List Community Member Spaces'), adding only 'Reads community data.' It never clarifies what a 'member space' is or how this differs from close siblings like list_space_members, list_members, or list_spaces, leaving the agent to infer the relationship.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance and no mention of alternatives, despite a crowded sibling set containing list_space_members and list_spaces. The only usage-adjacent note is about quota consumption, which is a cost warning rather than a selection rule.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_member_tagsMember Tags ListC

Read-onlyIdempotent

Member Tags List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name of the member tag
`page`	No	Page number
`sort`	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`is_public`	No	Whether the member tag is public
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false and openWorldHint=true, so the safety profile is covered without the description. The description adds a genuinely useful behavioral note beyond the annotations: the all_pages mode is bounded and every page counts against the API quota. It does not cover filtering behavior or result ordering beyond what the schema says.

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?

Three short sentences with no padding and the quota constraint placed up front. However, the first sentence spends its budget repeating the title instead of using that space for purpose or sibling differentiation.

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 read-only list tool with full schema coverage, complete annotations and no output schema, the definition is minimally viable. It is missing anything about the returned collection contents or the interaction between name/is_public filters and pagination, which an agent would need to call it confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 8 parameters, so the baseline is 3. The description adds no parameter meaning beyond the schema's own all_pages note (bounded pages, quota cost), which the schema already states almost verbatim; name, sort, is_public, account and max_items are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence is a verbatim restatement of the title 'Member Tags List', and 'Reads community data' is a vague catch-all that could describe dozens of siblings. It never says what a member tag is or how listing them differs from get_member_tag / list_tagged_members / tag_member, all present in the sibling list.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use versus when-not guidance and no routing to alternatives such as get_member_tag or list_tagged_members. The mention that all_pages is bounded and each page consumes quota is operational advice, not tool-selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_page_profile_fieldsGet Page Profile FieldsC

Read-onlyIdempotent

Get Page Profile Fields. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`page_name`	Yes	Page name

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds nothing beyond that — no return shape, no scoping, no note on which 'community data' is read or whether credential selection via 'account' matters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short and front-loaded, which is good, but the second sentence ('Reads community data') is vague filler rather than information, and the first sentence merely echoes the title. Brevity here reflects under-specification rather than efficient concision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter read tool with no output schema, the description should at least clarify what page profile fields are and how this differs from list_profile_fields. Instead it leaves the domain concept unexplained, which is a meaningful gap for an agent choosing among many list_* tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both parameters (account, page_name with its enum) are already fully documented in the schema; baseline 3 applies. The description contributes zero additional parameter meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description repeats the title verbatim ('Get Page Profile Fields') and adds only the tautological 'Reads community data.' It never says what a page profile field actually is or how it differs from the sibling list_profile_fields, so an agent cannot distinguish the two without opening schemas.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'Reads community data' hints at a read operation but gives no when-to-use condition, no prerequisites, and no routing against the many list_* siblings (notably list_profile_fields). The agent must infer usage entirely from the name.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_paywall_affiliatesPaywall Affiliates ListC

Read-onlyIdempotent

Paywall Affiliates List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`filters`	No	Filters
`per_page`	No	Records per page (max 100)
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds the quota-consumption trait ("every page counts against the API quota") and the bounded all_pages behavior, which is genuinely useful operational context. However, it largely echoes the all_pages schema description rather than disclosing anything new about cost, pagination limits, or continuation behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, and the second (quota/all_pages) is front-loaded usefully. But the first sentence is pure tautology against the title and consumes space without earning it.

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?

With a 6-parameter nested schema, strong annotations, and no output schema, the structured fields do most of the work. The description is adequate but leaves gaps: it never clarifies what the returned affiliate records contain or how the tool relates to the payout/affiliate siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including the nested filters object and the max_items continuity note, so the schema carries the parameter semantics. The description reinforces only the quota aspect of all_pages and adds no field-level meaning beyond it, which matches the baseline-3 case for fully documented schemas.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description effectively restates the title and name: "Paywall Affiliates List. Reads community data." It never explains what a paywall affiliate is or what this list contains, and it does nothing to differentiate the tool from the many other list_* siblings. This is close to tautology rather than a specific verb+resource statement.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use, when-not-to-use, or alternative-tool guidance. Given siblings like export_paywall_affiliate_payouts and list_members, the agent is left to infer the boundary entirely on its own.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_postsList Basic PostsB

Read-onlyIdempotent

List Basic Posts. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sort by
`status`	No	Post status
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	No	Basic type space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`search_text`	No	Search text
`space_group_id`	No	Space Group ID

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already provide readOnlyHint, idempotentHint, openWorldHint, and destructiveHint=false. The description adds useful context about bounded all_pages and API quota consumption, but it does not cover authentication needs, response shape, or pagination edge cases beyond the quota note.

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?

The description is short and front-loaded, with the core purpose stated first and the pagination/quota caveat last. Some redundancy exists because 'List Basic Posts' restates the title and 'Reads community data' is generic, but there is no wasted verbosity.

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?

With 10 optional parameters, rich schema descriptions, and annotations covering safety, the description is adequate but sparse. It omits sibling differentiation, usage context, and filtering guidance, though the structured fields compensate for much of that gap.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the input schema already documents all 10 parameters thoroughly. The description highlights all_pages and quota cost, but this largely repeats the schema's own all_pages and max_items descriptions without adding new semantic detail.

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 clear verb and resource: 'List Basic Posts' and 'Reads community data.' It implies this is a read-only listing tool, but it does not explicitly differentiate from siblings such as list_image_posts or search, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no alternatives named, and no conditions for preferring this tool over related list or search tools. The phrase 'Reads community data' is too vague to function as usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_profile_fieldsProfile Fields ListC

Read-onlyIdempotent

Profile Fields List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`label`	No	Filter by label (case-insensitive partial match)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`archived`	No	Set to 'true' to search archived profile fields, omit or set to 'false' for active fields
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint, so the safety profile is covered. The description contributes genuinely new behavioral context — that all_pages is bounded and that every page consumes API quota — which is useful, though it is stated tersely and omits error/rate-limit behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and the quota caveat is front-loaded, but the first clause merely repeats the tool title and 'Reads community data' is filler. Roughly half the text earns its place.

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?

With no output schema and seven fully documented parameters, plus annotations covering safety, the main missing piece is usage routing (sibling disambiguation and when to set account/archived/all_pages). For a read-only list tool the schema carries most of the burden, but the description leaves the selection context uncovered.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all seven parameters including page, label, account, archived, all_pages and max_items. The description only echoes the all_pages/quota constraint and adds no parameter-level meaning beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by restating the title ('Profile Fields List') and then says only 'Reads community data', which is a generic tautology rather than a statement of what is listed or from where. It does not distinguish this tool from the sibling list_page_profile_fields, so an agent cannot tell which listing endpoint applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance, no prerequisite (e.g., credential requirement for the 'account' parameter), and no mention of the sibling list_page_profile_fields as the alternative. Usage must be inferred entirely from the name and schema.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_segmentsList Community SegmentsA

Read-onlyIdempotent

List Community Segments. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`title`	No	Filter by title
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

A3.7/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and destructiveHint=false, so safety is covered. The description still adds non-obvious context: bounded all_pages behaviour and that each page consumes API quota, which affects how aggressively an agent paginates.

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?

Three short, front-loaded sentences with the resource named first and the quota caveat last. 'Reads community data' is largely redundant with the readOnlyHint annotation and could be dropped.

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 a six-optional-parameter list tool with no output schema, the fully documented input schema plus a note on quota cost and bounded pagination gives an agent enough to call it correctly. Return shape and pagination defaults remain unstated but are largely derivable from max_items/per_page.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100% and every parameter (page, title, account, per_page, all_pages, max_items) has its own schema description with bounds and defaults. The description adds no parameter detail beyond what the schema already provides, so baseline 3 applies.

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?

States a clear verb+resource ('List Community Segments') that is easy to distinguish from the create/update/delete/duplicate_community_segment siblings. However, it offers no explicit differentiation from those siblings or other listing tools beyond the name itself.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit when-to-use or when-not-to-use guidance, but the note that 'every page counts against the API quota' gives practical guidance for deciding whether to enable all_pages. The read-only nature is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_space_group_membersList Space Group MembersC

Read-onlyIdempotent

List Space Group Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`status`	No	Space group member status. By default, it returns all members.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`space_group_id`	Yes	Space Group ID

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds a genuine behavioral fact beyond that — every page consumes API quota and all_pages is bounded — which is useful for an agent planning pagination. It stops short of describing return shape, ordering, or error/auth behavior.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Very short, but the opening sentence duplicates the title verbatim and earns no space, and the remaining fragments are telegraphic rather than structured. It is front-loaded in the sense that there is almost nothing to load.

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 7-parameter, paginated list tool with no output schema, the description covers the quota/pagination caveat but says nothing about what a member record contains, ordering, or continuation handling. Annotations and the fully documented schema fill most of the gap, making this minimally adequate rather than complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents all 7 parameters including all_pages boundedness and max_items continuation state. The description's mention of bounded all_pages and quota merely echoes what the schema states, adding no syntax or semantics beyond it. Baseline 3 applies when the schema carries the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence "List Space Group Members" only restates the tool name/title, adding no verb+resource detail. "Reads community data" adds operational flavor but does not distinguish it from close siblings like list_space_members or list_space_group_members-adjacent list tools. Purpose is inferable but not sharpened beyond the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No indication of when to use this tool versus list_space_members, get_space_group_member, or list_space_groups. The only guidance-like content is pagination mechanics, not selection criteria or prerequisites.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_space_groupsList Space GroupsB

Read-onlyIdempotent

List Space Groups. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	Filter by name
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already establish the read-only, idempotent, non-destructive safety profile, so the bar is lower. The description adds genuinely useful behavior beyond them: the bounded nature of all_pages and that every page consumes API quota. It stops short of describing return shape or failure modes.

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?

Three short sentences, front-loaded with the tool's identity before behavioral notes. No filler, though the quota point appears in both the description and the all_pages schema entry, a minor redundancy.

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 six-parameter list tool with no output schema and no required parameters, the description covers pagination strategy and quota cost but says nothing about what a space group is or what a result looks like. Annotations cover safety, but the return/pagination semantics rest entirely on the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so the schema already documents all six parameters, including the quota note on all_pages. The description's mention of bounded all_pages and quota consumption largely restates the schema rather than adding new semantics, so baseline 3 applies.

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 ("List Space Groups") and is distinguishable from siblings such as list_space_group_members, get_space_group, and list_spaces. It does not explicitly say how it differs from those neighbors, but the resource naming is precise enough for selection.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no statement of when to use this tool versus alternatives like list_spaces, list_space_group_members, or get_space_group. "Reads community data" is a category hint, not usage guidance, and no prerequisites or exclusions are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_space_membersList Space MembersB

Read-onlyIdempotent

List Space Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`status`	No	Space member status. By default, it returns all members.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`space_id`	Yes	Space ID
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and open-world. The description adds genuine value beyond them by warning that every page counts against the API quota and that all_pages is bounded rather than a complete snapshot. It stops short of describing return shape or rate-limit specifics.

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?

Three short sentences, front-loaded with the purpose and then the quota caveat. No filler, though the second sentence ('Reads community data') is near-tautological for a list tool and earns little.

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 7-parameter paginated read tool with no output schema, the description covers the quota/pagination cost but says nothing about what a member record contains, ordering, or how it differs from the many sibling member-listing tools. Annotations carry the safety profile, so the remaining gap is moderate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, so every parameter is already documented in the schema. The description reinforces the all_pages/quota tradeoff but adds no syntax, defaults, or format detail beyond what the schema states, which is the expected baseline of 3.

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?

States a specific verb+resource (list space members) and adds that it reads community data, so the agent knows the domain. It does not explicitly distinguish itself from near-siblings like list_members or list_space_group_members, so it falls short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only notes that all_pages is bounded and paginated consumption of quota. There is no statement of when to use this tool versus list_members, list_space_group_members, or get_space_member, and no prerequisites or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_spacesList SpacesC

Read-onlyIdempotent

List Spaces. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sort by
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

C2.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, open-world behavior, so the safety profile is covered. The description adds genuinely new behavioral context by disclosing that every page consumes API quota, which is exactly the kind of rate/quota cost an agent needs before looping.

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?

Three short sentences with no filler, and the quota caveat is placed where it will be read before invoking. The opening "List Spaces" is redundant with the title, but the rest is tight and front-loaded.

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 a low-complexity read-only list tool with full schema coverage and rich annotations, the description covers the essentials plus the quota cost. It omits any indication of return shape, but with no output schema and a simple list contract this is a minor gap rather than a blocking one.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters (page, sort, account, per_page, all_pages, max_items) are already documented in the schema, including the quota and continuation semantics. The description's "bounded all_pages" note reinforces the schema but adds no new parameter syntax or constraints, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"List Spaces" essentially restates the tool name and title, and "Reads community data" only confirms a read without specifying what a space is or how it differs from the sibling list_member_spaces. There is no field-level or scope-level detail to distinguish it from adjacent space tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use guidance, no prerequisites, and no mention of the alternatives (e.g. list_member_spaces, get_space). The only hint is that all_pages is supported, which is a capability note rather than selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_subscriptionsCommunity Member Subscriptions ListB

Read-onlyIdempotent

Community Member Subscriptions List. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`sort`	No	Sort field (one of: charges_quantity, subscription_term, renews_on, community_member_name, paywall_name, platform, status, created_at). Defaults to created_at
`query`	No	Free-text search
`status`	No	Comma-separated list of statuses (e.g. active,trial,canceled)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`currency`	No	Comma-separated list of currency codes
`per_page`	No	Records per page (max 100)
`platform`	No	Comma-separated list of platforms (web, app_store, play_store)
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`direction`	No	Sort direction (asc or desc). Defaults to desc
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`paywall_ids`	No	Comma-separated list of paywall IDs
`member_email`	No	Filter by community member email (partial match)
`start_date_gte`	No	Only include subscriptions started on/after this date (ISO8601)
`start_date_lte`	No	Only include subscriptions started on/before this date (ISO8601)
`billing_interval`	No	Filter by paywall price billing interval (e.g. month, year)
`paywall_price_type`	No	Comma-separated list of paywall price types (e.g. subscription,onetime,installments)
`community_member_id`	No	Filter by community member ID
`scheduled_to_cancel`	No	Filter by whether the subscription is scheduled to cancel
`total_amount_paid_gte`	No	Minimum total amount paid (in currency subunits)
`total_amount_paid_lte`	No	Maximum total amount paid (in currency subunits)
`subscription_processor_id`	No	Filter by exact subscription processor ID
`billing_info_business_name`	No	Filter by billing info business name (partial match)
`community_member_public_uid`	No	Filter by community member public UID

TDQS

B3.4/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

With annotations already declaring readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, the safety profile is covered. The description adds valuable context: 'Supports bounded all_pages; every page counts against the API quota.' This goes beyond annotations by disclosing quota consumption and pagination behavior, which is important for a read tool with 24 parameters.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is three short sentences: a title, a vague statement 'Reads community data', and a note about all_pages and quota. While concise, the middle sentence 'Reads community data' is nearly redundant with the tool name and annotations, and the structure isn't optimally front-loaded with the most critical information (e.g., what the tool returns or how to use it).

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?

Given the complexity (24 parameters, no required ones) and the absence of an output schema, the description is minimally adequate. It covers the read-only nature and quota implications but doesn't explain return values, pagination limits beyond all_pages, or how to effectively use the many filters. With annotations and a rich schema, it's passable but leaves gaps in guiding the agent on expected outputs or advanced usage.

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 description coverage is 100%, so the schema fully documents all 24 parameters, including pagination and filtering options. The description doesn't add parameter-specific details, but since the schema is comprehensive, the baseline of 3 is raised because the description complements with behavioral notes about all_pages and quota, indirectly touching on parameter usage.

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 'Community Member Subscriptions List' and 'Reads community data', which identifies the resource (community member subscriptions) and the verb (reads/list). However, it doesn't explicitly distinguish this tool from its siblings like 'export_community_member_subscriptions' or 'list_charges', leaving some ambiguity about its specific scope.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description provides no guidance on when to use this tool versus alternatives such as 'export_community_member_subscriptions' or 'list_charges'. It also doesn't specify prerequisites or typical use cases, leaving the agent to infer usage from the tool name and schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_tagged_membersList Tagged MembersC

Read-onlyIdempotent

List Tagged Members. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`member_tag_ids`	No	Filter by Member Tag IDs (OR logic, comma-separated)

TDQS

C2.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so safety is covered. The description adds genuinely non-obvious operational context beyond the structured fields: pagination is bounded, every page consumes API quota, and all_pages is explicitly not a guaranteed complete snapshot. That is real behavioral value not present in the annotations or schema.

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?

Three short sentences with the pagination/quota caveat front-loaded and no padding. The only waste is the title restatement, which duplicates the name field rather than earning its place.

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?

With no output schema, the description should at least hint at the return shape (records, continuation state), and it only mentions continuation state parenthetically in the schema. The quota/pagination caveat is a good addition, but an agent still lacks a clear picture of what comes back or how this relates to get_tagged_member.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all six parameters are already documented in the input schema, including the all_pages and max_items semantics. The description adds no parameter-level meaning beyond that, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description opens by restating the title verbatim ('List Tagged Members') and adds only 'Reads community data,' which is a tautology for a read-only list tool. It never explains what a 'tagged member' is (members associated with member_tag_ids) nor distinguishes it from siblings like get_tagged_member, tag_member, or list_members.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No when-to-use or when-not-to-use guidance, and no routing to alternatives such as get_tagged_member for a single record. The only usage-adjacent text concerns pagination bounds, not tool selection.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_topicsList topicsB

Read-onlyIdempotent

List topics. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	query by name
`page`	No	Page number
`sort`	No	Sorting parameters (sort by name in ascending order, name in descending order, and by newest. Default is oldest)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.

TDQS

B3.2/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint and openWorldHint, so the safety profile is covered. The description adds genuinely new behavioral context beyond that: all_pages is bounded, each page consumes API quota, and the result is not a snapshot or guaranteed complete backup. That quota/pagination caveat is the kind of disclosure annotations cannot express.

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?

Three short, front-loaded sentences with no filler; the pass-through is trivial and the quota warning arrives early. It is slightly telegraphic 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 a read-only list tool with 100% parameter coverage and annotations covering safety, the description supplies the one non-obvious operational fact (bounded paging that costs quota). Nothing critical is missing, though field-level return detail and filtering strategy are left entirely to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents name, page, sort, account, per_page, all_pages and max_items, including the quota caveat on all_pages. The description reinforces the all_pages/quota behavior but adds no syntax or semantics the schema lacks, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb+resource ("List topics") but the opening sentence is essentially a restatement of the tool name, and it offers no differentiation from siblings such as list_posts, get_topic, or create_topic. An agent knows it lists topics but not how it relates to other topic or list operations.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives (e.g., get_topic for a single topic, or any search tool), nor any mentioned prerequisites or filters the caller should consider. "Reads community data" is a scope note, not usage guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_workflowsList a community's automations/workflowsA

Read-onlyIdempotent

List a community's automations/workflows. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number (min 1)
`query`	No	Filter by workflow name (substring match).
`status`	No	Filter by status. Omit to include archived; use `all` to exclude archived; use `archived` for only archived.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`per_page`	No	Records per page (max 100)
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`workflow_type`	No	Filter by type: dynamic (Automation), bulk_action (Bulk action), scheduled (Scheduled).

TDQS

A3.5/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, and non-destructive, so the safety profile is covered. The description adds genuinely useful behavior beyond that: the read quota cost of each page and the bounded nature of all_pages, warning the agent not to treat it as an exhaustive snapshot.

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?

Three short sentences, front-loaded with the operation, then scope, then the quota caveat. No filler or redundancy.

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?

With 8 optional params fully documented in the schema and annotations covering safety, the description is adequate but thin: it never mentions the filtering dimensions (query/status/workflow_type) or how results are consumed relative to get_workflow. It is complete enough to call, but not rich.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, including enum meanings and pagination bounds, so the schema carries the parameter burden and baseline is 3. The description restates all_pages/quota but adds no syntax or default detail beyond the 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?

States a specific verb and resource ('List a community's automations/workflows'), which is unambiguous about the operation. It does not, however, distinguish itself from siblings such as get_workflow, activate_workflow, or duplicate_workflow, so sibling differentiation is left to the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to use this versus get_workflow (single fetch) or the workflow mutation tools. The only usage-adjacent content is the all_pages/quota note, which is a cost warning rather than selection guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

mark_paywall_affiliate_payouts_paidMark Paywall Affiliate Payouts PaidB

Destructive

Mark Paywall Affiliate Payouts Paid. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_member_ids`	No	Community member IDs to scope the mark-paid to (max 20 per request). Omit to mark all processing payouts as paid.

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutation and non-idempotent nature is covered structurally. The description adds one genuinely useful non-annotation fact: the confirm=true precondition. It does not disclose what state is destroyed, whether the marking is reversible, or the effect on already-paid payouts.

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?

Two short sentences that are front-loaded with the action and the confirmation precondition. The only waste is that the opening sentence duplicates the title verbatim, but overall the definition is compact and easy to scan.

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 destructive, zero-required-parameter batch mutation with a nested payload object, the annotations cover the safety profile and the schema covers all inputs, so nothing critical is missing. The description nonetheless leaves unclear what 'mark paid' changes operationally (scope defaults, partial-member behavior) beyond the confirm gate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3 and the schema already documents account, confirm, payload, payload_file and community_member_ids. The description echoes confirm=true but adds no format, default or interaction detail beyond the schema (e.g. the account-vs-community distinction is schema-only). Baseline applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence is a verbatim restatement of the title, so the verb+resource is conveyed only through the name itself. It does not distinguish this tool from paywall-payout siblings such as start_paywall_affiliate_payouts or export_paywall_affiliate_payouts, leaving an agent to infer which payout operation applies. Purpose is understandable but adds no real clarity beyond the identifier.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'requires confirm=true for the user-requested action' implies the tool should be invoked only when the user explicitly asked for it, which is useful implied gating. However, no alternatives are named and no when-not-use conditions are given against the sibling payout tools. Guidance is implied rather than explicit.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

publish_paywallPublishes a paywallA

Destructive

Publishes a paywall. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`paywall_id`	Yes	Paywall ID

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, non-idempotent, and openWorld, so the safety profile is covered by structured data. The description adds genuinely new behavioral context beyond that: it 'changes community state' and enforces a confirm=true guard for user-requested actions, which tells the agent about the confirmation gate it must satisfy. It still doesn't disclose side effects on members or reversibility.

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?

Two short sentences, front-loaded with the action and followed by the state-change/confirm constraint; nothing is padded. It is slightly redundant with the title but stays efficient.

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 destructive, non-idempotent mutation with no output schema, annotations plus the confirm gate cover the essentials. What's missing is the effect of publishing (does the paywall become publicly reachable? what happens to already-published state?) and any auth/scope requirements tied to the account parameter.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (account, confirm, paywall_id) are already documented in the schema, giving a baseline of 3. The description only reinforces the confirm semantics already stated in the schema and says nothing about the account parameter or credential selection.

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?

States a specific verb+resource ('Publishes a paywall'), which is clearer than a bare name restatement. However, it does not distinguish this from sibling lifecycle tools such as archive_paywall, unarchive_paywall, or update_paywall_group, leaving the agent to infer what 'publish' means state-wise.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The confirm=true clause implies the tool should only be used when the user explicitly asked for this action, which is partial when-to-use guidance. There is no guidance on when to publish vs. archive/unarchive a paywall, nor prerequisites like required permissions or draft state.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

refund_community_member_chargeRefund Community Member ChargeB

Destructive

Refund Community Member Charge. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`amount`	No	Amount to refund (in currency subunits). Omit for a full refund.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`charge_id`	Yes	Community Member Charge ID
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`reason_details`	No	Refund reason. Required, 255 characters max.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false. The description's 'changes community state' largely restates that, but 'requires confirm=true for the user-requested action' is genuinely useful added context about a guard condition. It omits reversibility, permission requirements, and rate limits.

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?

Two compact sentences with no filler, and the state-changing/confirm constraint is front-loaded. It is efficient, though the opening restatement of the title is slightly redundant.

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 destructive, open-world, non-idempotent financial tool with a nested payload and multiple mutually exclusive body-input options, the description is thin. The schema and annotations carry most of the load, but the description never warns about irreversibility or the payload/payload_file exclusivity.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents charge_id, amount, account, confirm, payload, payload_file, and reason_details. The description adds no syntax or format detail beyond what the schema provides, so the baseline 3 applies.

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 (refund a Community Member Charge), making purpose unambiguous. However, the first sentence is essentially the title repeated verbatim, and there is no differentiation from sibling tools (e.g., cancel/resume subscription, list_charges).

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It discloses the confirm=true gating requirement and ties it to 'the user-requested action', which is a usage constraint. But it offers no when-to-use vs alternatives guidance, no prerequisites, and no exclusion cases (e.g., partial vs full refund conditions).

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_from_access_groupRemove Access Group MemberB

Destructive

Remove Access Group Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`access_group_id`	Yes

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds the confirm=true requirement and that community state changes, which is useful, but it omits what happens to the member, reversibility, or error behavior when the member is absent.

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?

Two short sentences with the confirm requirement front-loaded after the action statement. The first sentence merely restates the title, which is mildly redundant, but nothing else is wasted.

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 destructive, non-idempotent mutation with no output schema, the annotations plus the confirm note cover the essentials. What is missing is the consequence of removal and error/edge handling, leaving the definition adequate but thin.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 75%, so most parameters are documented in the schema itself, and the confirm parameter's meaning is already given there. The description restates the confirm=true requirement but adds no syntax or format detail beyond the schema, matching the baseline when structured fields do the heavy lifting.

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 ('Remove Access Group Member'), making the target object clear. It is distinguishable from add_to_access_group by the verb, though it does not explicitly name that sibling or contrast with remove_member/remove_space_member.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage via 'requires confirm=true for the user-requested action,' which tells the agent a confirmation gate exists. However, it offers no explicit when-to-use guidance or routing against alternatives like remove_member or remove_space_member, leaving usage largely inferred.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_memberDeactivate a community memberB

Destructive

Deactivate a community member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`member_id`	Yes	ID of the community member

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds that it 'changes community state' and enforces a confirm gate, but the confirm requirement is also spelled out in the schema, so the marginal disclosure is modest. Reversibility and the fate of the member's data remain unstated.

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?

Two short sentences, front-loaded with the action and followed by the operational constraint; no filler. It is tight, though the second sentence largely restates the schema's confirm guidance rather than adding new information.

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 destructive, non-idempotent mutation with no output schema, the description covers the action and the confirmation gate but omits reversibility, required permissions/scope, and what happens to the member's content. Annotations carry the safety signal, but the agent still lacks enough context to reason about consequences.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are already documented, including the 'confirm' gate ('Set true only when the user asked for exactly this action'). The description repeats the confirm requirement rather than adding syntax or constraints beyond the schema, so the baseline 3 applies.

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?

States a specific verb + resource ('Deactivate a community member') and usefully disambiguates the ambiguous tool name 'remove_member' by clarifying the action is deactivation, not deletion. It does not explicitly distinguish itself from close siblings like ban_community_member or delete_community_member, so it stops short of a 5.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Provides one concrete usage rule ('requires confirm=true for the user-requested action'), which is actionable. However, it never states when to prefer this over ban_community_member, delete_community_member, or remove_from_access_group, leaving the agent to infer sibling selection from names alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

remove_space_memberRemove Space MemberC

Destructive

Remove Space Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`email`	Yes	Email
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`space_id`	Yes	Space ID

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds two useful pieces of context beyond annotations: it "changes community state" and requires confirm=true, which the annotations do not mention. It still doesn't say whether removal is permanent or reversible.

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?

Two short sentences with no filler, and the behavioral constraint is front-loaded. The only waste is the opening restatement of the title, which occupies half the text.

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 destructive, non-idempotent mutation with no output schema, the annotations carry most of the safety burden and the schema fully documents parameters. The description adequately flags state change and the confirm gate, but leaves open what happens to the removed member's data or whether the action can be undone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the baseline is 3. The description reinforces the confirm parameter's intent, but adds no syntax, format, or constraint details beyond what the schema already documents for email, account, confirm, and space_id.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence restates the tool title verbatim ("Remove Space Member"), adding essentially nothing over the name. The resource is unambiguous, but the description never distinguishes this from close siblings such as remove_member, delete_community_member, or delete_space_group_member.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description only hints at when to set confirm=true ("for the user-requested action"). It gives no guidance on when to use this tool versus add_space_member, remove_member, or other member-removal siblings, and no prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

reorder_course_lessonsReorder course lessonsB

Destructive

Reorder course lessons. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`space_id`	No	ID of the course space
`new_order`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description usefully adds that it 'changes community state' and needs confirm=true, but does not disclose what the reorder replaces (whole-order overwrite) or the confirm semantics beyond what the schema says.

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?

Two short sentences with zero padding, front-loading the operation and then the confirm requirement. It is appropriately sized, though the single terse line leaves room without being wasteful.

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 6-parameter, nested-object mutation with no output schema, the description is thin: it never explains that new_order replaces the entire ordering, nor the payload/payload_file/body-flag alternatives. The confirm note is helpful, but key invocation details are left to the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents space_id, account, confirm, payload and payload_file. The description adds no parameter-level meaning, and notably omits that new_order must be a complete ordered listing of all sections/lessons, which is the semantically critical detail.

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 ('Reorder course lessons'), which is clear and concrete. However it does not differentiate from siblings like update_course_lesson or update_course_section, which also mutate lesson/section ordering, so an agent must infer the distinction from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

'requires confirm=true for the user-requested action' hints at the precondition for invoking it, but there is no explicit when-to-use versus when-not guidance and no mention of alternatives such as update_course_lesson for non-ordering edits. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

report_flagged_contentReport Flagged ContentC

Destructive

Report Flagged Content. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`flagged_content`	No

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the safety profile is largely covered. The description adds that this changes community state and requires confirm=true for the user-requested action, which is useful but overlaps the schema's confirm documentation. It omits what gets changed, permission requirements, and side effects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two sentences is compact, but the first is pure title repetition and earns nothing, while the second crams the only real information (state change + confirm) into one line. Front-loading is weak because the substantive clause comes second.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with a nested flagged_content object and three mutually exclusive body mechanisms (payload, payload_file, body flags), the description explains none of them and has no output schema to fall back on. An agent cannot tell what the call returns or which body form to choose.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is high (80%), so the schema already documents account, confirm, payload and payload_file. The description only echoes confirm=true and adds no syntax or semantics beyond the structured fields. Baseline 3 applies when the schema carries the burden.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence merely restates the tool name and title verbatim ('Report Flagged Content'), adding no verb+resource detail beyond the identifier. It never explains what reporting actually does to the flagged content or how it differs from the sibling list_flagged_content. The second sentence describes behavior, not purpose.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use or when-not-to-use guidance, and no mention of the obvious alternative list_flagged_content. The only usage-flavored statement is about confirm=true, which is already documented in the schema rather than being routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

resume_community_member_subscriptionResume Community Member SubscriptionB

Destructive

Resume Community Member Subscription. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`subscription_id`	Yes	Community Member Subscription ID

TDQS

B3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so mutation and openness are known. The description usefully adds that it 'changes community state' and that confirm=true is required, but it never says what is actually resumed or what side effects (billing, notifications) occur.

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?

Two short sentences with the mutation warning and confirm gate front-loaded and no filler. It is efficient, though the first sentence is largely wasted on restating the title.

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 a 1-required-param mutation with rich annotations and no output schema, the essentials (mutating, confirm gate) are covered. The main gap is the absence of any when-to-use context relative to cancel/archive siblings.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so subscription_id, account, and confirm are already documented in the schema. The description echoes the confirm requirement but adds no format, constraint, or usage nuance beyond the schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence 'Resume Community Member Subscription' restates the tool name/title rather than explaining what resuming a subscription entails. The verb+resource are recoverable, but there is no differentiation from the sibling cancel_community_member_subscription or any hint about what state changes.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description states a prerequisite ('requires confirm=true') but gives no when-to-use guidance and names no alternative. An agent learning only from this text cannot tell when resume is appropriate versus cancel or archive.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

revoke_invitation_linkRevoke invitation linkA

Destructive

Revoke invitation link. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`invitation_id`	Yes	Invitation link ID

TDQS

A3.6/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false, so safety is partly covered. The description adds genuinely new behavioral context: the operation mutates community state and is gated behind an explicit confirm=true flag tied to user intent, which is not derivable from the annotations.

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?

Two tight sentences with the operation stated first and the confirm precondition second. The opening 'Revoke invitation link' slightly duplicates the title and name rather than using the space for differentiation, which keeps it short of a 5.

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?

With no output schema, the description needn't explain returns, and annotations carry the destructive profile. Still missing for a destructive tool: whether revocation is permanent or recoverable, and what happens to already-accepted invitations. Adequate but with clear gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (account, confirm, invitation_id) are already documented in the schema. The description reinforces the confirm semantics but adds no syntax, format, or edge-case detail beyond what the schema provides; baseline 3 applies.

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 gives a specific verb ('Revoke') and resource ('invitation link'), so the basic operation is unambiguous. However, the sibling set contains delete_invitation_link and update_invitation_link, and nothing here explains how revocation differs from deletion — the agent must guess which one applies.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It states a concrete precondition — confirm=true is required, and only when the user requested exactly this action — which is real usage guidance. It does not, however, address when to prefer this tool over delete_invitation_link or update_invitation_link, leaving the key routing decision implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

searchAdvanced SearchC

Read-onlyIdempotent

Advanced Search. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`page`	No	Page number
`type`	No	Search type
`query`	Yes	Search query
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`filters`	No	Filters
`per_page`	No	Number of records per page
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`mention_scope`	No	Mention scope

TDQS

C2.9/5.0

Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, idempotentHint=true, and destructiveHint=false, covering the safety profile. The description adds useful behavioral context beyond annotations: 'Supports bounded all_pages; every page counts against the API quota,' disclosing quota consumption and bounded pagination. This is valuable rate-limit and execution behavior not otherwise stated.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is very short (three sentences) and front-loads the quota note, but the first sentence 'Advanced Search' merely repeats the title and does not earn its place. 'Reads community data' is vague, while the quota sentence is the only genuinely informative one. It is concise but inefficient in content allocation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter search tool with nested filters, multiple search types, and many sibling search tools, the description is insufficient. It does not explain what entity types are searched, when to choose this tool over specialized alternatives, or what the bounded all_pages return behavior implies beyond quota. Annotations cover safety, but routing and scope remain unclear.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all parameters are already well documented in the input schema, including all_pages, max_items, account, and filters. The description adds no additional parameter meaning beyond what the schema provides. Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description says 'Advanced Search. Reads community data,' which states a verb and resource but remains very broad. It does not specify that it searches across multiple entity types (posts, members, comments, etc.) and does not distinguish itself from sibling search tools like search_member or search_paywalls. The purpose is implied but vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this generic search versus the many sibling search tools (search_member, search_paywalls, search_locations). The only usage-related note is about all_pages quota, which is about behavior, not context selection. An agent is left to infer usage conditions from the schema alone.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_locationsSearch locationsC

Read-onlyIdempotent

Search locations. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`query`	Yes	Free-text location query (e.g. 'San Francisco, CA' or 'Berlin').
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.3/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=true, openWorldHint=true, and idempotentHint=true, and "Reads community data" merely echoes the read-only nature without adding anything. No mention of result format, pagination, rate limits, or credential behavior despite the account parameter implying auth selection.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two very short sentences with no padding, and the core purpose is front-loaded. However, the brevity comes at the cost of substance rather than being disciplined conciseness.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a two-parameter lookup with no output schema, the description leaves key context unstated: what a "location" object is in this domain, and what "community data" being read implies for results. Annotations cover the safety profile, but the description does not carry its share for a discovery tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so both the free-text query and the named-account semantics are fully documented in the schema. The description adds nothing on top of that, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Search locations" restates the tool name and title verbatim, so it does not distinguish the tool from siblings like search, search_member, or search_paywalls. "Reads community data" is a vague qualifier that adds no specificity about what a location is or what data is read.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus the many other search_* siblings or list_* tools. The agent must infer from the name alone that this is for geographic location lookups.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_memberSearch a community memberC

Read-onlyIdempotent

Search a community member. Reads community data.

ParametersJSON Schema

Name	Required	Description	Default
`email`	Yes	Email of the community member
`account`	No	Named private Circle account; selects credentials, not a remote community ID.

TDQS

C2.1/5.0

Behavior2/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description's 'Reads community data' merely echoes readOnlyHint and adds nothing about lookup behavior, miss handling, or scoping that the annotations don't already provide.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

At two short sentences it is certainly concise, but the second sentence ('Reads community data') is redundant with the readOnly annotation and the first repeats the title, so neither fully earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With no output schema and only safety annotations, the description carries the burden of explaining what a search returns, how a missing member is handled, and how it relates to get_member/list_members. None of that is present, leaving the definition incomplete for an agent deciding between member-lookup tools.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 100%, and the schema itself explains that 'account' selects credentials rather than a remote community ID and that 'email' identifies the member. The description adds no parameter meaning beyond this, so the baseline 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description 'Search a community member' simply restates the tool name and title, adding no distinguishing detail. It does not differentiate this tool from close siblings like get_member, list_members, or search, so an agent cannot tell them apart from the text alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines1/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives such as get_member or list_members, nor any prerequisites or exclusions. 'Reads community data' is a vague tagline, not usage direction.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

search_paywallsSearch PaywallsC

Read-onlyIdempotent

Search Paywalls. Reads community data. Supports bounded all_pages; every page counts against the API quota.

ParametersJSON Schema

Name	Required	Description
`name`	No	Filter by paywall name or display name (partial match)
`page`	No	Page number
`sort`	No	Sort field (one of: title, status, created_at). Defaults to created_at
`status`	No	Comma-separated list of statuses (e.g. draft,active,inactive)
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`currency`	No	Comma-separated list of currency codes
`per_page`	No	Records per page (max 100)
`all_pages`	No	Read bounded page/per_page pages; each request consumes API quota. Not a snapshot or guaranteed complete backup.
`direction`	No	Sort direction (asc or desc). Defaults to desc. Only takes effect when sort is also given -- direction alone is ignored
`max_items`	No	Maximum returned records with all_pages=true, default 1000. At most 100 requests; output includes continuation state.
`paywall_id`	No	Comma-separated list of paywall IDs to include
`exclude_paywall_id`	No	Comma-separated list of paywall IDs to exclude
`subscription_group_id`	No	Comma-separated list of subscription group IDs to include
`exclude_subscription_group_id`	No	Comma-separated list of subscription group IDs to exclude

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnly, idempotent, non-destructive, and open-world. The description adds one genuinely useful piece of context beyond them: that every page consumes API quota and that all_pages is bounded. It does not address permissions, return shape, or continuation handling in the description itself.

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?

Three short fragments, front-loaded with the resource and the most important constraint (quota cost). It is tightly sized, though one fragment is filler ('Reads community data').

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 14-parameter search with no output schema, the description covers the quota caveat but omits return/continuation behavior and does not route the agent to alternatives. The complete schema mitigates this, leaving it adequate but not complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all 14 parameters are already documented in the schema, including quota and continuation notes on all_pages and max_items. The description adds little parameter meaning beyond the schema, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The name and title already say 'Search Paywalls', and the description mostly restates that with the vague addendum 'Reads community data'. It gives a verb+resource but does not clarify scope or distinguish this from siblings like search, search_locations, or search_member.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus alternatives, no prerequisites, and no conditions. The mention of all_pages is behavioral, not directional.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

send_messageCreate MessageC

Destructive

Create Message. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`user_email`	No
`user_emails`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`chat_room_uuid`	No
`rich_text_body`	No
`parent_message_id`	No

TDQS

C2.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely useful disclosure beyond them: the mandatory confirm=true gate and that the operation 'changes community state.' It still omits what gets mutated, delivery semantics, or any rate-limit context.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is short and front-loaded, but the first sentence is pure filler that duplicates the title, and the second sentence crams a state-change claim and a confirmation rule into one clause. It is efficient in length but low in information density.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 9-parameter mutation tool with nested rich-text objects, zero required fields, no output schema, and an openWorld hint, the description is far too thin. An agent cannot tell from it how to target a recipient, what rich_text_body should contain, or what the confirmation actually authorizes.

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 only 44% across 9 parameters, and the description explains none of them. Key selectors such as user_email, user_emails, chat_room_uuid, rich_text_body, and parent_message_id are undocumented in both the schema and the prose, so the description fails to compensate for the coverage gap.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The body is essentially the title restated: 'Create Message.' It names no target (DM vs. chat room), no scope, and does nothing to distinguish it from close siblings like create_comment, create_post, or import_chat_room_message. This is tautological rather than a specific verb+resource with sibling differentiation.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no when-to-use guidance and no named alternative. The only actionable hint is the bare mention that confirm=true is required 'for the user-requested action,' which is a gating note rather than usage context, and it doesn't say when NOT to use the tool or which sibling to prefer.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

start_paywall_affiliate_payoutsStart Paywall Affiliate PayoutsB

Destructive

Start Paywall Affiliate Payouts. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_member_ids`	No	Community member IDs to scope the start to (max 20 per request). Omit to start all due payouts.

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds real value beyond that by stating it 'changes community state' and requires confirm=true, but it never says what the mutation actually does (e.g., that it initiates payouts) or what side effects result.

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?

Two short, front-loaded sentences with no filler or redundancy in length. It is efficient, though the opening sentence is a pure restatement of the title and so earns less than a fully front-loaded definition would.

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 an optional-parameter, no-output-schema mutation tool whose annotations already cover destructiveness, the definition is minimally sufficient — it flags the confirm gate and the state change. It stops short of explaining the actual payout effect or the account/payload_file mutual-exclusion constraints, so an agent still has gaps.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema already documents confirm, payload, payload_file, account, and community_member_ids in detail. The description's only parameter remark repeats the confirm requirement already in the schema, adding no meaning. Baseline 3 is correct.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence simply restates the title verbatim, adding no information an agent didn't already have from the name. The only added content ('Changes community state') is behavioral, not purpose, and no distinction is drawn from close siblings like mark_paywall_affiliate_payouts_paid or export_paywall_affiliate_payouts. Purpose is inferable from the name but the description itself does not sharpen it.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description gives one concrete usage constraint — confirm=true is required for the user-requested action — which is genuinely useful for invocation. However, it offers no guidance on when to pick this tool versus mark_paywall_affiliate_payouts_paid (marking as paid) or export_paywall_affiliate_payouts, leaving the main selection question unanswered.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

tag_memberCreate Tagged MemberC

Destructive

Create Tagged Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`user_email`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_tag_id`	No

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered structurally. The description adds a genuine behavioral constraint beyond the annotations: that the action mutates community state and is gated behind confirm=true tied to an explicit user request. It still omits what state changes occur and whether the tagging is reversible.

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?

Two short sentences, front-loaded, with no padding. The wording is efficient, though the first sentence contributes almost no information because it merely restates the title.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with a nested payload object, six parameters, and no output schema, the description is far too thin. It never explains what a member tag is, what member_tag_id refers to, or how account selects credentials, leaving significant gaps.

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 coverage is moderate (67%) and the description explains nothing about the parameters beyond reasserting the confirm gate already documented in the schema. The undocumented top-level user_email and member_tag_id body flags, plus the mutual exclusivity of payload vs. body flags vs. payload_file, are not compensated for in the description.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The only purpose statement is 'Create Tagged Member,' which repeats the tool name and title verbatim, making it essentially a tautology rather than a description of the member-tag association being created. It gives the agent no way to distinguish this from siblings like create_member_tag, untag_member, or create_space_group_member.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'requires confirm=true for the user-requested action' is the only usage signal, and it concerns confirmation rather than when to choose this tool over alternatives. No guidance is offered on when to tag a member versus creating a tag or adding them to a group.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unarchive_access_groupUnarchive Access GroupA

Destructive

Unarchive Access Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`access_group_id`	Yes	Access Group ID

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, and openWorldHint=true. The description adds the confirmation requirement ('requires confirm=true'), which is useful behavioral context not present in annotations, but it does not explain what community state changes, authentication needs, or reversibility.

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?

The description is two short sentences with the action front-loaded. The first sentence merely repeats the title, which is slightly wasteful, but the second sentence efficiently conveys the behavioral constraint.

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 a simple mutation tool with full schema coverage and annotations covering safety traits, the description adds the important confirm=true requirement. It omits explicit routing to archive_access_group, but otherwise gives enough context to invoke the tool correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters are documented in the schema. The description's mention of confirm=true does not add meaning beyond the schema's own description for that parameter, so the baseline of 3 applies.

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 and resource ('Unarchive Access Group'), making the action immediately clear. However, it does not distinguish this tool from the sibling archive_access_group or explain what unarchiving restores, so sibling differentiation is absent.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies usage by noting that confirm=true is required for the user-requested action, which gives a condition for proper invocation. It does not state when to use this tool versus archive_access_group or update_access_group, nor does it offer explicit when-not guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unarchive_paywallUnarchives a paywallB

Destructive

Unarchives a paywall. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`paywall_id`	Yes	Paywall ID

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, and idempotentHint=false, so the agent knows this is a mutating, non-idempotent, destructive operation. The description adds that it "changes community state" and requires confirm=true, but does not say what is destroyed, whether the action is reversible, or whether re-running it is safe despite the false idempotency hint.

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?

Two short, front-loaded sentences with no filler; the action is stated first and the confirm requirement second. It is efficient, though the "Changes community state" clause overlaps with what the destructiveHint annotation already conveys.

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 3-parameter destructive mutation with no output schema, the definition covers action and the confirm gate but leaves reversibility and side effects on the paywall's associated state implicit. Adequate but with clear gaps for a destructive operation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so account, confirm, and paywall_id are all documented in the schema itself. The description reinforces the meaning of confirm ("for the user-requested action") but adds no syntax, format, or constraint detail beyond the 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 gives a specific verb+resource ("Unarchives a paywall"), which is unambiguous and self-evidently the inverse of the sibling archive_paywall. It does not explicitly name or contrast against that sibling, but the action is clearly distinguishable from list/get/update paywall tools.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

"requires confirm=true for the user-requested action" implies the tool should only be called when the user explicitly asked to unarchive, which is useful gating guidance. However, there is no explicit when-not guidance, no stated prerequisite (e.g., paywall must currently be archived), and no named alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unarchive_profile_fieldUnarchive Profile FieldB

Destructive

Unarchive Profile Field. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`profile_field_id`	Yes	Profile field ID

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is covered. The description adds one genuinely new fact — that the call changes community state — but the confirm=true note merely restates the schema's own parameter description. No mention of permissions, reversibility, or side effects.

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?

Two short sentences with the resource and the key precondition front-loaded and no filler. Slightly redundant with the title and schema, but tight overall.

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 destructive, non-idempotent mutation with no output schema, the annotations cover the safety profile and the schema covers the parameters, so the basics are present. Still missing are the effects of unarchiving on the field's prior state and any permission requirements an agent should anticipate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so all three parameters (account, confirm, profile_field_id) are already documented in the schema, including the credential-selection semantics of 'account'. The description adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

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?

States a specific verb and resource ('Unarchive Profile Field'), so the agent knows exactly what operation is performed. It does not differentiate itself from sibling operations like archive_profile_field or delete_profile_field, leaving the routing decision to the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes the confirm=true precondition, which is a usage constraint, but says nothing about when to choose unarchive over archive/delete, nor what state the field must be in for this to apply. Usage is implied rather than explained.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

unfollow_postUnfollow a postA

Destructive

Unfollow a post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`post_id`	Yes	Post ID
`community_member_id`	Yes	Community Member ID

TDQS

A3.5/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the safety profile is covered structurally. The description adds that the call 'changes community state' and requires an explicit confirm flag, which is useful context, but it doesn't explain reversibility or side effects on notifications/feeds.

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?

Two short sentences with the purpose front-loaded and no filler. The phrase 'for the user-requested action' is slightly redundant with 'requires confirm=true' but does not bloat the definition.

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 a simple two-required-parameter mutation with annotations supplying the safety profile and no output schema, the description covers purpose, state change and the confirm gate. It omits failure modes (e.g. not-followed error) and authorization requirements, which keeps it short of a 5.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% — post_id, community_member_id, account and confirm are all documented inline, and the description's confirm guidance duplicates the schema wording. Baseline 3 is appropriate since the schema carries parameter meaning.

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?

States a specific verb+resource ('Unfollow a post') that an agent can act on without ambiguity. It does not differentiate from any sibling (no follow/unfollow alternative exists in the sibling list), but the operation is self-evident.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies when the tool applies and adds a gating rule ('requires confirm=true for the user-requested action'), but gives no when-not guidance, no mention of preconditions such as prior follow state, and no routing to alternative tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

untag_memberDelete Tagged MemberB

Destructive

Delete Tagged Member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`user_email`	Yes	User Email
`member_tag_id`	Yes	Member Tag ID

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is known. The description adds the confirm gate and 'changes community state', but the confirm semantics are also duplicated in the schema's parameter description, so net added value is modest.

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?

Two short, front-loaded sentences with no padding. Minor waste in the first sentence restating the title verbatim rather than elaborating.

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?

No output schema exists, so the description need not explain returns, and annotations plus full schema coverage carry most of the burden. However, 'changes community state' is vague about what exactly is destroyed (tag removal vs. member deletion), leaving the agent to infer the effect.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so parameters (account, confirm, user_email, member_tag_id) are already documented in the schema. The description only gestures at confirm and adds no syntax or format detail beyond what the schema provides; baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb+resource ('Delete Tagged Member'), but it is a verbatim repetition of the title, so it offers no information beyond the already-visible name/title. It also fails to distinguish this tool from close siblings like tag_member, delete_member_tag, or remove_member.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage via 'requires confirm=true for the user-requested action', which is a real prerequisite, but there is no explicit when/when-not guidance and no mention of the alternative tagging tools an agent might confuse this with.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_access_groupUpdate Access GroupC

Destructive

Update Access Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`access_group`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`access_group_id`	Yes	Access Group ID

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the safety profile is covered. The description adds a genuine behavioral detail (the confirm=true gate), but says nothing about what state is changed, reversibility, or consequences of a bad update.

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?

Two short sentences with no padding, and the confirm requirement is front-loaded. It is efficient, though the first sentence wastes words by echoing the title.

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?

Given annotations that carry the destructive profile and 83% schema coverage, the description is minimally adequate for a 6-param mutation tool with nested objects. It remains thin on what the update actually affects and how payload versus body flags are meant to be used.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents confirm, account, payload, payload_file, and access_group_id. The description's mention of confirm adds no meaning beyond the schema's own 'Set true only when the user asked for exactly this action,' so baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence 'Update Access Group' simply restates the title, and 'Changes community state' is a vague hint at the effect. It names the verb+resource but offers no differentiation from siblings like archive_access_group, unarchive_access_group, or create_access_group.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage signal is 'requires confirm=true for the user-requested action,' which is a prerequisite rather than when-to-use guidance. Nothing tells the agent when to prefer this over archive_access_group, unarchive_access_group, or create_access_group.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_chat_preferencesUpdate Chat PreferencesC

Destructive

Update Chat Preferences. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`messaging_enabled`	No	Enable or disable messaging for the community
`voice_messages_enabled`	No	Enable or disable voice messages for the community
`group_messaging_enabled`	No	Enable or disable group messaging for the community
`member_to_member_messaging_enabled`	No	Enable or disable member-to-member messaging for the community

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true and idempotentHint=false, so the mutation/safety profile is covered. The description usefully adds the confirm-gate requirement, but does not explain what state is changed, whether changes are reversible, or any auth/permission implications.

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?

Two short, front-loaded sentences with no filler or repetition. It is efficiently sized, though the brevity comes partly from under-specification rather than tight editing.

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 destructive mutation with 8 parameters, a nested payload object, and mutually exclusive input modes (flags vs payload vs payload_file), the description offers minimal context. Annotations carry the safety profile and the schema carries parameter detail, but the description does nothing to clarify the payload-vs-flags choice or the scope of "community state."

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% across all 8 parameters, so the schema already documents account, confirm, payload and the four messaging flags. The description's confirm note largely duplicates the schema's own "Set true only when the user asked for exactly this action," adding no syntax or precedence detail beyond it.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update Chat Preferences" simply restates the tool name and title; the only added information is the generic note that it "Changes community state." It never names which preferences are affected (messaging, voice, group messaging), so an agent cannot distinguish its scope from siblings like update_community or update_connect_settings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It supplies one concrete usage rule — confirm=true is required for the user-requested action — which is genuine when-to-use guidance. However, it names no alternatives and gives no exclusion criteria among the many update_* siblings, leaving routing to inference.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_communityUpdate CommunityC

Destructive

Update Community. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`community`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_setting`	No

TDQS

C2.6/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is known. The description's "changes community state" is consistent with that and it usefully surfaces the confirm=true requirement, but it never explains what is destroyed, whether the change is reversible, or what the openWorld remote mutation affects.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences, front-loaded, but the opening sentence duplicates the title verbatim and earns nothing. The remaining sentence is efficient; the text is brief but under-informative rather than over-long.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive, non-idempotent, open-world mutation with six parameters, deeply nested community/community_setting payloads, no required fields, and no output schema. A two-sentence description that names no updatable fields and no side effects is far too thin for that complexity.

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?

Six parameters at 67% schema description coverage; the schema already documents account, confirm, payload and payload_file. The description adds nothing beyond repeating the confirm requirement, and the large community/community_setting nested objects (the actual substance of the call) get no explanation of which fields are updatable or how partial updates behave.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update Community" names a verb and resource, and "Changes community state" confirms it is a mutation, but it never says what state (name, prefs, branding, digest settings, etc.) nor distinguishes it from close siblings like update_community_segment, update_space, update_connect_settings or update_tax_settings. The first sentence is essentially a restatement of the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is "requires confirm=true for the user-requested action," which is a gating condition rather than when-to-use guidance. There is no mention of prerequisites (admin scope, account selection), no indication of when to prefer get_community or a sibling update tool, and no when-not-to-use statement.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_community_segmentUpdate a community segmentC

Destructive

Update a community segment. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`rules`	No
`title`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`visible`	No
`segment_id`	Yes	ID of the community segment to update
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`community_segment_consumer_attributes`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is covered. The description adds the confirm=true requirement, a genuinely useful behavioral gate, but says nothing about reversibility, credential selection via the account param, or side effects on members.

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?

Two short sentences, front-loaded with the action and then the confirm gate; no filler. Brevity is appropriate, though it borders on under-specification for a 9-parameter mutation.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 9 parameters, nested objects, and no output schema, the description is too thin. It omits the payload/payload_file/body-flag alternatives and any indication of what 'changes community state' actually affects.

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 only 56% across 9 parameters, and the description compensates for none of it beyond restating confirm. It does not clarify the payload vs. payload_file vs. body-flag mutual exclusion, nor the rules/rule_type structure.

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?

States a specific verb and resource ('Update a community segment'), which distinguishes it from create/delete/duplicate siblings by name. However, it adds no scope detail (e.g. what a segment is or what parts are updated) beyond the title.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description notes confirm=true is required 'for the user-requested action', which hints at a gating condition, but it never says when to choose this tool over siblings like create_community_segment or delete_community_segment, nor what prerequisites exist.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_connect_settingsUpdate Connect settingsB

Destructive

Update Connect settings. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`connect`	No
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`messaging`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_directory`	No

TDQS

B3.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the risk profile is covered by structured data. The description's added value is the confirm gate tying the mutation to an explicit user request, but it says nothing about partial-merge behavior, what happens to omitted settings, or permission requirements for a destructive multi-section update.

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?

Two short sentences, mutation scope front-loaded, no filler. It is efficient, though the brevity is partly a symptom of under-specification rather than disciplined trimming.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent tool with 7 parameters, deep nested objects, three mutually exclusive body-passing mechanisms and no output schema, two sentences are far too thin. The agent must go entirely to the schema to learn how to construct a valid call.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 57% with 7 parameters, so the description should compensate more than it does. It only restates the confirm parameter, which the schema already documents verbatim in spirit, and says nothing about the payload vs. body-flags vs. payload_file exclusivity or the nested connect/messaging/member_directory groups.

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?

States a specific verb+resource ('Update Connect settings') and adds that it changes community state. It does not differentiate itself from the sibling get_connect_settings, so the agent gets the purpose but not the contrast.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It gives one concrete precondition ('requires confirm=true for the user-requested action'), which is genuine conditional guidance. However it never says when to choose this over get_connect_settings or other update_* configuration tools, leaving the selection decision implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_course_lessonUpdate a course lessonC

Destructive

Update a course lesson. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`status`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`body_html`	No
`lesson_id`	Yes	ID of the course lesson
`thumbnail`	No	signed_id of the lesson thumbnail image returned from the direct upload endpoint
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`featured_media`	No	signed_id of the lesson featured media file returned from the direct upload endpoint
`rich_text_body`	No
`is_comments_enabled`	No
`is_featured_media_enabled`	No
`is_featured_media_download_enabled`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds the confirm=true safety gate and notes it "changes community state," which is useful context, but it does not disclose what is destroyed, auth needs, or partial-update behavior.

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?

Two tight sentences with the mutation and confirm constraint front-loaded. Nothing is padded, though the brevity comes at the cost of missing detail rather than being truly economical.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 14-parameter, nested-object mutation tool with no output schema and a 50% schema coverage, the description is far too thin. It omits the mutually exclusive input modes (payload_file vs. body flags vs. payload) that an agent must understand to invoke it correctly.

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?

With 14 parameters and only 50% schema description coverage, the description carries a compensation burden it does not meet. It adds no meaning to lesson_id, account, payload vs. body flags vs. payload_file, or the nested rich_text_body, leaving several parameters ambiguous.

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?

States a specific verb+resource ("Update a course lesson") that an agent can distinguish from the create/delete lesson siblings. However, it does not differentiate itself from closely related siblings like update_course_section, update_course_progress, or reorder_course_lessons.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is a precondition ("requires confirm=true"), not a when-to-use rule. It names no alternatives, no when-not conditions, and no prerequisites such as the lesson needing to exist or which fields are mutable.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_course_progressUpdate Course Lesson ProgressC

Destructive

Update Course Lesson Progress. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`status`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`lesson_id`	No
`member_email`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the mutation and non-idempotent profile is covered structurally. The description adds that it 'Changes community state' and enforces a confirm gate, which is useful context, but it never states what state is altered or what is destroyed.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loaded, but the opening sentence simply echoes the title and earns no place. The second sentence carries the only substantive content, so the structure is efficient but under-loaded for a 7-parameter destructive tool.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent, open-world mutation with 7 parameters, nested payload, and no output schema, the description is far too thin. It omits what changes, whether progress is reversible, and how payload/payload_file/body-flag alternatives interact.

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 only 57 percent across 7 parameters, including a nested payload object, yet the description adds no meaning beyond referencing confirm=true. The account-credential-selection nuance, status enum, and payload/body-flag interaction are left entirely to the schema.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence is a verbatim restatement of the tool title 'Update Course Lesson Progress', making it a tautology rather than an explanation. Nothing distinguishes it from the sibling update_course_lesson, nor does it clarify that this marks a member's per-lesson completion status. An agent gets the resource but no added meaning beyond the name.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this versus update_course_lesson, reorder_course_lessons, or get_course_lesson. The only conditional, 'requires confirm=true for the user-requested action', is a gating constraint rather than usage routing and largely duplicates the confirm parameter's own schema description.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_course_sectionUpdate a course sectionB

Destructive

Update a course section. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`section_id`	Yes	ID of the course section
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, readOnlyHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds useful context beyond them by stating that the call changes community state and is gated behind confirm=true; it still says nothing about what is destroyed or overwritten by an update.

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?

Two short sentences with no filler, and the confirmation constraint is stated up front after the purpose. It is efficient, though the extreme brevity leaves gaps the description could have filled.

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 destructive, non-idempotent mutation with six parameters, a nested payload object and no output schema, the description is thin: it never mentions which fields are updatable (name) or how payload/payload_file/body-flag modes interact. Annotations cover the safety side, but the description leaves an agent needing to infer the rest from the schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already explains account, confirm, payload, payload_file and section_id. The description only reinforces the confirm semantics, adding little syntax or format detail about the nested payload or the payload/payload_file exclusivity beyond what the schema states.

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?

States a specific verb and resource ('Update a course section'), so an agent can immediately tell it is a mutation on an existing section rather than a create/delete. It does not, however, distinguish itself from siblings like update_course_lesson or update_course_progress, which share the same naming shape.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'requires confirm=true for the user-requested action' implies the tool should only be invoked when the user explicitly asked for this change, which is mild usage guidance. There is no explicit when-to-use/when-not, no prerequisite list, and no routing to create/delete/get section alternatives.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_eventUpdate EventC

Destructive

Update Event. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`event`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`event_id`	Yes	Event ID
`space_id`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, covering the safety profile. The description adds two genuinely useful behavioral facts: the mutation "changes community state" and that confirm=true gates the action. However, it does not disclose what is destroyed, permission needs, or rate limits, so it only modestly exceeds the annotation baseline.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is short and front-loaded, but the leading sentence is a redundant restatement of the name, so not every sentence earns its place. The useful content (confirm requirement, state change) is present but minimal.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a complex, non-idempotent, destructive mutation with nested objects and no output schema, the description is inadequate. It omits guidance on the three body-input strategies (event object, payload, payload_file) and on the multi-field event structure, leaving the agent to infer how to assemble a correct call.

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?

With 7 parameters (including a deeply nested event object, payload, and payload_file) at 71% schema coverage, the description should clarify the structural options. It mentions only confirm, which the schema already documents, and says nothing about how payload, payload_file, and body flags relate or how to use the nested event fields.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update Event." restates the tool name and title almost verbatim, making the opening sentence tautological. The clause "Changes community state" adds only a vague sense of scope and does not distinguish this from siblings like create_event, delete_event, duplicate_event, or update_post.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description implies the tool is for a "user-requested action" and that confirm=true is required, but gives no explicit when-to-use versus alternatives. It never tells the agent how to choose between update_event and its closely related event siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_filter_controlUpdate a member directory or member space filter controlB

Destructive

Update a member directory or member space filter control. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`key`	No	Filter to control.
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`enabled`	No	Whether the filter is shown. Set false to hide it.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`sort_key`	No	Ordering position; lower values sort first.
`space_id`	No	Member space ID to move this control to.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`profile_field_id`	No	Profile field ID for a profile_field control.
`filter_control_id`	Yes	Filter control ID. Use list_filter_kit_controls if the ID is unknown.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the write/destructive nature is covered. The description adds the confirmation gate and 'Changes community state', which is mildly useful, but says nothing about reversibility, partial-update behavior, or what an unconfirmed call does. With annotations carrying the safety profile, this is an adequate 3.

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?

Two tight sentences, front-loaded with purpose and followed by the constraint. No filler, though it is perhaps terse for a 10-parameter destructive mutation.

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 10-parameter, nested-object, destructive mutation with no output schema, the description is thin: it does not address partial updates, whether omitted fields are preserved or reset, or the consequence of an unconfirmed call. Annotations cover safety and the schema covers parameters, so it borders on adequate, but the behavioral context for a destructive tool is underdeveloped.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100%, so the schema fully documents all parameters including the confirm semantics and nested payload. The description adds no parameter meaning beyond that, which is the correct baseline of 3 when the schema does the heavy lifting.

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?

States a specific verb ('Update') and resource ('filter control') with the two scoping contexts (member directory vs member space). It is clearly differentiable from create_filter_control/delete_filter_control/get_filter_control by resource, though it does not name those siblings explicitly.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

Implies usage through the confirm requirement ('requires confirm=true for the user-requested action'), which tells the agent when confirmation is appropriate, but gives no explicit when-to-use vs. alternatives or when-not-to-use guidance against sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_formUpdate a formC

Destructive

Update a form. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`status`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`form_id`	Yes	Form ID
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`elements`	No
`popup_delay`	No
`embed_styles`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`redirect_url`	No
`popup_frequency`	No
`thank_you_page_body`	No
`embed_display_format`	No
`thank_you_page_title`	No
`standalone_page_styles`	No
`after_submission_action`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false and openWorldHint=true, so the mutation profile is largely covered. The description adds two useful facts beyond that: it changes community state and it requires confirm=true for the user-requested action. However, it omits critical behavioral constraints the schema carries, such as the mutual exclusivity of payload, payload_file and body flags.

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?

Two short sentences with the core action front-loaded and no filler. The brevity is efficient even though it borders on under-specification given the tool's complexity.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 17 parameters, nested objects, 29% schema coverage and no output schema, this description is far too thin. It does not explain the three-way body-input mutual exclusivity, the element/payload structure, or what the confirm gate actually guards, leaving the agent without enough context to call it correctly.

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 only 29% across 17 parameters, so the description must compensate and largely fails to. The only parameter it touches is confirm, and that merely restates the schema's own description; the important payload vs payload_file vs body-flags exclusivity, the nested elements structure and the many style/redirect fields get no explanation.

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?

States a specific verb (Update) and resource (a form), so the agent knows this mutates an existing form. It does not differentiate itself from the many siblings in the form family (delete_form, duplicate_form, get_form, create_form_submission), so it lands at a clear-but-undifferentiated 4.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to choose update_form over its alternatives such as duplicate_form or create_form_submission. The only usage-adjacent content is the confirm=true instruction, which is a safety gate rather than routing guidance, leaving the agent to infer the context.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_invitation_linkUpdate invitation linkC

Destructive

Update invitation link. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No	Name for the invitation link
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`paywall`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`invitation_id`	Yes	Invitation link ID
`member_tag_ids`	No	Member tag IDs to apply when the link is used
`access_group_ids`	No	Access group IDs to attach; fully replaces the current set (empty array detaches all)
`redirect_space_id`	No	ID of the space to open after signup. Set to null to remove the existing redirect

TDQS

C2.8/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare readOnlyHint=false, destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is largely covered. The description adds the non-obvious requirement of confirm=true and confirms it mutates community state, but says nothing about which fields get overwritten, whether omitted fields are preserved, or the payload/payload_file/body-flags exclusivity.

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?

Two short sentences with no filler, and the state-changing/confirm requirement is front-loaded right after the purpose. It is efficient but under-specified rather than tight-by-design.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 10 parameters (including nested paywall, tags, access groups, redirect and three mutually exclusive body-passing modes) and no output schema, the description omits too much: overwrite semantics, confirm behavior, and how to choose among payload, payload_file, and body flags.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 90%, so the schema already documents nearly all 10 parameters in detail, including mutual exclusivity of payload_file and nested paywall semantics. The description contributes no additional parameter meaning, making the baseline 3 appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a verb (Update) and resource (invitation link), but adds essentially nothing beyond the tool title of the same wording. It never says what aspects of the link are updatable (name, paywall, tags, access groups, redirect) even though those are the core fields, and it does not distinguish itself from close siblings like revoke_invitation_link or delete_invitation_link.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is procedural: confirm=true is needed for the user-requested action. There is no statement of when to update versus revoke, delete, or create an invitation, nor any prerequisite or context condition for choosing this tool.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_memberUpdate a community memberB

Destructive

Update a community member. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`avatar`	No	signed_id of the avatar returned from the direct upload endpoint
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`headline`	No
`member_id`	Yes	ID of the community member
`space_ids`	No
`is_flagged`	No
`preferences`	No
`member_since`	No	Effective "member since" / joined date. Cannot be in the future.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`member_tag_ids`	No
`space_group_ids`	No
`community_member_profile_fields`	No	Profile fields key value pairs

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and readOnlyHint=false, so the mutation profile is covered. The description adds one genuinely new behavioral fact - the confirm=true guardrail - but "changes community state" is largely redundant with the destructive annotation and nothing is said about auth, reversibility, or side effects on related resources.

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?

Two short sentences, front-loaded with the verb+resource and the confirm requirement. Efficient, though "Changes community state" carries little weight beyond what the destructive annotation already tells the agent.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 15 parameters, nested payload, and no output schema, this description is far too thin. It omits which fields are updatable, the payload/payload_file/flag exclusivity rules, and any confirmation semantics beyond a single phrase.

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?

With 15 parameters, nested objects, and only 53% schema description coverage, the schema leaves many fields undocumented. The description adds no parameter meaning at all beyond echoing confirm, and says nothing about the mutually exclusive payload / payload_file / body-flag patterns the schema hints at.

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 clear verb (update) and resource (community member), matching the title. However, it does nothing to distinguish this from close siblings like update_community, create_member, remove_member, or ban_community_member, so the agent must infer scope from the name alone.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The sentence "requires confirm=true for the user-requested action" gives one useful precondition for invocation. Beyond that there is no guidance on when to use this versus alternatives, nor which fields are appropriate to update versus the create/delete sibling tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_member_tagUpdate member tagC

Destructive

Update member tag. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`color`	No
`emoji`	No
`tag_id`	Yes	Member tag ID
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`is_public`	No
`custom_emoji`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`display_format`	No
`display_locations`	No
`is_background_enabled`	No

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds one genuinely useful behavior beyond annotations—the confirm=true requirement—but says nothing about side effects on existing tag membership or the community-state change it alludes to.

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?

Two short, front-loaded sentences with no filler. It is efficient, though the brevity comes at the cost of substance rather than being tightly information-dense.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive mutation with 13 parameters, nested objects, and no output schema, the description is far too thin. It omits which tag attributes can be changed, the effect on tagged members, and how the payload/payload_file alternatives relate to body flags.

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 only 38% across 13 parameters, and the description only touches confirm=true. The many bare parameters (name, color, emoji, is_public, custom_emoji, display_format, display_locations, is_background_enabled) plus the nested payload object are left undocumented in both places, so the description fails to compensate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update member tag. Changes community state" essentially restates the tool name/title with a generic add-on. It provides no specifics about what a member tag is, what fields are mutable, or how this differs from sibling tools like create_member_tag, delete_member_tag, or get_member_tag.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is "requires confirm=true for the user-requested action," which is an invocation gate rather than a when-to-use signal. There is no indication of when to prefer this over tag_member/untag_member or the other member-tag siblings.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_paywall_affiliateUpdate Paywall AffiliateC

Destructive

Update Paywall Affiliate. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`status`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`affiliate_id`	Yes	Affiliate ID
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

C2.7/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, so the safety profile is covered. The description adds that the operation 'changes community state' and is confirmation-gated, which is modest added context, but it omits what specifically is destroyed/changed and whether the change is reversible.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

It is very short and front-loaded, but the opening sentence is pure tautology that earns no place, and the substantive content ('changes community state', confirm requirement) is compressed to the point of being underspecified rather than concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 6-parameter destructive mutation with a nested payload object and no output schema, the description leaves major gaps: which affiliate fields can be changed, what the status values mean, and what happens on success. The confirmation hint and vague 'community state' note are not enough to invoke this tool confidently.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents most parameters including confirm, payload and payload_file. The description adds no format or meaning beyond the schema, which is the expected baseline when structured fields carry the load.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence simply restates the tool name and title verbatim, adding no distinguishing information. The second sentence mentions 'changes community state' but never says what is actually updated on the affiliate (e.g. status), so an agent cannot tell this apart from the many other update_* siblings.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It does communicate one gating condition: the action requires confirm=true and is intended for a user-requested action. However, there is no indication of when to use this tool versus alternatives such as invite_paywall_affiliates or the payout tools, and no prerequisites or exclusion conditions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_paywall_groupUpdate Subscription GroupB

Destructive

Update Subscription Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`currency_id`	No	ID of the currency the group's paywalls are priced in
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`paywall_group_id`	Yes	Subscription group ID

TDQS

B3.2/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the safety profile is largely covered. The description adds two useful pieces of context beyond the annotations: that the operation 'changes community state' and that it requires confirm=true. It still omits consequences of the change (reversibility, effect on existing paywalls/pricing).

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?

Two short sentences with zero padding and the constraint front-loaded. The first sentence largely restates the title verbatim, which is slightly redundant, but nothing is wasted.

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 7-parameter, nested-object mutation tool, the description is thin: it does not mention which fields can be changed, that payload/payload_file and body flags are mutually exclusive, or what the update returns. The annotations and rich schema carry most of the burden, leaving the description just adequate.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 86%, so the schema already documents nearly every parameter (account, currency_id, payload, payload_file, paywall_group_id). The description reinforces the confirm requirement but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.

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 names a specific verb and resource ('Update Subscription Group'), making the operation clear. However, it does not distinguish this tool from the many siblings in the paywall family (create_paywall_group, delete_paywall, archive_paywall, publish_paywall) or state which fields are updatable.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage guidance is that confirm=true is required 'for the user-requested action', which constrains one parameter but never states when to use this tool versus create_paywall_group or the archive/delete variants. No prerequisites, exclusions, or alternatives are given.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_postUpdate Basic PostC

Destructive

Update Basic Post. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`topics`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`post_id`	Yes
`is_pinned`	No
`meta_title`	No
`cover_image`	No	signed_id of the cover image
`tiptap_body`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`published_at`	No
`hide_meta_info`	No
`opengraph_title`	No
`meta_description`	No
`is_liking_enabled`	No
`is_comments_closed`	No
`skip_notifications`	No
`is_comments_enabled`	No
`internal_custom_html`	No
`opengraph_description`	No
`is_truncation_disabled`	No
`hide_from_featured_areas`	No

TDQS

C2.9/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already mark this as a destructive, non-idempotent, open-world write operation. The description adds that it changes community state and requires confirm=true, which is useful mutation context, but it does not detail permissions, reversibility, or side effects.

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 two sentences, front-loaded, and free of filler. The first sentence restates the title, while the second adds mutation and confirm requirements, so it is efficient though sparse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a 23-parameter destructive update with no output schema and very low schema coverage, the description barely scratches the surface. It gives the confirm requirement but omits payload-vs-body-flag behavior, tiptap_body handling, and field-specific update semantics.

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 22%, so the description needs to compensate, but it only mentions confirm=true and says nothing about post_id, payload, payload_file, tiptap_body, or the other 18 parameters. The confirm note largely duplicates existing schema guidance, leaving most parameters undocumented.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose3/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description identifies a verb and resource ('Update Basic Post'), but 'Basic Post' is not defined and the description does not distinguish this tool from create_post, delete_post, get_post, or explain what fields are updateable. It is minimally clear but vague.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only usage signal is the confirm=true prerequisite tied to user-requested actions. It does not name alternatives or explain when to use this versus get_post, create_post, or delete_post.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_profile_fieldUpdate Profile FieldC

Destructive

Update Profile Field. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`profile_field`	No
`profile_field_id`	Yes	Profile field ID

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true, so the mutation profile is covered. The description adds that the operation 'changes community state' and requires confirm=true, which reinforces the destructive nature but adds little beyond the annotations and the schema's confirm description. It omits what is actually overwritten (e.g. that choice deletions via _destroy erase member selections).

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences with the constraint front-loaded, so there is no padding. However, the brevity comes at the cost of under-specification rather than through efficient information density, so it is merely adequate.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

This is a destructive, non-idempotent mutation with six parameters, deeply nested objects, and no output schema; the description should explain whether updates are partial or replace the whole field, what confirm guards, and what side effects reach members. None of that is present, leaving significant gaps for a complex tool.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 83%, so the schema already documents nearly every parameter, including nested profile_field attributes. The description adds no parameter-level meaning (no partial-vs-full update semantics, no interaction between payload, payload_file, and body flags). Baseline 3 is appropriate when the schema does the heavy lifting.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The title sentence 'Update Profile Field' is a tautological restatement of the tool name; no verb+resource detail about what a profile field update actually changes. The second sentence describes a constraint ('Changes community state') rather than purpose, and does not distinguish it from siblings like create_profile_field, delete_profile_field, or archive_profile_field.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No guidance on when to update vs archive/create/delete a profile field, nor on prerequisites such as permissions or which community the field belongs to. The only usage-ish content is the confirm flag requirement, which is a mechanical prerequisite rather than routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_spaceUpdate SpaceC

Destructive

Update Space. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`emoji`	No	Simple emoji string for the space
`topics`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`is_draft`	No	Only valid for course spaces; set to false to publish a course
`space_id`	Yes	Space ID
`is_hidden`	No
`is_private`	No
`cover_image`	No	signed_id of the cover image
`default_tab`	No	Default tab to show when entering the space
`custom_emoji`	No
`default_sort`	No
`display_view`	No	Default display view for the space
`hide_sorting`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`show_tab_bar`	No	Show the tab bar navigation
`visible_tabs`	No
`space_group_id`	No
`show_next_event`	No	Show next event information for event spaces
`thumbnail_image`	No	signed_id of the thumbnail image for event spaces
`is_post_disabled`	No
`hide_from_sidebar`	No	Hide space from sidebar navigation
`locked_button_url`	No
`hide_members_count`	No	Hide the member count display
`hide_post_settings`	No	Hide post settings
`hide_right_sidebar`	No	Hide right sidebar in space
`pinned_posts_label`	No	Custom label for pinned posts
`cover_image_visible`	No
`default_member_sort`	No	Default sort order for members
`locked_button_label`	No
`locked_page_heading`	No
`meta_tag_attributes`	No
`default_comment_sort`	No	Default sort order for comments
`chat_room_description`	No	Description for the chat room in chat spaces
`chat_room_show_history`	No	Show chat history to new members in chat spaces
`event_auto_rsvp_enabled`	No	Only for event spaces
`locked_page_description`	No
`require_topic_selection`	No	Require topic selection when posting
`hide_from_featured_areas`	No	Hide space from featured areas
`course_setting_attributes`	No
`cover_image_display_style`	No
`disable_member_post_covers`	No	Disable cover images on member posts
`is_hidden_from_non_members`	No
`default_notification_setting`	No	Members will receive an email notification when new events are posted
`show_lock_icon_for_non_members`	No	Show lock icon for non-members
`prevent_members_from_adding_others`	No	Prevent members from adding other members to the space
`default_in_app_notification_setting`	No	Members will see an in-app notification when new events are posted
`default_mobile_notification_setting`	No	Members will see a mobile notification when new events are posted
`default_mention_in_app_notification_setting`	No	Members will see an in-app notification when mentioned
`default_mention_mobile_notification_setting`	No	Members will see a mobile notification when mentioned

TDQS

C2.3/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, and idempotentHint=false, so the safety profile is partly known. The description adds one genuinely new behavioral fact - that the call is gated behind confirm=true - which is useful context beyond the annotations. It does not, however, disclose what state is destroyed or what happens on partial updates.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Two short sentences that are front-loaded and free of filler, which is structurally sound. However, at this brevity for a 52-parameter destructive tool, the terseness reads as under-specification rather than disciplined concision.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with 52 parameters, nested objects, no output schema, and only 63% description coverage, the description is far too thin. It surfaces the confirm requirement but omits which space fields are mutable, side effects, and prerequisite permission context.

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?

With 52 parameters and only 63% schema description coverage, roughly a third of the parameters are undocumented in both schema and description, and the description should compensate but does not. The single parameter it references (confirm) is already fully described in the schema, so it adds no meaning.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

The first sentence is a verbatim restatement of the tool name/title ('Update Space'), which is the definition of tautology. 'Changes community state' is vague - it does not say which aspects of the space are updated and does nothing to distinguish this from siblings such as update_community or update_space_group.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is the confirm=true gating, which the schema already states ('Set true only when the user asked for exactly this action'). There is no when-to-use vs. when-not-to-use framing and no routing to alternative update_* tools despite the dense sibling set.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_space_groupUpdate Space GroupC

Destructive

Update Space Group. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`slug`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.
`space_group_id`	Yes	Space Group ID
`hide_members_count`	No
`is_hidden_from_non_members`	No
`allow_members_to_create_spaces`	No
`moderator_community_member_ids`	No	Array of community member ids to add as moderators
`hide_non_member_spaces_from_sidebar`	No
`automatically_add_members_to_new_spaces`	No
`add_members_to_space_group_on_space_join`	No

TDQS

C2.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, readOnlyHint=false, idempotentHint=false, so the mutation/safety profile is covered. The description adds that it changes community state and mandates confirm=true, which is mildly useful context, but it does not say what is destroyed, what permissions are needed, or how partial updates behave.

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?

Two short sentences, front-loaded, with no filler or repetition. It is efficient, though the terseness borders on under-specification rather than being genuinely concise.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive 14-parameter tool with a nested payload object and no output schema, the description omits body-format selection, credential/account selection, and the scope of the state change. An agent would have to reverse-engineer most of the call contract from the schema.

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 only 43% across 14 parameters, so the description is expected to compensate, yet it mentions only confirm. The mutual exclusivity of payload vs body flags vs payload_file, the account credential selector, and the moderator id array are left entirely to sparse schema text.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose2/5

Does the description clearly state what the tool does and how it differs from similar tools?

"Update Space Group" is a near-verbatim restatement of the tool name/title, so the first sentence carries no added information. "Changes community state" gestures at the resource but is vague and does not distinguish this tool from siblings like update_space, update_community, or update_paywall_group.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The only guidance is the confirm=true requirement, which is a precondition rather than a when-to-use statement. There is no indication of when an agent should call update_space_group versus update_space or update_community, and no exclusions or alternatives are named.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_tax_settingsUpdate tax settingsB

Destructive

Update tax settings. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`tax_setting`	No
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.4/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, idempotentHint=false and readOnlyHint=false, so the danger profile is covered. The description adds the useful guardrail that confirm=true is mandatory, but does not say what settings are mutated or whether the change is reversible.

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?

Two short sentences, front-loaded with the action and immediately followed by the operational constraint. No filler, though it partially restates the title.

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 destructive, non-idempotent mutation with three overlapping body-input mechanisms (payload, tax_setting, payload_file) and no output schema, the description is thin. It never explains which input form to prefer or that payload_file cannot be mixed with the others, leaving an agent to infer that from the schema alone.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80%, so the schema already documents account, confirm, payload and payload_file. The description reinforces confirm=true but adds no detail on the tax_setting fields or on the mutual exclusivity between payload, tax_setting and payload_file, which is the genuinely confusing part of this 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?

States a specific verb+resource ("Update tax settings") and adds the scope of the change (community state). It does not name or contrast with any sibling such as get_tax_settings, so the agent gets a clear purpose but no routing help.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It provides one conditional: confirm=true is required for the user-requested action, which implies this is a user-initiated write. There is no when-not guidance and no mention of the read counterpart get_tax_settings, so usage is only implied.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

update_topicUpdate a topicB

Destructive

Update a topic. Changes community state and requires confirm=true for the user-requested action.

ParametersJSON Schema

Name	Required	Description
`name`	No
`account`	No	Named private Circle account; selects credentials, not a remote community ID.
`confirm`	No	Set true only when the user asked for exactly this action.
`payload`	No	Complete JSON request body instead of body flags. Supports nested Tiptap, maps and nullable values.
`topic_id`	Yes	Topic ID
`space_ids`	No	Array of space IDs to be assigned to the topic
`admin_only`	No	Toggles if only admins and moderators can select this topic
`payload_file`	No	Regular local JSON body file, at most 5 MB. Cannot be mixed with body flags or payload.

TDQS

B3.1/5.0

Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare destructiveHint=true, openWorldHint=true, idempotentHint=false, so the safety profile is covered. The description adds a genuinely useful behavioral requirement (confirm=true for user-requested actions) and confirms state mutation, but says nothing about what specifically changes, permissions, or reversibility.

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?

Two short sentences, front-loaded with the action and its constraint, with no filler. It is efficient, though arguably terse for a tool with 8 parameters and nested objects.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a destructive, non-idempotent mutation with nested objects and three mutually exclusive body-input options (body flags, payload, payload_file), the description is too thin. It omits the payload-vs-flags-vs-file choice and any statement of effect, leaving an agent under-informed despite the rich schema.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 88%, so the schema already documents nearly all 8 parameters, including the confirm and payload fields. The description's only param-relevant content echoes the confirm semantics already present in the schema, adding little new meaning; baseline 3 applies.

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 ('Update a topic'), which is clear enough to distinguish it from create_topic, delete_topic, and get_topic by name. However, it adds no field-level or scope detail beyond restating the title, and 'Changes community state' is vague rather than differentiating.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines2/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

There is no guidance on when to use this tool versus siblings like update_space or update_community, and no prerequisites or exclusions are stated. The one conditional ('requires confirm=true for the user-requested action') is really a parameter instruction, not alternative-routing guidance.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

104 tool updatesv3.0.1Oct 7, 2026

Changedactivate_workflow1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedadd_space_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedadd_to_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedarchive_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedarchive_paywall1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedarchive_profile_field1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedban_community_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcancel_community_member_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_comment1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_community_segment10 fields changed

addedInput schema / $defs

Added value: +{
+  "rules": {
+    "properties": {
+      "rule_type": {
+        "enum": [
+          "all_contacts",
+          "all_members",
+          "custom_filters",
+          "selected_members"
+        ],
+        "type": "string"
+      },
+      "rules": {
+        "anyOf": [
+          {
+            "items": {
+              "properties": {
+                "filter_type": {
+                  "enum": [
+                    "is",
+                    "is_not",
+                    "contains",
+                    "does_not_contain",
+                    "gt",
+                    "lt",
+                    "eq"
+                  ],
+                  "type": "string"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "key": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": [
+                    "string",
+                    "boolean"
+                  ]
+                }
+              },
+              "required": [
+                "key",
+                "value"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          {
+            "items": {
+              "properties": {
+                "community_member_id": {
+                  "type": "integer"
+                },
+                "email": {
+                  "format": "email",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "email",
+                "community_member_id"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        ]
+      }
+    },
+    "required": [
+      "rule_type",
+      "rules"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / rules / $ref
```
Added value: +"#/$defs/rules"
```

removedInput schema / properties / payload / properties / rules / properties

Removed value: -{
-  "rule_type": {
-    "enum": [
-      "all_contacts",
-      "all_members",
-      "custom_filters",
-      "selected_members"
-    ],
-    "type": "string"
-  },
-  "rules": {
-    "anyOf": [
-      {
-        "items": {
-          "properties": {
-            "filter_type": {
-              "enum": [
-                "is",
-                "is_not",
-                "contains",
-                "does_not_contain",
-                "gt",
-                "lt",
-                "eq"
-              ],
-              "type": "string"
-            },
-            "id": {
-              "type": "string"
-            },
-            "key": {
-              "type": "string"
-            },
-            "value": {
-              "type": [
-                "string",
-                "boolean"
-              ]
-            }
-          },
-          "required": [
-            "key",
-            "value"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      {
-        "items": {
-          "properties": {
-            "community_member_id": {
-              "type": "integer"
-            },
-            "email": {
-              "format": "email",
-              "type": "string"
-            }
-          },
-          "required": [
-            "email",
-            "community_member_id"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  }
-}

removedInput schema / properties / payload / properties / rules / required
```
Removed value: -[
-  "rule_type",
-  "rules"
-]
```
removedInput schema / properties / payload / properties / rules / type
```
Removed value: -"object"
```
addedInput schema / properties / rules / $ref
```
Added value: +"#/$defs/rules"
```

removedInput schema / properties / rules / properties

Removed value: -{
-  "rule_type": {
-    "enum": [
-      "all_contacts",
-      "all_members",
-      "custom_filters",
-      "selected_members"
-    ],
-    "type": "string"
-  },
-  "rules": {
-    "anyOf": [
-      {
-        "items": {
-          "properties": {
-            "filter_type": {
-              "enum": [
-                "is",
-                "is_not",
-                "contains",
-                "does_not_contain",
-                "gt",
-                "lt",
-                "eq"
-              ],
-              "type": "string"
-            },
-            "id": {
-              "type": "string"
-            },
-            "key": {
-              "type": "string"
-            },
-            "value": {
-              "type": [
-                "string",
-                "boolean"
-              ]
-            }
-          },
-          "required": [
-            "key",
-            "value"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      {
-        "items": {
-          "properties": {
-            "community_member_id": {
-              "type": "integer"
-            },
-            "email": {
-              "format": "email",
-              "type": "string"
-            }
-          },
-          "required": [
-            "email",
-            "community_member_id"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  }
-}

removedInput schema / properties / rules / required
```
Removed value: -[
-  "rule_type",
-  "rules"
-]
```
removedInput schema / properties / rules / type
```
Removed value: -"object"
```

Changedcreate_contact_note1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_course_lesson8 fields changed

addedInput schema / $defs

Added value: +{
+  "rich_text_body": {
+    "properties": {
+      "body": {
+        "properties": {
+          "content": {
+            "items": {
+              "properties": {
+                "attrs": {
+                  "type": "object"
+                },
+                "marks": {
+                  "items": {
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "text": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "type": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "content"
+        ],
+        "type": "object"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / payload / properties / rich_text_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / rich_text_body / type
```
Removed value: -"object"
```
addedInput schema / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / rich_text_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / rich_text_body / type
```
Removed value: -"object"
```

Changedcreate_course_section1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_direct_upload10 fields changed

addedInput schema / $defs

Added value: +{
+  "blob": {
+    "properties": {
+      "byte_size": {
+        "type": "integer"
+      },
+      "checksum": {
+        "type": "string"
+      },
+      "content_type": {
+        "type": "string"
+      },
+      "filename": {
+        "type": "string"
+      },
+      "key": {
+        "type": "string"
+      }
+    },
+    "required": [
+      "key",
+      "filename",
+      "content_type",
+      "byte_size",
+      "checksum"
+    ],
+    "type": "object"
+  }
+}

addedInput schema / properties / blob / $ref
```
Added value: +"#/$defs/blob"
```

removedInput schema / properties / blob / properties

Removed value: -{
-  "byte_size": {
-    "type": "integer"
-  },
-  "checksum": {
-    "type": "string"
-  },
-  "content_type": {
-    "type": "string"
-  },
-  "filename": {
-    "type": "string"
-  },
-  "key": {
-    "type": "string"
-  }
-}

removedInput schema / properties / blob / required

Removed value: -[
-  "key",
-  "filename",
-  "content_type",
-  "byte_size",
-  "checksum"
-]

removedInput schema / properties / blob / type
```
Removed value: -"object"
```

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / blob / $ref
```
Added value: +"#/$defs/blob"
```

removedInput schema / properties / payload / properties / blob / properties

Removed value: -{
-  "byte_size": {
-    "type": "integer"
-  },
-  "checksum": {
-    "type": "string"
-  },
-  "content_type": {
-    "type": "string"
-  },
-  "filename": {
-    "type": "string"
-  },
-  "key": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / blob / required

Removed value: -[
-  "key",
-  "filename",
-  "content_type",
-  "byte_size",
-  "checksum"
-]

removedInput schema / properties / payload / properties / blob / type
```
Removed value: -"object"
```

Changedcreate_embed1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_event10 fields changed

addedInput schema / $defs

Added value: +{
+  "event": {
+    "properties": {
+      "attendee_invite_attributes": {
+        "properties": {
+          "invited_cohost_ids": {
+            "items": {
+              "type": "integer"
+            },
+            "type": "array"
+          },
+          "invited_entities_ids": {
+            "properties": {
+              "member_tags_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "members_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "space_groups_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "spaces_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "body": {
+        "type": "string"
+      },
+      "cover_image": {
+        "description": "signed_id of the cover image",
+        "type": "string"
+      },
+      "event_setting_attributes": {
+        "properties": {
+          "confirmation_message_button_link": {
+            "type": "string"
+          },
+          "confirmation_message_button_title": {
+            "type": "string"
+          },
+          "confirmation_message_description": {
+            "type": "string"
+          },
+          "confirmation_message_title": {
+            "type": "string"
+          },
+          "duration_in_seconds": {
+            "type": "integer"
+          },
+          "enable_custom_thank_you_message": {
+            "type": "boolean"
+          },
+          "hide_attendees": {
+            "type": "boolean"
+          },
+          "hide_location_from_non_attendees": {
+            "type": "boolean"
+          },
+          "host": {
+            "type": "string"
+          },
+          "in_person_location": {
+            "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
+            "type": "string"
+          },
+          "live_stream_room_setting_attributes": {
+            "properties": {
+              "access_type": {
+                "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
+                "enum": [
+                  "open",
+                  "secret",
+                  "public_stream"
+                ],
+                "type": "string"
+              },
+              "auto_post_recording_enabled": {
+                "type": "boolean"
+              },
+              "hide_participants_list": {
+                "type": "boolean"
+              },
+              "limit_url_sharing": {
+                "type": "boolean"
+              },
+              "mute_on_join": {
+                "type": "boolean"
+              },
+              "recording_enabled": {
+                "type": "boolean"
+              },
+              "view_type": {
+                "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
+                "enum": [
+                  "speaker_view",
+                  "speaker_variant_view",
+                  "grid_view"
+                ],
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "location_type": {
+            "enum": [
+              "virtual",
+              "in_person",
+              "tbd",
+              "live_stream",
+              "live_room"
+            ],
+            "type": "string"
+          },
+          "rsvp_disabled": {
+            "type": "boolean"
+          },
+          "rsvp_limit": {
+            "type": "integer"
+          },
+          "rsvp_limit_enabled": {
+            "type": "boolean"
+          },
+          "send_email_confirmation": {
+            "type": "boolean"
+          },
+          "send_email_reminder": {
+            "type": "boolean"
+          },
+          "send_in_app_notification_confirmation": {
+            "type": "boolean"
+          },
+          "send_in_app_notification_reminder": {
+            "type": "boolean"
+          },
+          "send_publish_email": {
+            "type": "boolean"
+          },
+          "starts_at": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "ticket_type": {
+            "enum": [
+              "paid",
+              "free"
+            ],
+            "type": "string"
+          },
+          "virtual_location_url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "event_type": {
+        "enum": [
+          "single",
+          "recurring"
+        ],
+        "type": "string"
+      },
+      "hide_from_featured_areas": {
+        "type": "boolean"
+      },
+      "meta_tag_attributes": {
+        "properties": {
+          "meta_description": {
+            "type": "string"
+          },
+          "meta_title": {
+            "type": "string"
+          },
+          "opengraph_description": {
+            "type": "string"
+          },
+          "opengraph_image": {
+            "type": "string"
+          },
+          "opengraph_title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "name": {
+        "type": "string"
+      },
+      "paywall_attributes": {
+        "properties": {
+          "currency_id": {
+            "type": "integer"
+          },
+          "description": {
+            "type": "string"
+          },
+          "price_amount": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "recurring_setting_attributes": {
+        "properties": {
+          "edit_mode": {
+            "enum": [
+              "current",
+              "remaining",
+              "all"
+            ],
+            "type": "string"
+          },
+          "ends_at": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "frequency": {
+            "enum": [
+              "daily",
+              "weekday",
+              "weekly",
+              "bi_weekly",
+              "monthly",
+              "monthly_weekday_based",
+              "annually",
+              "yearly"
+            ],
+            "type": "string"
+          },
+          "occurrences": {
+            "type": "integer"
+          }
+        },
+        "type": "object"
+      },
+      "slug": {
+        "type": "string"
+      },
+      "space_id": {
+        "type": "integer"
+      },
+      "status": {
+        "enum": [
+          "draft",
+          "published"
+        ],
+        "type": "string"
+      },
+      "thumbnail_image": {
+        "description": "signed_id of the thumbnail image",
+        "type": "string"
+      },
+      "topics": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "user_id": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "space_id",
+      "status"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / event / $ref
```
Added value: +"#/$defs/event"
```

removedInput schema / properties / event / properties

Removed value: -{
-  "attendee_invite_attributes": {
-    "properties": {
-      "invited_cohost_ids": {
-        "items": {
-          "type": "integer"
-        },
-        "type": "array"
-      },
-      "invited_entities_ids": {
-        "properties": {
-          "member_tags_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "members_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "space_groups_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "spaces_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "body": {
-    "type": "string"
-  },
-  "cover_image": {
-    "description": "signed_id of the cover image",
-    "type": "string"
-  },
-  "event_setting_attributes": {
-    "properties": {
-      "confirmation_message_button_link": {
-        "type": "string"
-      },
-      "confirmation_message_button_title": {
-        "type": "string"
-      },
-      "confirmation_message_description": {
-        "type": "string"
-      },
-      "confirmation_message_title": {
-        "type": "string"
-      },
-      "duration_in_seconds": {
-        "type": "integer"
-      },
-      "enable_custom_thank_you_message": {
-        "type": "boolean"
-      },
-      "hide_attendees": {
-        "type": "boolean"
-      },
-      "hide_location_from_non_attendees": {
-        "type": "boolean"
-      },
-      "host": {
-        "type": "string"
-      },
-      "in_person_location": {
-        "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
-        "type": "string"
-      },
-      "live_stream_room_setting_attributes": {
-        "properties": {
-          "access_type": {
-            "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
-            "enum": [
-              "open",
-              "secret",
-              "public_stream"
-            ],
-            "type": "string"
-          },
-          "auto_post_recording_enabled": {
-            "type": "boolean"
-          },
-          "hide_participants_list": {
-            "type": "boolean"
-          },
-          "limit_url_sharing": {
-            "type": "boolean"
-          },
-          "mute_on_join": {
-            "type": "boolean"
-          },
-          "recording_enabled": {
-            "type": "boolean"
-          },
-          "view_type": {
-            "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
-            "enum": [
-              "speaker_view",
-              "speaker_variant_view",
-              "grid_view"
-            ],
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "location_type": {
-        "enum": [
-          "virtual",
-          "in_person",
-          "tbd",
-          "live_stream",
-          "live_room"
-        ],
-        "type": "string"
-      },
-      "rsvp_disabled": {
-        "type": "boolean"
-      },
-      "rsvp_limit": {
-        "type": "integer"
-      },
-      "rsvp_limit_enabled": {
-        "type": "boolean"
-      },
-      "send_email_confirmation": {
-        "type": "boolean"
-      },
-      "send_email_reminder": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_confirmation": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_reminder": {
-        "type": "boolean"
-      },
-      "send_publish_email": {
-        "type": "boolean"
-      },
-      "starts_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "ticket_type": {
-        "enum": [
-          "paid",
-          "free"
-        ],
-        "type": "string"
-      },
-      "virtual_location_url": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "event_type": {
-    "enum": [
-      "single",
-      "recurring"
-    ],
-    "type": "string"
-  },
-  "hide_from_featured_areas": {
-    "type": "boolean"
-  },
-  "meta_tag_attributes": {
-    "properties": {
-      "meta_description": {
-        "type": "string"
-      },
-      "meta_title": {
-        "type": "string"
-      },
-      "opengraph_description": {
-        "type": "string"
-      },
-      "opengraph_image": {
-        "type": "string"
-      },
-      "opengraph_title": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "name": {
-    "type": "string"
-  },
-  "paywall_attributes": {
-    "properties": {
-      "currency_id": {
-        "type": "integer"
-      },
-      "description": {
-        "type": "string"
-      },
-      "price_amount": {
-        "type": "number"
-      }
-    },
-    "type": "object"
-  },
-  "recurring_setting_attributes": {
-    "properties": {
-      "edit_mode": {
-        "enum": [
-          "current",
-          "remaining",
-          "all"
-        ],
-        "type": "string"
-      },
-      "ends_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "frequency": {
-        "enum": [
-          "daily",
-          "weekday",
-          "weekly",
-          "bi_weekly",
-          "monthly",
-          "monthly_weekday_based",
-          "annually",
-          "yearly"
-        ],
-        "type": "string"
-      },
-      "occurrences": {
-        "type": "integer"
-      }
-    },
-    "type": "object"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "space_id": {
-    "type": "integer"
-  },
-  "status": {
-    "enum": [
-      "draft",
-      "published"
-    ],
-    "type": "string"
-  },
-  "thumbnail_image": {
-    "description": "signed_id of the thumbnail image",
-    "type": "string"
-  },
-  "topics": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "user_id": {
-    "type": "integer"
-  }
-}

removedInput schema / properties / event / required

Removed value: -[
-  "name",
-  "space_id",
-  "status"
-]

removedInput schema / properties / event / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / event / $ref
```
Added value: +"#/$defs/event"
```

removedInput schema / properties / payload / properties / event / properties

Removed value: -{
-  "attendee_invite_attributes": {
-    "properties": {
-      "invited_cohost_ids": {
-        "items": {
-          "type": "integer"
-        },
-        "type": "array"
-      },
-      "invited_entities_ids": {
-        "properties": {
-          "member_tags_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "members_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "space_groups_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "spaces_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "body": {
-    "type": "string"
-  },
-  "cover_image": {
-    "description": "signed_id of the cover image",
-    "type": "string"
-  },
-  "event_setting_attributes": {
-    "properties": {
-      "confirmation_message_button_link": {
-        "type": "string"
-      },
-      "confirmation_message_button_title": {
-        "type": "string"
-      },
-      "confirmation_message_description": {
-        "type": "string"
-      },
-      "confirmation_message_title": {
-        "type": "string"
-      },
-      "duration_in_seconds": {
-        "type": "integer"
-      },
-      "enable_custom_thank_you_message": {
-        "type": "boolean"
-      },
-      "hide_attendees": {
-        "type": "boolean"
-      },
-      "hide_location_from_non_attendees": {
-        "type": "boolean"
-      },
-      "host": {
-        "type": "string"
-      },
-      "in_person_location": {
-        "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
-        "type": "string"
-      },
-      "live_stream_room_setting_attributes": {
-        "properties": {
-          "access_type": {
-            "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
-            "enum": [
-              "open",
-              "secret",
-              "public_stream"
-            ],
-            "type": "string"
-          },
-          "auto_post_recording_enabled": {
-            "type": "boolean"
-          },
-          "hide_participants_list": {
-            "type": "boolean"
-          },
-          "limit_url_sharing": {
-            "type": "boolean"
-          },
-          "mute_on_join": {
-            "type": "boolean"
-          },
-          "recording_enabled": {
-            "type": "boolean"
-          },
-          "view_type": {
-            "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
-            "enum": [
-              "speaker_view",
-              "speaker_variant_view",
-              "grid_view"
-            ],
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "location_type": {
-        "enum": [
-          "virtual",
-          "in_person",
-          "tbd",
-          "live_stream",
-          "live_room"
-        ],
-        "type": "string"
-      },
-      "rsvp_disabled": {
-        "type": "boolean"
-      },
-      "rsvp_limit": {
-        "type": "integer"
-      },
-      "rsvp_limit_enabled": {
-        "type": "boolean"
-      },
-      "send_email_confirmation": {
-        "type": "boolean"
-      },
-      "send_email_reminder": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_confirmation": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_reminder": {
-        "type": "boolean"
-      },
-      "send_publish_email": {
-        "type": "boolean"
-      },
-      "starts_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "ticket_type": {
-        "enum": [
-          "paid",
-          "free"
-        ],
-        "type": "string"
-      },
-      "virtual_location_url": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "event_type": {
-    "enum": [
-      "single",
-      "recurring"
-    ],
-    "type": "string"
-  },
-  "hide_from_featured_areas": {
-    "type": "boolean"
-  },
-  "meta_tag_attributes": {
-    "properties": {
-      "meta_description": {
-        "type": "string"
-      },
-      "meta_title": {
-        "type": "string"
-      },
-      "opengraph_description": {
-        "type": "string"
-      },
-      "opengraph_image": {
-        "type": "string"
-      },
-      "opengraph_title": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "name": {
-    "type": "string"
-  },
-  "paywall_attributes": {
-    "properties": {
-      "currency_id": {
-        "type": "integer"
-      },
-      "description": {
-        "type": "string"
-      },
-      "price_amount": {
-        "type": "number"
-      }
-    },
-    "type": "object"
-  },
-  "recurring_setting_attributes": {
-    "properties": {
-      "edit_mode": {
-        "enum": [
-          "current",
-          "remaining",
-          "all"
-        ],
-        "type": "string"
-      },
-      "ends_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "frequency": {
-        "enum": [
-          "daily",
-          "weekday",
-          "weekly",
-          "bi_weekly",
-          "monthly",
-          "monthly_weekday_based",
-          "annually",
-          "yearly"
-        ],
-        "type": "string"
-      },
-      "occurrences": {
-        "type": "integer"
-      }
-    },
-    "type": "object"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "space_id": {
-    "type": "integer"
-  },
-  "status": {
-    "enum": [
-      "draft",
-      "published"
-    ],
-    "type": "string"
-  },
-  "thumbnail_image": {
-    "description": "signed_id of the thumbnail image",
-    "type": "string"
-  },
-  "topics": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "user_id": {
-    "type": "integer"
-  }
-}

removedInput schema / properties / payload / properties / event / required
```
Removed value: -[
-  "name",
-  "space_id",
-  "status"
-]
```
removedInput schema / properties / payload / properties / event / type
```
Removed value: -"object"
```

Changedcreate_event_attendee1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_filter_control10 fields changed

addedInput schema / $defs

Added value: +{
+  "key": {
+    "description": "Filter to control; profile_field requires profile_field_id",
+    "enum": [
+      "contact_search",
+      "near_me",
+      "online",
+      "recently_joined",
+      "location",
+      "tags",
+      "profile_field",
+      "spaces",
+      "space_groups",
+      "global"
+    ],
+    "type": "string"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / key / $ref
```
Added value: +"#/$defs/key"
```

removedInput schema / properties / key / description

Removed value: -"Filter to control; profile_field requires profile_field_id"

removedInput schema / properties / key / enum

Removed value: -[
-  "contact_search",
-  "near_me",
-  "online",
-  "recently_joined",
-  "location",
-  "tags",
-  "profile_field",
-  "spaces",
-  "space_groups",
-  "global"
-]

removedInput schema / properties / key / type
```
Removed value: -"string"
```
addedInput schema / properties / payload / properties / key / $ref
```
Added value: +"#/$defs/key"
```

removedInput schema / properties / payload / properties / key / description

Removed value: -"Filter to control; profile_field requires profile_field_id"

removedInput schema / properties / payload / properties / key / enum

Removed value: -[
-  "contact_search",
-  "near_me",
-  "online",
-  "recently_joined",
-  "location",
-  "tags",
-  "profile_field",
-  "spaces",
-  "space_groups",
-  "global"
-]

removedInput schema / properties / payload / properties / key / type
```
Removed value: -"string"
```

Changedcreate_form_submission1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_image_post8 fields changed

addedInput schema / $defs

Added value: +{
+  "gallery_attributes": {
+    "properties": {
+      "downloadable_images": {
+        "type": "boolean"
+      },
+      "images_attributes": {
+        "items": {
+          "properties": {
+            "height": {
+              "type": "integer"
+            },
+            "id": {
+              "type": "integer"
+            },
+            "image": {
+              "type": "string"
+            },
+            "width": {
+              "type": "integer"
+            }
+          },
+          "type": "object"
+        },
+        "type": "array"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / gallery_attributes / $ref
```
Added value: +"#/$defs/gallery_attributes"
```

removedInput schema / properties / gallery_attributes / properties

Removed value: -{
-  "downloadable_images": {
-    "type": "boolean"
-  },
-  "images_attributes": {
-    "items": {
-      "properties": {
-        "height": {
-          "type": "integer"
-        },
-        "id": {
-          "type": "integer"
-        },
-        "image": {
-          "type": "string"
-        },
-        "width": {
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "type": "array"
-  }
-}

removedInput schema / properties / gallery_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / gallery_attributes / $ref
```
Added value: +"#/$defs/gallery_attributes"
```

removedInput schema / properties / payload / properties / gallery_attributes / properties

Removed value: -{
-  "downloadable_images": {
-    "type": "boolean"
-  },
-  "images_attributes": {
-    "items": {
-      "properties": {
-        "height": {
-          "type": "integer"
-        },
-        "id": {
-          "type": "integer"
-        },
-        "image": {
-          "type": "string"
-        },
-        "width": {
-          "type": "integer"
-        }
-      },
-      "type": "object"
-    },
-    "type": "array"
-  }
-}

removedInput schema / properties / payload / properties / gallery_attributes / type
```
Removed value: -"object"
```

Changedcreate_invitation10 fields changed

addedInput schema / $defs

Added value: +{
+  "paywall": {
+    "description": "Optional paywall configuration",
+    "properties": {
+      "paywall_coupon_code": {
+        "description": "Optional coupon code for the paywall trial",
+        "type": "string"
+      },
+      "paywall_id": {
+        "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
+        "type": "integer"
+      },
+      "paywall_price_id": {
+        "description": "Eligible recurring paywall price ID",
+        "type": "integer"
+      },
+      "paywall_trial_days": {
+        "description": "Free trial length in days",
+        "maximum": 730,
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "type": [
+      "object",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / paywall / $ref
```
Added value: +"#/$defs/paywall"
```
removedInput schema / properties / payload / properties / paywall / description
```
Removed value: -"Optional paywall configuration"
```

removedInput schema / properties / payload / properties / paywall / properties

Removed value: -{
-  "paywall_coupon_code": {
-    "description": "Optional coupon code for the paywall trial",
-    "type": "string"
-  },
-  "paywall_id": {
-    "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
-    "type": "integer"
-  },
-  "paywall_price_id": {
-    "description": "Eligible recurring paywall price ID",
-    "type": "integer"
-  },
-  "paywall_trial_days": {
-    "description": "Free trial length in days",
-    "maximum": 730,
-    "minimum": 1,
-    "type": "integer"
-  }
-}

removedInput schema / properties / payload / properties / paywall / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / paywall / $ref
```
Added value: +"#/$defs/paywall"
```
removedInput schema / properties / paywall / description
```
Removed value: -"Optional paywall configuration"
```

removedInput schema / properties / paywall / properties

Removed value: -{
-  "paywall_coupon_code": {
-    "description": "Optional coupon code for the paywall trial",
-    "type": "string"
-  },
-  "paywall_id": {
-    "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
-    "type": "integer"
-  },
-  "paywall_price_id": {
-    "description": "Eligible recurring paywall price ID",
-    "type": "integer"
-  },
-  "paywall_trial_days": {
-    "description": "Free trial length in days",
-    "maximum": 730,
-    "minimum": 1,
-    "type": "integer"
-  }
-}

removedInput schema / properties / paywall / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

Changedcreate_lead1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_member_tag1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_paywall_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_post8 fields changed

addedInput schema / $defs

Added value: +{
+  "tiptap_body": {
+    "properties": {
+      "body": {
+        "properties": {
+          "content": {
+            "items": {
+              "properties": {
+                "attrs": {
+                  "type": "object"
+                },
+                "marks": {
+                  "items": {
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "text": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "type": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "content"
+        ],
+        "type": "object"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / tiptap_body / $ref
```
Added value: +"#/$defs/tiptap_body"
```

removedInput schema / properties / payload / properties / tiptap_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / tiptap_body / type
```
Removed value: -"object"
```
addedInput schema / properties / tiptap_body / $ref
```
Added value: +"#/$defs/tiptap_body"
```

removedInput schema / properties / tiptap_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / tiptap_body / type
```
Removed value: -"object"
```

Changedcreate_profile_field10 fields changed

addedInput schema / $defs

Added value: +{
+  "profile_field": {
+    "properties": {
+      "allow_null": {
+        "description": "Whether the field may be left empty. Defaults to false",
+        "type": "boolean"
+      },
+      "choices_attributes": {
+        "description": "Options for a select or checkbox field. Required for those types, must be absent otherwise",
+        "items": {
+          "properties": {
+            "sort_key": {
+              "description": "Position of the option, ascending",
+              "type": "integer"
+            },
+            "value": {
+              "description": "Option label",
+              "type": "string"
+            }
+          },
+          "required": [
+            "value"
+          ],
+          "type": "object"
+        },
+        "maxItems": 50,
+        "type": "array"
+      },
+      "description": {
+        "description": "Help text shown to members",
+        "type": "string"
+      },
+      "field_type": {
+        "description": "Type of field to create",
+        "enum": [
+          "text",
+          "select",
+          "checkbox",
+          "textarea",
+          "link",
+          "number"
+        ],
+        "type": "string"
+      },
+      "key": {
+        "description": "Unique identifier for the field within the community. Lowercase letters, numbers and underscores only",
+        "maxLength": 100,
+        "minLength": 1,
+        "pattern": "^[a-z0-9_]+$",
+        "type": "string"
+      },
+      "label": {
+        "description": "Field label shown to members",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      },
+      "number_options_attributes": {
+        "description": "Formatting for a number field. Required for that type, must be absent otherwise",
+        "properties": {
+          "decimal": {
+            "description": "Number of decimal places",
+            "minimum": 0,
+            "type": "integer"
+          },
+          "format": {
+            "description": "How the number is formatted",
+            "enum": [
+              "number",
+              "percentage",
+              "custom",
+              "unformatted"
+            ],
+            "type": "string"
+          },
+          "position": {
+            "description": "Which side of the number the custom text sits on",
+            "enum": [
+              "left",
+              "right"
+            ],
+            "type": "string"
+          },
+          "text": {
+            "description": "Custom text shown alongside the number. Required when format is custom",
+            "type": "string"
+          }
+        },
+        "required": [
+          "format"
+        ],
+        "type": "object"
+      },
+      "pages_attributes": {
+        "description": "The pages the field appears on. Send all four to state visibility explicitly",
+        "items": {
+          "properties": {
+            "name": {
+              "description": "Page the field appears on",
+              "enum": [
+                "signup",
+                "edit_profile",
+                "profile_view",
+                "community_view"
+              ],
+              "type": "string"
+            },
+            "visible": {
+              "description": "Whether the field is visible on this page",
+              "type": "boolean"
+            }
+          },
+          "required": [
+            "name",
+            "visible"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "placeholder": {
+        "description": "Placeholder text. Only meaningful for text, textarea and link fields",
+        "type": "string"
+      },
+      "required": {
+        "description": "Whether members must fill the field in. Defaults to false",
+        "type": "boolean"
+      }
+    },
+    "required": [
+      "label",
+      "field_type",
+      "key",
+      "pages_attributes"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / profile_field / $ref
```
Added value: +"#/$defs/profile_field"
```

removedInput schema / properties / payload / properties / profile_field / properties

Removed value: -{
-  "allow_null": {
-    "description": "Whether the field may be left empty. Defaults to false",
-    "type": "boolean"
-  },
-  "choices_attributes": {
-    "description": "Options for a select or checkbox field. Required for those types, must be absent otherwise",
-    "items": {
-      "properties": {
-        "sort_key": {
-          "description": "Position of the option, ascending",
-          "type": "integer"
-        },
-        "value": {
-          "description": "Option label",
-          "type": "string"
-        }
-      },
-      "required": [
-        "value"
-      ],
-      "type": "object"
-    },
-    "maxItems": 50,
-    "type": "array"
-  },
-  "description": {
-    "description": "Help text shown to members",
-    "type": "string"
-  },
-  "field_type": {
-    "description": "Type of field to create",
-    "enum": [
-      "text",
-      "select",
-      "checkbox",
-      "textarea",
-      "link",
-      "number"
-    ],
-    "type": "string"
-  },
-  "key": {
-    "description": "Unique identifier for the field within the community. Lowercase letters, numbers and underscores only",
-    "maxLength": 100,
-    "minLength": 1,
-    "pattern": "^[a-z0-9_]+$",
-    "type": "string"
-  },
-  "label": {
-    "description": "Field label shown to members",
-    "maxLength": 255,
-    "minLength": 1,
-    "type": "string"
-  },
-  "number_options_attributes": {
-    "description": "Formatting for a number field. Required for that type, must be absent otherwise",
-    "properties": {
-      "decimal": {
-        "description": "Number of decimal places",
-        "minimum": 0,
-        "type": "integer"
-      },
-      "format": {
-        "description": "How the number is formatted",
-        "enum": [
-          "number",
-          "percentage",
-          "custom",
-          "unformatted"
-        ],
-        "type": "string"
-      },
-      "position": {
-        "description": "Which side of the number the custom text sits on",
-        "enum": [
-          "left",
-          "right"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "description": "Custom text shown alongside the number. Required when format is custom",
-        "type": "string"
-      }
-    },
-    "required": [
-      "format"
-    ],
-    "type": "object"
-  },
-  "pages_attributes": {
-    "description": "The pages the field appears on. Send all four to state visibility explicitly",
-    "items": {
-      "properties": {
-        "name": {
-          "description": "Page the field appears on",
-          "enum": [
-            "signup",
-            "edit_profile",
-            "profile_view",
-            "community_view"
-          ],
-          "type": "string"
-        },
-        "visible": {
-          "description": "Whether the field is visible on this page",
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "name",
-        "visible"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "placeholder": {
-    "description": "Placeholder text. Only meaningful for text, textarea and link fields",
-    "type": "string"
-  },
-  "required": {
-    "description": "Whether members must fill the field in. Defaults to false",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / profile_field / required

Removed value: -[
-  "label",
-  "field_type",
-  "key",
-  "pages_attributes"
-]

removedInput schema / properties / payload / properties / profile_field / type
```
Removed value: -"object"
```
addedInput schema / properties / profile_field / $ref
```
Added value: +"#/$defs/profile_field"
```

removedInput schema / properties / profile_field / properties

Removed value: -{
-  "allow_null": {
-    "description": "Whether the field may be left empty. Defaults to false",
-    "type": "boolean"
-  },
-  "choices_attributes": {
-    "description": "Options for a select or checkbox field. Required for those types, must be absent otherwise",
-    "items": {
-      "properties": {
-        "sort_key": {
-          "description": "Position of the option, ascending",
-          "type": "integer"
-        },
-        "value": {
-          "description": "Option label",
-          "type": "string"
-        }
-      },
-      "required": [
-        "value"
-      ],
-      "type": "object"
-    },
-    "maxItems": 50,
-    "type": "array"
-  },
-  "description": {
-    "description": "Help text shown to members",
-    "type": "string"
-  },
-  "field_type": {
-    "description": "Type of field to create",
-    "enum": [
-      "text",
-      "select",
-      "checkbox",
-      "textarea",
-      "link",
-      "number"
-    ],
-    "type": "string"
-  },
-  "key": {
-    "description": "Unique identifier for the field within the community. Lowercase letters, numbers and underscores only",
-    "maxLength": 100,
-    "minLength": 1,
-    "pattern": "^[a-z0-9_]+$",
-    "type": "string"
-  },
-  "label": {
-    "description": "Field label shown to members",
-    "maxLength": 255,
-    "minLength": 1,
-    "type": "string"
-  },
-  "number_options_attributes": {
-    "description": "Formatting for a number field. Required for that type, must be absent otherwise",
-    "properties": {
-      "decimal": {
-        "description": "Number of decimal places",
-        "minimum": 0,
-        "type": "integer"
-      },
-      "format": {
-        "description": "How the number is formatted",
-        "enum": [
-          "number",
-          "percentage",
-          "custom",
-          "unformatted"
-        ],
-        "type": "string"
-      },
-      "position": {
-        "description": "Which side of the number the custom text sits on",
-        "enum": [
-          "left",
-          "right"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "description": "Custom text shown alongside the number. Required when format is custom",
-        "type": "string"
-      }
-    },
-    "required": [
-      "format"
-    ],
-    "type": "object"
-  },
-  "pages_attributes": {
-    "description": "The pages the field appears on. Send all four to state visibility explicitly",
-    "items": {
-      "properties": {
-        "name": {
-          "description": "Page the field appears on",
-          "enum": [
-            "signup",
-            "edit_profile",
-            "profile_view",
-            "community_view"
-          ],
-          "type": "string"
-        },
-        "visible": {
-          "description": "Whether the field is visible on this page",
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "name",
-        "visible"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "placeholder": {
-    "description": "Placeholder text. Only meaningful for text, textarea and link fields",
-    "type": "string"
-  },
-  "required": {
-    "description": "Whether members must fill the field in. Defaults to false",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / profile_field / required

Removed value: -[
-  "label",
-  "field_type",
-  "key",
-  "pages_attributes"
-]

removedInput schema / properties / profile_field / type
```
Removed value: -"object"
```

Changedcreate_space26 fields changed

addedInput schema / $defs

Added value: +{
+  "course_setting": {
+    "description": "Course space configuration",
+    "properties": {
+      "course_type": {
+        "enum": [
+          "self_paced",
+          "scheduled",
+          "structured"
+        ],
+        "type": "string"
+      },
+      "custom_lesson_label": {
+        "enum": [
+          "activity",
+          "assignment",
+          "challenge",
+          "class",
+          "day",
+          "exercise",
+          "lecture",
+          "lesson",
+          "practice",
+          "session",
+          "topic",
+          "tutorial",
+          "workshop"
+        ],
+        "type": "string"
+      },
+      "custom_section_label": {
+        "enum": [
+          "chapter",
+          "level",
+          "module",
+          "part",
+          "path",
+          "phase",
+          "section",
+          "stage",
+          "track",
+          "unit",
+          "week"
+        ],
+        "type": "string"
+      },
+      "enforce_lessons_order": {
+        "type": "boolean"
+      },
+      "lesson_thumbnails_visible": {
+        "type": "boolean"
+      },
+      "new_comment_notification_enabled": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "meta_tag_attributes": {
+    "description": "SEO meta tag attributes",
+    "properties": {
+      "meta_description": {
+        "type": "string"
+      },
+      "meta_title": {
+        "type": "string"
+      },
+      "opengraph_description": {
+        "type": "string"
+      },
+      "opengraph_image": {
+        "type": "string"
+      },
+      "opengraph_title": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "visible_tabs": {
+    "description": "Visible tabs configuration for the space",
+    "properties": {
+      "members": {
+        "description": "Show members tab",
+        "type": "boolean"
+      },
+      "past": {
+        "description": "Show past events tab",
+        "type": "boolean"
+      },
+      "posts": {
+        "description": "Show posts tab",
+        "type": "boolean"
+      },
+      "upcoming": {
+        "description": "Show upcoming events tab",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / course_setting / $ref
```
Added value: +"#/$defs/course_setting"
```
removedInput schema / properties / course_setting / description
```
Removed value: -"Course space configuration"
```

removedInput schema / properties / course_setting / properties

Removed value: -{
-  "course_type": {
-    "enum": [
-      "self_paced",
-      "scheduled",
-      "structured"
-    ],
-    "type": "string"
-  },
-  "custom_lesson_label": {
-    "enum": [
-      "activity",
-      "assignment",
-      "challenge",
-      "class",
-      "day",
-      "exercise",
-      "lecture",
-      "lesson",
-      "practice",
-      "session",
-      "topic",
-      "tutorial",
-      "workshop"
-    ],
-    "type": "string"
-  },
-  "custom_section_label": {
-    "enum": [
-      "chapter",
-      "level",
-      "module",
-      "part",
-      "path",
-      "phase",
-      "section",
-      "stage",
-      "track",
-      "unit",
-      "week"
-    ],
-    "type": "string"
-  },
-  "enforce_lessons_order": {
-    "type": "boolean"
-  },
-  "lesson_thumbnails_visible": {
-    "type": "boolean"
-  },
-  "new_comment_notification_enabled": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / course_setting / type
```
Removed value: -"object"
```
addedInput schema / properties / meta_tag_attributes / $ref
```
Added value: +"#/$defs/meta_tag_attributes"
```
removedInput schema / properties / meta_tag_attributes / description
```
Removed value: -"SEO meta tag attributes"
```

removedInput schema / properties / meta_tag_attributes / properties

Removed value: -{
-  "meta_description": {
-    "type": "string"
-  },
-  "meta_title": {
-    "type": "string"
-  },
-  "opengraph_description": {
-    "type": "string"
-  },
-  "opengraph_image": {
-    "type": "string"
-  },
-  "opengraph_title": {
-    "type": "string"
-  }
-}

removedInput schema / properties / meta_tag_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / course_setting / $ref
```
Added value: +"#/$defs/course_setting"
```
removedInput schema / properties / payload / properties / course_setting / description
```
Removed value: -"Course space configuration"
```

removedInput schema / properties / payload / properties / course_setting / properties

Removed value: -{
-  "course_type": {
-    "enum": [
-      "self_paced",
-      "scheduled",
-      "structured"
-    ],
-    "type": "string"
-  },
-  "custom_lesson_label": {
-    "enum": [
-      "activity",
-      "assignment",
-      "challenge",
-      "class",
-      "day",
-      "exercise",
-      "lecture",
-      "lesson",
-      "practice",
-      "session",
-      "topic",
-      "tutorial",
-      "workshop"
-    ],
-    "type": "string"
-  },
-  "custom_section_label": {
-    "enum": [
-      "chapter",
-      "level",
-      "module",
-      "part",
-      "path",
-      "phase",
-      "section",
-      "stage",
-      "track",
-      "unit",
-      "week"
-    ],
-    "type": "string"
-  },
-  "enforce_lessons_order": {
-    "type": "boolean"
-  },
-  "lesson_thumbnails_visible": {
-    "type": "boolean"
-  },
-  "new_comment_notification_enabled": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / course_setting / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / meta_tag_attributes / $ref
```
Added value: +"#/$defs/meta_tag_attributes"
```
removedInput schema / properties / payload / properties / meta_tag_attributes / description
```
Removed value: -"SEO meta tag attributes"
```

removedInput schema / properties / payload / properties / meta_tag_attributes / properties

Removed value: -{
-  "meta_description": {
-    "type": "string"
-  },
-  "meta_title": {
-    "type": "string"
-  },
-  "opengraph_description": {
-    "type": "string"
-  },
-  "opengraph_image": {
-    "type": "string"
-  },
-  "opengraph_title": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / meta_tag_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / visible_tabs / $ref
```
Added value: +"#/$defs/visible_tabs"
```
removedInput schema / properties / payload / properties / visible_tabs / description
```
Removed value: -"Visible tabs configuration for the space"
```

removedInput schema / properties / payload / properties / visible_tabs / properties

Removed value: -{
-  "members": {
-    "description": "Show members tab",
-    "type": "boolean"
-  },
-  "past": {
-    "description": "Show past events tab",
-    "type": "boolean"
-  },
-  "posts": {
-    "description": "Show posts tab",
-    "type": "boolean"
-  },
-  "upcoming": {
-    "description": "Show upcoming events tab",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / visible_tabs / type
```
Removed value: -"object"
```
addedInput schema / properties / visible_tabs / $ref
```
Added value: +"#/$defs/visible_tabs"
```

removedInput schema / properties / visible_tabs / description

Removed value: -"Visible tabs configuration for the space"

removedInput schema / properties / visible_tabs / properties

Removed value: -{
-  "members": {
-    "description": "Show members tab",
-    "type": "boolean"
-  },
-  "past": {
-    "description": "Show past events tab",
-    "type": "boolean"
-  },
-  "posts": {
-    "description": "Show posts tab",
-    "type": "boolean"
-  },
-  "upcoming": {
-    "description": "Show upcoming events tab",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / visible_tabs / type
```
Removed value: -"object"
```

Changedcreate_space_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_space_group_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedcreate_topic1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddeactivate_workflow1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_comment1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_community_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_community_segment1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_course_lesson1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_course_section1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_event1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_event_attendee1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_filter_control1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_form1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_image_post1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_invitation_link1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_lead1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_member_tag1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_paywall1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_paywall_coupon1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_post1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_profile_field1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_space1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_space_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_space_group_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeddelete_topic1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedduplicate_community_segment1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedduplicate_event1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedduplicate_form1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedduplicate_image_post1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedduplicate_workflow1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedexport_community_member_charges1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedexport_community_member_subscriptions1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedexport_paywall_affiliate_payouts1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedimport_chat_room_message1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedinvite_paywall_affiliates1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedmark_paywall_affiliate_payouts_paid1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedpublish_paywall1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedrefund_community_member_charge1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedremove_from_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedremove_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedremove_space_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedreorder_course_lessons10 fields changed

addedInput schema / $defs

Added value: +{
+  "new_order": {
+    "description": "All course sections and lessons in their final order",
+    "items": {
+      "properties": {
+        "lesson_ids": {
+          "items": {
+            "type": "integer"
+          },
+          "type": "array"
+        },
+        "section_id": {
+          "type": "integer"
+        }
+      },
+      "required": [
+        "section_id",
+        "lesson_ids"
+      ],
+      "type": "object"
+    },
+    "type": "array"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / new_order / $ref
```
Added value: +"#/$defs/new_order"
```

removedInput schema / properties / new_order / description

Removed value: -"All course sections and lessons in their final order"

removedInput schema / properties / new_order / items

Removed value: -{
-  "properties": {
-    "lesson_ids": {
-      "items": {
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "section_id": {
-      "type": "integer"
-    }
-  },
-  "required": [
-    "section_id",
-    "lesson_ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / new_order / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / new_order / $ref
```
Added value: +"#/$defs/new_order"
```
removedInput schema / properties / payload / properties / new_order / description
```
Removed value: -"All course sections and lessons in their final order"
```

removedInput schema / properties / payload / properties / new_order / items

Removed value: -{
-  "properties": {
-    "lesson_ids": {
-      "items": {
-        "type": "integer"
-      },
-      "type": "array"
-    },
-    "section_id": {
-      "type": "integer"
-    }
-  },
-  "required": [
-    "section_id",
-    "lesson_ids"
-  ],
-  "type": "object"
-}

removedInput schema / properties / payload / properties / new_order / type
```
Removed value: -"array"
```

Changedreport_flagged_content10 fields changed

addedInput schema / $defs

Added value: +{
+  "flagged_content": {
+    "properties": {
+      "content_id": {
+        "type": "integer"
+      },
+      "content_type": {
+        "enum": [
+          "post",
+          "comment",
+          "connect/connection",
+          "chat_room_message"
+        ],
+        "type": "string"
+      },
+      "reported_reason_body": {
+        "type": "string"
+      },
+      "reported_reason_type": {
+        "enum": [
+          "harassment",
+          "spam",
+          "incorrect_location",
+          "against_guidelines",
+          "other"
+        ],
+        "type": "string"
+      }
+    },
+    "required": [
+      "content_id",
+      "content_type",
+      "reported_reason_type",
+      "reported_reason_body"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / flagged_content / $ref
```
Added value: +"#/$defs/flagged_content"
```

removedInput schema / properties / flagged_content / properties

Removed value: -{
-  "content_id": {
-    "type": "integer"
-  },
-  "content_type": {
-    "enum": [
-      "post",
-      "comment",
-      "connect/connection",
-      "chat_room_message"
-    ],
-    "type": "string"
-  },
-  "reported_reason_body": {
-    "type": "string"
-  },
-  "reported_reason_type": {
-    "enum": [
-      "harassment",
-      "spam",
-      "incorrect_location",
-      "against_guidelines",
-      "other"
-    ],
-    "type": "string"
-  }
-}

removedInput schema / properties / flagged_content / required

Removed value: -[
-  "content_id",
-  "content_type",
-  "reported_reason_type",
-  "reported_reason_body"
-]

removedInput schema / properties / flagged_content / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / flagged_content / $ref
```
Added value: +"#/$defs/flagged_content"
```

removedInput schema / properties / payload / properties / flagged_content / properties

Removed value: -{
-  "content_id": {
-    "type": "integer"
-  },
-  "content_type": {
-    "enum": [
-      "post",
-      "comment",
-      "connect/connection",
-      "chat_room_message"
-    ],
-    "type": "string"
-  },
-  "reported_reason_body": {
-    "type": "string"
-  },
-  "reported_reason_type": {
-    "enum": [
-      "harassment",
-      "spam",
-      "incorrect_location",
-      "against_guidelines",
-      "other"
-    ],
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / flagged_content / required

Removed value: -[
-  "content_id",
-  "content_type",
-  "reported_reason_type",
-  "reported_reason_body"
-]

removedInput schema / properties / payload / properties / flagged_content / type
```
Removed value: -"object"
```

Changedresume_community_member_subscription1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedrevoke_invitation_link1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedsend_message8 fields changed

addedInput schema / $defs

Added value: +{
+  "rich_text_body": {
+    "properties": {
+      "attachments": {
+        "items": {},
+        "type": "array"
+      },
+      "body": {
+        "properties": {
+          "content": {
+            "items": {
+              "properties": {
+                "content": {
+                  "items": {
+                    "properties": {
+                      "attrs": {
+                        "properties": {
+                          "href": {
+                            "type": [
+                              "string",
+                              "null"
+                            ]
+                          },
+                          "sgid": {
+                            "type": "string"
+                          },
+                          "target": {
+                            "type": [
+                              "string",
+                              "null"
+                            ]
+                          }
+                        },
+                        "required": [
+                          "sgid"
+                        ],
+                        "type": "object"
+                      },
+                      "circle_ios_fallback_text": {
+                        "type": [
+                          "string",
+                          "null"
+                        ]
+                      },
+                      "marks": {
+                        "items": {
+                          "properties": {
+                            "attrs": {
+                              "properties": {
+                                "href": {
+                                  "type": "string"
+                                },
+                                "target": {
+                                  "type": "string"
+                                }
+                              },
+                              "type": "object"
+                            },
+                            "type": {
+                              "type": "string"
+                            }
+                          },
+                          "type": "object"
+                        },
+                        "type": [
+                          "array",
+                          "null"
+                        ]
+                      },
+                      "text": {
+                        "type": [
+                          "string",
+                          "null"
+                        ]
+                      },
+                      "type": {
+                        "type": "string"
+                      }
+                    },
+                    "required": [
+                      "type"
+                    ],
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "type": {
+                  "type": "string"
+                }
+              },
+              "required": [
+                "type",
+                "content"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "circle_ios_fallback_text": {
+        "type": "string"
+      },
+      "community_members": {
+        "items": {},
+        "type": "array"
+      },
+      "entities": {
+        "items": {},
+        "type": "array"
+      },
+      "format": {
+        "type": "string"
+      },
+      "group_mentions": {
+        "items": {},
+        "type": "array"
+      },
+      "inline_attachments": {
+        "items": {},
+        "type": "array"
+      },
+      "polls": {
+        "items": {},
+        "type": "array"
+      },
+      "sgids_to_object_map": {
+        "type": "object"
+      }
+    },
+    "type": [
+      "object",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / payload / properties / rich_text_body / properties

Removed value: -{
-  "attachments": {
-    "items": {},
-    "type": "array"
-  },
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "content": {
-              "items": {
-                "properties": {
-                  "attrs": {
-                    "properties": {
-                      "href": {
-                        "type": [
-                          "string",
-                          "null"
-                        ]
-                      },
-                      "sgid": {
-                        "type": "string"
-                      },
-                      "target": {
-                        "type": [
-                          "string",
-                          "null"
-                        ]
-                      }
-                    },
-                    "required": [
-                      "sgid"
-                    ],
-                    "type": "object"
-                  },
-                  "circle_ios_fallback_text": {
-                    "type": [
-                      "string",
-                      "null"
-                    ]
-                  },
-                  "marks": {
-                    "items": {
-                      "properties": {
-                        "attrs": {
-                          "properties": {
-                            "href": {
-                              "type": "string"
-                            },
-                            "target": {
-                              "type": "string"
-                            }
-                          },
-                          "type": "object"
-                        },
-                        "type": {
-                          "type": "string"
-                        }
-                      },
-                      "type": "object"
-                    },
-                    "type": [
-                      "array",
-                      "null"
-                    ]
-                  },
-                  "text": {
-                    "type": [
-                      "string",
-                      "null"
-                    ]
-                  },
-                  "type": {
-                    "type": "string"
-                  }
-                },
-                "required": [
-                  "type"
-                ],
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "required": [
-            "type",
-            "content"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "circle_ios_fallback_text": {
-    "type": "string"
-  },
-  "community_members": {
-    "items": {},
-    "type": "array"
-  },
-  "entities": {
-    "items": {},
-    "type": "array"
-  },
-  "format": {
-    "type": "string"
-  },
-  "group_mentions": {
-    "items": {},
-    "type": "array"
-  },
-  "inline_attachments": {
-    "items": {},
-    "type": "array"
-  },
-  "polls": {
-    "items": {},
-    "type": "array"
-  },
-  "sgids_to_object_map": {
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / rich_text_body / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / rich_text_body / properties

Removed value: -{
-  "attachments": {
-    "items": {},
-    "type": "array"
-  },
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "content": {
-              "items": {
-                "properties": {
-                  "attrs": {
-                    "properties": {
-                      "href": {
-                        "type": [
-                          "string",
-                          "null"
-                        ]
-                      },
-                      "sgid": {
-                        "type": "string"
-                      },
-                      "target": {
-                        "type": [
-                          "string",
-                          "null"
-                        ]
-                      }
-                    },
-                    "required": [
-                      "sgid"
-                    ],
-                    "type": "object"
-                  },
-                  "circle_ios_fallback_text": {
-                    "type": [
-                      "string",
-                      "null"
-                    ]
-                  },
-                  "marks": {
-                    "items": {
-                      "properties": {
-                        "attrs": {
-                          "properties": {
-                            "href": {
-                              "type": "string"
-                            },
-                            "target": {
-                              "type": "string"
-                            }
-                          },
-                          "type": "object"
-                        },
-                        "type": {
-                          "type": "string"
-                        }
-                      },
-                      "type": "object"
-                    },
-                    "type": [
-                      "array",
-                      "null"
-                    ]
-                  },
-                  "text": {
-                    "type": [
-                      "string",
-                      "null"
-                    ]
-                  },
-                  "type": {
-                    "type": "string"
-                  }
-                },
-                "required": [
-                  "type"
-                ],
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "required": [
-            "type",
-            "content"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "circle_ios_fallback_text": {
-    "type": "string"
-  },
-  "community_members": {
-    "items": {},
-    "type": "array"
-  },
-  "entities": {
-    "items": {},
-    "type": "array"
-  },
-  "format": {
-    "type": "string"
-  },
-  "group_mentions": {
-    "items": {},
-    "type": "array"
-  },
-  "inline_attachments": {
-    "items": {},
-    "type": "array"
-  },
-  "polls": {
-    "items": {},
-    "type": "array"
-  },
-  "sgids_to_object_map": {
-    "type": "object"
-  }
-}

removedInput schema / properties / rich_text_body / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

Changedstart_paywall_affiliate_payouts1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedtag_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedunarchive_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedunarchive_paywall1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedunarchive_profile_field1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedunfollow_post1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changeduntag_member1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_access_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_chat_preferences1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_community14 fields changed

addedInput schema / $defs

Added value: +{
+  "community": {
+    "properties": {
+      "allow_signups_to_public_community": {
+        "type": "boolean"
+      },
+      "community_switcher_enabled": {
+        "type": "boolean"
+      },
+      "custom_cta_for_share_links": {
+        "type": "boolean"
+      },
+      "custom_tos": {
+        "type": "string"
+      },
+      "custom_tos_enabled": {
+        "type": "boolean"
+      },
+      "default_existing_member_space_id": {
+        "type": "integer"
+      },
+      "default_logged_out_space_id": {
+        "type": "integer"
+      },
+      "default_new_member_space_id": {
+        "type": "integer"
+      },
+      "default_search_sorting": {
+        "enum": [
+          "relevance",
+          "latest",
+          "oldest",
+          "alphabetical"
+        ],
+        "type": "string"
+      },
+      "digest_intro": {
+        "type": "string"
+      },
+      "digest_subject": {
+        "type": "string"
+      },
+      "digests_hide_comments": {
+        "type": "boolean"
+      },
+      "digests_hide_members": {
+        "type": "boolean"
+      },
+      "digests_hide_posts": {
+        "type": "boolean"
+      },
+      "digests_hide_stats": {
+        "type": "boolean"
+      },
+      "is_private": {
+        "type": "boolean"
+      },
+      "locale": {
+        "enum": [
+          "en",
+          "pt",
+          "pt-PT",
+          "es",
+          "fr",
+          "it"
+        ],
+        "type": "string"
+      },
+      "locked_post_cta_body": {
+        "type": "string"
+      },
+      "locked_post_cta_button_text": {
+        "type": "string"
+      },
+      "locked_post_cta_button_url": {
+        "type": "string"
+      },
+      "locked_post_cta_heading": {
+        "type": "string"
+      },
+      "logo": {
+        "description": "signed_id of the logo returned from the direct upload endpoint",
+        "type": "string"
+      },
+      "name": {
+        "type": "string"
+      },
+      "prefs": {
+        "properties": {
+          "brand_color": {
+            "properties": {
+              "dark": {
+                "type": "string"
+              },
+              "light": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "brand_text_color": {
+            "properties": {
+              "dark": {
+                "type": "string"
+              },
+              "light": {
+                "type": "string"
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "private_signup_link_label": {
+        "type": "string"
+      },
+      "private_signup_link_url": {
+        "type": "string"
+      },
+      "reply_to_email": {
+        "type": "string"
+      },
+      "slug": {
+        "type": "string"
+      },
+      "weekly_digest_enabled": {
+        "type": "boolean"
+      },
+      "white_label": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "community_setting": {
+    "properties": {
+      "allow_members_to_go_live": {
+        "type": "boolean"
+      },
+      "allow_moderator_csv_download": {
+        "type": "boolean"
+      },
+      "allow_profile_search_indexing": {
+        "type": "boolean"
+      },
+      "community_activity_notifications_email_enabled": {
+        "type": "boolean"
+      },
+      "community_activity_notifications_in_app_enabled": {
+        "type": "boolean"
+      },
+      "deactivate_account_enabled": {
+        "type": "boolean"
+      },
+      "default_logged_out_redirect_id": {
+        "type": "integer"
+      },
+      "default_logged_out_redirect_type": {
+        "enum": [
+          "Space",
+          "Site::Page",
+          "feed"
+        ],
+        "type": "string"
+      },
+      "default_space_ids": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "desktop_app_community_visibility_enabled": {
+        "type": "boolean"
+      },
+      "enforce_otp_for_signup": {
+        "type": "boolean"
+      },
+      "hide_emails_on_member_profiles": {
+        "type": "boolean"
+      },
+      "ios_app_enabled": {
+        "type": "boolean"
+      },
+      "member_media_uploads_enabled": {
+        "type": "boolean"
+      },
+      "show_ios_app_banner": {
+        "type": "boolean"
+      },
+      "truncate_post_body_in_email_notifications": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

addedInput schema / properties / community / $ref
```
Added value: +"#/$defs/community"
```

removedInput schema / properties / community / properties

Removed value: -{
-  "allow_signups_to_public_community": {
-    "type": "boolean"
-  },
-  "community_switcher_enabled": {
-    "type": "boolean"
-  },
-  "custom_cta_for_share_links": {
-    "type": "boolean"
-  },
-  "custom_tos": {
-    "type": "string"
-  },
-  "custom_tos_enabled": {
-    "type": "boolean"
-  },
-  "default_existing_member_space_id": {
-    "type": "integer"
-  },
-  "default_logged_out_space_id": {
-    "type": "integer"
-  },
-  "default_new_member_space_id": {
-    "type": "integer"
-  },
-  "default_search_sorting": {
-    "enum": [
-      "relevance",
-      "latest",
-      "oldest",
-      "alphabetical"
-    ],
-    "type": "string"
-  },
-  "digest_intro": {
-    "type": "string"
-  },
-  "digest_subject": {
-    "type": "string"
-  },
-  "digests_hide_comments": {
-    "type": "boolean"
-  },
-  "digests_hide_members": {
-    "type": "boolean"
-  },
-  "digests_hide_posts": {
-    "type": "boolean"
-  },
-  "digests_hide_stats": {
-    "type": "boolean"
-  },
-  "is_private": {
-    "type": "boolean"
-  },
-  "locale": {
-    "enum": [
-      "en",
-      "pt",
-      "pt-PT",
-      "es",
-      "fr",
-      "it"
-    ],
-    "type": "string"
-  },
-  "locked_post_cta_body": {
-    "type": "string"
-  },
-  "locked_post_cta_button_text": {
-    "type": "string"
-  },
-  "locked_post_cta_button_url": {
-    "type": "string"
-  },
-  "locked_post_cta_heading": {
-    "type": "string"
-  },
-  "logo": {
-    "description": "signed_id of the logo returned from the direct upload endpoint",
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  },
-  "prefs": {
-    "properties": {
-      "brand_color": {
-        "properties": {
-          "dark": {
-            "type": "string"
-          },
-          "light": {
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "brand_text_color": {
-        "properties": {
-          "dark": {
-            "type": "string"
-          },
-          "light": {
-            "type": "string"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "private_signup_link_label": {
-    "type": "string"
-  },
-  "private_signup_link_url": {
-    "type": "string"
-  },
-  "reply_to_email": {
-    "type": "string"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "weekly_digest_enabled": {
-    "type": "boolean"
-  },
-  "white_label": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / community / type
```
Removed value: -"object"
```
addedInput schema / properties / community_setting / $ref
```
Added value: +"#/$defs/community_setting"
```

removedInput schema / properties / community_setting / properties

Removed value: -{
-  "allow_members_to_go_live": {
-    "type": "boolean"
-  },
-  "allow_moderator_csv_download": {
-    "type": "boolean"
-  },
-  "allow_profile_search_indexing": {
-    "type": "boolean"
-  },
-  "community_activity_notifications_email_enabled": {
-    "type": "boolean"
-  },
-  "community_activity_notifications_in_app_enabled": {
-    "type": "boolean"
-  },
-  "deactivate_account_enabled": {
-    "type": "boolean"
-  },
-  "default_logged_out_redirect_id": {
-    "type": "integer"
-  },
-  "default_logged_out_redirect_type": {
-    "enum": [
-      "Space",
-      "Site::Page",
-      "feed"
-    ],
-    "type": "string"
-  },
-  "default_space_ids": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "desktop_app_community_visibility_enabled": {
-    "type": "boolean"
-  },
-  "enforce_otp_for_signup": {
-    "type": "boolean"
-  },
-  "hide_emails_on_member_profiles": {
-    "type": "boolean"
-  },
-  "ios_app_enabled": {
-    "type": "boolean"
-  },
-  "member_media_uploads_enabled": {
-    "type": "boolean"
-  },
-  "show_ios_app_banner": {
-    "type": "boolean"
-  },
-  "truncate_post_body_in_email_notifications": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / community_setting / type
```
Removed value: -"object"
```

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / community / $ref
```
Added value: +"#/$defs/community"
```

removedInput schema / properties / payload / properties / community / properties

Removed value: -{
-  "allow_signups_to_public_community": {
-    "type": "boolean"
-  },
-  "community_switcher_enabled": {
-    "type": "boolean"
-  },
-  "custom_cta_for_share_links": {
-    "type": "boolean"
-  },
-  "custom_tos": {
-    "type": "string"
-  },
-  "custom_tos_enabled": {
-    "type": "boolean"
-  },
-  "default_existing_member_space_id": {
-    "type": "integer"
-  },
-  "default_logged_out_space_id": {
-    "type": "integer"
-  },
-  "default_new_member_space_id": {
-    "type": "integer"
-  },
-  "default_search_sorting": {
-    "enum": [
-      "relevance",
-      "latest",
-      "oldest",
-      "alphabetical"
-    ],
-    "type": "string"
-  },
-  "digest_intro": {
-    "type": "string"
-  },
-  "digest_subject": {
-    "type": "string"
-  },
-  "digests_hide_comments": {
-    "type": "boolean"
-  },
-  "digests_hide_members": {
-    "type": "boolean"
-  },
-  "digests_hide_posts": {
-    "type": "boolean"
-  },
-  "digests_hide_stats": {
-    "type": "boolean"
-  },
-  "is_private": {
-    "type": "boolean"
-  },
-  "locale": {
-    "enum": [
-      "en",
-      "pt",
-      "pt-PT",
-      "es",
-      "fr",
-      "it"
-    ],
-    "type": "string"
-  },
-  "locked_post_cta_body": {
-    "type": "string"
-  },
-  "locked_post_cta_button_text": {
-    "type": "string"
-  },
-  "locked_post_cta_button_url": {
-    "type": "string"
-  },
-  "locked_post_cta_heading": {
-    "type": "string"
-  },
-  "logo": {
-    "description": "signed_id of the logo returned from the direct upload endpoint",
-    "type": "string"
-  },
-  "name": {
-    "type": "string"
-  },
-  "prefs": {
-    "properties": {
-      "brand_color": {
-        "properties": {
-          "dark": {
-            "type": "string"
-          },
-          "light": {
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "brand_text_color": {
-        "properties": {
-          "dark": {
-            "type": "string"
-          },
-          "light": {
-            "type": "string"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "private_signup_link_label": {
-    "type": "string"
-  },
-  "private_signup_link_url": {
-    "type": "string"
-  },
-  "reply_to_email": {
-    "type": "string"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "weekly_digest_enabled": {
-    "type": "boolean"
-  },
-  "white_label": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / community / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / community_setting / $ref
```
Added value: +"#/$defs/community_setting"
```

removedInput schema / properties / payload / properties / community_setting / properties

Removed value: -{
-  "allow_members_to_go_live": {
-    "type": "boolean"
-  },
-  "allow_moderator_csv_download": {
-    "type": "boolean"
-  },
-  "allow_profile_search_indexing": {
-    "type": "boolean"
-  },
-  "community_activity_notifications_email_enabled": {
-    "type": "boolean"
-  },
-  "community_activity_notifications_in_app_enabled": {
-    "type": "boolean"
-  },
-  "deactivate_account_enabled": {
-    "type": "boolean"
-  },
-  "default_logged_out_redirect_id": {
-    "type": "integer"
-  },
-  "default_logged_out_redirect_type": {
-    "enum": [
-      "Space",
-      "Site::Page",
-      "feed"
-    ],
-    "type": "string"
-  },
-  "default_space_ids": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "desktop_app_community_visibility_enabled": {
-    "type": "boolean"
-  },
-  "enforce_otp_for_signup": {
-    "type": "boolean"
-  },
-  "hide_emails_on_member_profiles": {
-    "type": "boolean"
-  },
-  "ios_app_enabled": {
-    "type": "boolean"
-  },
-  "member_media_uploads_enabled": {
-    "type": "boolean"
-  },
-  "show_ios_app_banner": {
-    "type": "boolean"
-  },
-  "truncate_post_body_in_email_notifications": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / community_setting / type
```
Removed value: -"object"
```

Changedupdate_community_segment10 fields changed

addedInput schema / $defs

Added value: +{
+  "rules": {
+    "properties": {
+      "rule_type": {
+        "enum": [
+          "all_contacts",
+          "all_members",
+          "custom_filters",
+          "selected_members"
+        ],
+        "type": "string"
+      },
+      "rules": {
+        "anyOf": [
+          {
+            "items": {
+              "properties": {
+                "filter_type": {
+                  "enum": [
+                    "is",
+                    "is_not",
+                    "contains",
+                    "does_not_contain",
+                    "gt",
+                    "lt",
+                    "eq"
+                  ],
+                  "type": "string"
+                },
+                "id": {
+                  "type": "string"
+                },
+                "key": {
+                  "type": "string"
+                },
+                "value": {
+                  "type": [
+                    "string",
+                    "boolean"
+                  ]
+                }
+              },
+              "required": [
+                "key",
+                "value"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          },
+          {
+            "items": {
+              "properties": {
+                "community_member_id": {
+                  "type": "integer"
+                },
+                "email": {
+                  "format": "email",
+                  "type": "string"
+                }
+              },
+              "required": [
+                "email",
+                "community_member_id"
+              ],
+              "type": "object"
+            },
+            "type": "array"
+          }
+        ]
+      }
+    },
+    "required": [
+      "rule_type",
+      "rules"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / rules / $ref
```
Added value: +"#/$defs/rules"
```

removedInput schema / properties / payload / properties / rules / properties

Removed value: -{
-  "rule_type": {
-    "enum": [
-      "all_contacts",
-      "all_members",
-      "custom_filters",
-      "selected_members"
-    ],
-    "type": "string"
-  },
-  "rules": {
-    "anyOf": [
-      {
-        "items": {
-          "properties": {
-            "filter_type": {
-              "enum": [
-                "is",
-                "is_not",
-                "contains",
-                "does_not_contain",
-                "gt",
-                "lt",
-                "eq"
-              ],
-              "type": "string"
-            },
-            "id": {
-              "type": "string"
-            },
-            "key": {
-              "type": "string"
-            },
-            "value": {
-              "type": [
-                "string",
-                "boolean"
-              ]
-            }
-          },
-          "required": [
-            "key",
-            "value"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      {
-        "items": {
-          "properties": {
-            "community_member_id": {
-              "type": "integer"
-            },
-            "email": {
-              "format": "email",
-              "type": "string"
-            }
-          },
-          "required": [
-            "email",
-            "community_member_id"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  }
-}

removedInput schema / properties / payload / properties / rules / required
```
Removed value: -[
-  "rule_type",
-  "rules"
-]
```
removedInput schema / properties / payload / properties / rules / type
```
Removed value: -"object"
```
addedInput schema / properties / rules / $ref
```
Added value: +"#/$defs/rules"
```

removedInput schema / properties / rules / properties

Removed value: -{
-  "rule_type": {
-    "enum": [
-      "all_contacts",
-      "all_members",
-      "custom_filters",
-      "selected_members"
-    ],
-    "type": "string"
-  },
-  "rules": {
-    "anyOf": [
-      {
-        "items": {
-          "properties": {
-            "filter_type": {
-              "enum": [
-                "is",
-                "is_not",
-                "contains",
-                "does_not_contain",
-                "gt",
-                "lt",
-                "eq"
-              ],
-              "type": "string"
-            },
-            "id": {
-              "type": "string"
-            },
-            "key": {
-              "type": "string"
-            },
-            "value": {
-              "type": [
-                "string",
-                "boolean"
-              ]
-            }
-          },
-          "required": [
-            "key",
-            "value"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      },
-      {
-        "items": {
-          "properties": {
-            "community_member_id": {
-              "type": "integer"
-            },
-            "email": {
-              "format": "email",
-              "type": "string"
-            }
-          },
-          "required": [
-            "email",
-            "community_member_id"
-          ],
-          "type": "object"
-        },
-        "type": "array"
-      }
-    ]
-  }
-}

removedInput schema / properties / rules / required
```
Removed value: -[
-  "rule_type",
-  "rules"
-]
```
removedInput schema / properties / rules / type
```
Removed value: -"object"
```

Changedupdate_connect_settings20 fields changed

addedInput schema / $defs

Added value: +{
+  "connect": {
+    "properties": {
+      "enabled": {
+        "description": "Whether the Connect feature is enabled for the community",
+        "type": "boolean"
+      },
+      "exclude_admins_from_recommendations": {
+        "description": "Whether admins are excluded from connection recommendations",
+        "type": "boolean"
+      },
+      "exclude_moderators_from_recommendations": {
+        "description": "Whether moderators are excluded from connection recommendations",
+        "type": "boolean"
+      },
+      "recommendations": {
+        "description": "Whether member-to-member connection recommendations are enabled. Only effective when connect.enabled is true.",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "member_directory": {
+    "properties": {
+      "public": {
+        "description": "Whether the member directory is publicly visible",
+        "type": "boolean"
+      },
+      "sort": {
+        "description": "Default sort order for the member directory",
+        "enum": [
+          "alphabetical",
+          "oldest",
+          "latest"
+        ],
+        "type": "string"
+      },
+      "view": {
+        "description": "Default view layout for the member directory",
+        "enum": [
+          "list",
+          "cards"
+        ],
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "messaging": {
+    "properties": {
+      "enabled": {
+        "description": "Whether messaging is enabled for the community (master toggle)",
+        "type": "boolean"
+      },
+      "group_messaging_enabled": {
+        "description": "Whether members can create group chats",
+        "type": "boolean"
+      },
+      "member_to_member_messaging_enabled": {
+        "description": "Whether members can direct message one another",
+        "type": "boolean"
+      },
+      "require_connection_before_messaging": {
+        "description": "Whether members must be connected before they can message each other",
+        "type": "boolean"
+      },
+      "voice_messages_enabled": {
+        "description": "Whether voice messages are enabled in chats",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / connect / $ref
```
Added value: +"#/$defs/connect"
```

removedInput schema / properties / connect / properties

Removed value: -{
-  "enabled": {
-    "description": "Whether the Connect feature is enabled for the community",
-    "type": "boolean"
-  },
-  "exclude_admins_from_recommendations": {
-    "description": "Whether admins are excluded from connection recommendations",
-    "type": "boolean"
-  },
-  "exclude_moderators_from_recommendations": {
-    "description": "Whether moderators are excluded from connection recommendations",
-    "type": "boolean"
-  },
-  "recommendations": {
-    "description": "Whether member-to-member connection recommendations are enabled. Only effective when connect.enabled is true.",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / connect / type
```
Removed value: -"object"
```
addedInput schema / properties / member_directory / $ref
```
Added value: +"#/$defs/member_directory"
```

removedInput schema / properties / member_directory / properties

Removed value: -{
-  "public": {
-    "description": "Whether the member directory is publicly visible",
-    "type": "boolean"
-  },
-  "sort": {
-    "description": "Default sort order for the member directory",
-    "enum": [
-      "alphabetical",
-      "oldest",
-      "latest"
-    ],
-    "type": "string"
-  },
-  "view": {
-    "description": "Default view layout for the member directory",
-    "enum": [
-      "list",
-      "cards"
-    ],
-    "type": "string"
-  }
-}

removedInput schema / properties / member_directory / type
```
Removed value: -"object"
```
addedInput schema / properties / messaging / $ref
```
Added value: +"#/$defs/messaging"
```

removedInput schema / properties / messaging / properties

Removed value: -{
-  "enabled": {
-    "description": "Whether messaging is enabled for the community (master toggle)",
-    "type": "boolean"
-  },
-  "group_messaging_enabled": {
-    "description": "Whether members can create group chats",
-    "type": "boolean"
-  },
-  "member_to_member_messaging_enabled": {
-    "description": "Whether members can direct message one another",
-    "type": "boolean"
-  },
-  "require_connection_before_messaging": {
-    "description": "Whether members must be connected before they can message each other",
-    "type": "boolean"
-  },
-  "voice_messages_enabled": {
-    "description": "Whether voice messages are enabled in chats",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / messaging / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / connect / $ref
```
Added value: +"#/$defs/connect"
```

removedInput schema / properties / payload / properties / connect / properties

Removed value: -{
-  "enabled": {
-    "description": "Whether the Connect feature is enabled for the community",
-    "type": "boolean"
-  },
-  "exclude_admins_from_recommendations": {
-    "description": "Whether admins are excluded from connection recommendations",
-    "type": "boolean"
-  },
-  "exclude_moderators_from_recommendations": {
-    "description": "Whether moderators are excluded from connection recommendations",
-    "type": "boolean"
-  },
-  "recommendations": {
-    "description": "Whether member-to-member connection recommendations are enabled. Only effective when connect.enabled is true.",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / connect / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / member_directory / $ref
```
Added value: +"#/$defs/member_directory"
```

removedInput schema / properties / payload / properties / member_directory / properties

Removed value: -{
-  "public": {
-    "description": "Whether the member directory is publicly visible",
-    "type": "boolean"
-  },
-  "sort": {
-    "description": "Default sort order for the member directory",
-    "enum": [
-      "alphabetical",
-      "oldest",
-      "latest"
-    ],
-    "type": "string"
-  },
-  "view": {
-    "description": "Default view layout for the member directory",
-    "enum": [
-      "list",
-      "cards"
-    ],
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / member_directory / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / messaging / $ref
```
Added value: +"#/$defs/messaging"
```

removedInput schema / properties / payload / properties / messaging / properties

Removed value: -{
-  "enabled": {
-    "description": "Whether messaging is enabled for the community (master toggle)",
-    "type": "boolean"
-  },
-  "group_messaging_enabled": {
-    "description": "Whether members can create group chats",
-    "type": "boolean"
-  },
-  "member_to_member_messaging_enabled": {
-    "description": "Whether members can direct message one another",
-    "type": "boolean"
-  },
-  "require_connection_before_messaging": {
-    "description": "Whether members must be connected before they can message each other",
-    "type": "boolean"
-  },
-  "voice_messages_enabled": {
-    "description": "Whether voice messages are enabled in chats",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / messaging / type
```
Removed value: -"object"
```

Changedupdate_course_lesson8 fields changed

addedInput schema / $defs

Added value: +{
+  "rich_text_body": {
+    "properties": {
+      "body": {
+        "properties": {
+          "content": {
+            "items": {
+              "properties": {
+                "attrs": {
+                  "type": "object"
+                },
+                "marks": {
+                  "items": {
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "text": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "type": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "content"
+        ],
+        "type": "object"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / payload / properties / rich_text_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / rich_text_body / type
```
Removed value: -"object"
```
addedInput schema / properties / rich_text_body / $ref
```
Added value: +"#/$defs/rich_text_body"
```

removedInput schema / properties / rich_text_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / rich_text_body / type
```
Removed value: -"object"
```

Changedupdate_course_progress1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_course_section1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_event10 fields changed

addedInput schema / $defs

Added value: +{
+  "event": {
+    "properties": {
+      "attendee_invite_attributes": {
+        "properties": {
+          "invited_cohost_ids": {
+            "items": {
+              "type": "integer"
+            },
+            "type": "array"
+          },
+          "invited_entities_ids": {
+            "properties": {
+              "member_tags_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "members_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "space_groups_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              },
+              "spaces_ids": {
+                "items": {
+                  "type": "integer"
+                },
+                "type": "array"
+              }
+            },
+            "type": "object"
+          }
+        },
+        "type": "object"
+      },
+      "body": {
+        "type": "string"
+      },
+      "cover_image": {
+        "description": "signed_id of the cover image",
+        "type": "string"
+      },
+      "event_setting_attributes": {
+        "properties": {
+          "confirmation_message_button_link": {
+            "type": "string"
+          },
+          "confirmation_message_button_title": {
+            "type": "string"
+          },
+          "confirmation_message_description": {
+            "type": "string"
+          },
+          "confirmation_message_title": {
+            "type": "string"
+          },
+          "duration_in_seconds": {
+            "type": "integer"
+          },
+          "enable_custom_thank_you_message": {
+            "type": "boolean"
+          },
+          "hide_attendees": {
+            "type": "boolean"
+          },
+          "hide_location_from_non_attendees": {
+            "type": "boolean"
+          },
+          "host": {
+            "type": "string"
+          },
+          "in_person_location": {
+            "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
+            "type": "string"
+          },
+          "live_stream_room_setting_attributes": {
+            "properties": {
+              "access_type": {
+                "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
+                "enum": [
+                  "open",
+                  "secret",
+                  "public_stream"
+                ],
+                "type": "string"
+              },
+              "auto_post_recording_enabled": {
+                "type": "boolean"
+              },
+              "hide_participants_list": {
+                "type": "boolean"
+              },
+              "limit_url_sharing": {
+                "type": "boolean"
+              },
+              "mute_on_join": {
+                "type": "boolean"
+              },
+              "recording_enabled": {
+                "type": "boolean"
+              },
+              "view_type": {
+                "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
+                "enum": [
+                  "speaker_view",
+                  "speaker_variant_view",
+                  "grid_view"
+                ],
+                "type": "string"
+              }
+            },
+            "type": "object"
+          },
+          "location_type": {
+            "type": "string"
+          },
+          "rsvp_disabled": {
+            "type": "boolean"
+          },
+          "rsvp_limit": {
+            "type": "integer"
+          },
+          "rsvp_limit_enabled": {
+            "type": "boolean"
+          },
+          "send_email_confirmation": {
+            "type": "boolean"
+          },
+          "send_email_reminder": {
+            "type": "boolean"
+          },
+          "send_in_app_notification_confirmation": {
+            "type": "boolean"
+          },
+          "send_in_app_notification_reminder": {
+            "type": "boolean"
+          },
+          "send_publish_email": {
+            "type": "boolean"
+          },
+          "starts_at": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "ticket_type": {
+            "type": "string"
+          },
+          "virtual_location_url": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "event_type": {
+        "type": "string"
+      },
+      "hide_from_featured_areas": {
+        "type": "boolean"
+      },
+      "meta_tag_attributes": {
+        "properties": {
+          "meta_description": {
+            "type": "string"
+          },
+          "meta_title": {
+            "type": "string"
+          },
+          "opengraph_description": {
+            "type": "string"
+          },
+          "opengraph_image": {
+            "type": "string"
+          },
+          "opengraph_title": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "name": {
+        "type": "string"
+      },
+      "paywall_attributes": {
+        "properties": {
+          "currency_id": {
+            "type": "integer"
+          },
+          "description": {
+            "type": "string"
+          },
+          "price_amount": {
+            "type": "number"
+          }
+        },
+        "type": "object"
+      },
+      "recurring_setting_attributes": {
+        "properties": {
+          "edit_mode": {
+            "type": "string"
+          },
+          "ends_at": {
+            "format": "date-time",
+            "type": "string"
+          },
+          "frequency": {
+            "type": "string"
+          },
+          "occurrences": {
+            "type": "integer"
+          }
+        },
+        "type": "object"
+      },
+      "slug": {
+        "type": "string"
+      },
+      "space_id": {
+        "type": "integer"
+      },
+      "status": {
+        "enum": [
+          "draft",
+          "published"
+        ],
+        "type": "string"
+      },
+      "thumbnail_image": {
+        "description": "signed_id of the thumbnail image",
+        "type": "string"
+      },
+      "topics": {
+        "items": {
+          "type": "integer"
+        },
+        "type": "array"
+      },
+      "user_id": {
+        "type": "integer"
+      }
+    },
+    "required": [
+      "name",
+      "space_id",
+      "status"
+    ],
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / event / $ref
```
Added value: +"#/$defs/event"
```

removedInput schema / properties / event / properties

Removed value: -{
-  "attendee_invite_attributes": {
-    "properties": {
-      "invited_cohost_ids": {
-        "items": {
-          "type": "integer"
-        },
-        "type": "array"
-      },
-      "invited_entities_ids": {
-        "properties": {
-          "member_tags_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "members_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "space_groups_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "spaces_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "body": {
-    "type": "string"
-  },
-  "cover_image": {
-    "description": "signed_id of the cover image",
-    "type": "string"
-  },
-  "event_setting_attributes": {
-    "properties": {
-      "confirmation_message_button_link": {
-        "type": "string"
-      },
-      "confirmation_message_button_title": {
-        "type": "string"
-      },
-      "confirmation_message_description": {
-        "type": "string"
-      },
-      "confirmation_message_title": {
-        "type": "string"
-      },
-      "duration_in_seconds": {
-        "type": "integer"
-      },
-      "enable_custom_thank_you_message": {
-        "type": "boolean"
-      },
-      "hide_attendees": {
-        "type": "boolean"
-      },
-      "hide_location_from_non_attendees": {
-        "type": "boolean"
-      },
-      "host": {
-        "type": "string"
-      },
-      "in_person_location": {
-        "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
-        "type": "string"
-      },
-      "live_stream_room_setting_attributes": {
-        "properties": {
-          "access_type": {
-            "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
-            "enum": [
-              "open",
-              "secret",
-              "public_stream"
-            ],
-            "type": "string"
-          },
-          "auto_post_recording_enabled": {
-            "type": "boolean"
-          },
-          "hide_participants_list": {
-            "type": "boolean"
-          },
-          "limit_url_sharing": {
-            "type": "boolean"
-          },
-          "mute_on_join": {
-            "type": "boolean"
-          },
-          "recording_enabled": {
-            "type": "boolean"
-          },
-          "view_type": {
-            "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
-            "enum": [
-              "speaker_view",
-              "speaker_variant_view",
-              "grid_view"
-            ],
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "location_type": {
-        "type": "string"
-      },
-      "rsvp_disabled": {
-        "type": "boolean"
-      },
-      "rsvp_limit": {
-        "type": "integer"
-      },
-      "rsvp_limit_enabled": {
-        "type": "boolean"
-      },
-      "send_email_confirmation": {
-        "type": "boolean"
-      },
-      "send_email_reminder": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_confirmation": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_reminder": {
-        "type": "boolean"
-      },
-      "send_publish_email": {
-        "type": "boolean"
-      },
-      "starts_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "ticket_type": {
-        "type": "string"
-      },
-      "virtual_location_url": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "event_type": {
-    "type": "string"
-  },
-  "hide_from_featured_areas": {
-    "type": "boolean"
-  },
-  "meta_tag_attributes": {
-    "properties": {
-      "meta_description": {
-        "type": "string"
-      },
-      "meta_title": {
-        "type": "string"
-      },
-      "opengraph_description": {
-        "type": "string"
-      },
-      "opengraph_image": {
-        "type": "string"
-      },
-      "opengraph_title": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "name": {
-    "type": "string"
-  },
-  "paywall_attributes": {
-    "properties": {
-      "currency_id": {
-        "type": "integer"
-      },
-      "description": {
-        "type": "string"
-      },
-      "price_amount": {
-        "type": "number"
-      }
-    },
-    "type": "object"
-  },
-  "recurring_setting_attributes": {
-    "properties": {
-      "edit_mode": {
-        "type": "string"
-      },
-      "ends_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "frequency": {
-        "type": "string"
-      },
-      "occurrences": {
-        "type": "integer"
-      }
-    },
-    "type": "object"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "space_id": {
-    "type": "integer"
-  },
-  "status": {
-    "enum": [
-      "draft",
-      "published"
-    ],
-    "type": "string"
-  },
-  "thumbnail_image": {
-    "description": "signed_id of the thumbnail image",
-    "type": "string"
-  },
-  "topics": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "user_id": {
-    "type": "integer"
-  }
-}

removedInput schema / properties / event / required

Removed value: -[
-  "name",
-  "space_id",
-  "status"
-]

removedInput schema / properties / event / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / event / $ref
```
Added value: +"#/$defs/event"
```

removedInput schema / properties / payload / properties / event / properties

Removed value: -{
-  "attendee_invite_attributes": {
-    "properties": {
-      "invited_cohost_ids": {
-        "items": {
-          "type": "integer"
-        },
-        "type": "array"
-      },
-      "invited_entities_ids": {
-        "properties": {
-          "member_tags_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "members_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "space_groups_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          },
-          "spaces_ids": {
-            "items": {
-              "type": "integer"
-            },
-            "type": "array"
-          }
-        },
-        "type": "object"
-      }
-    },
-    "type": "object"
-  },
-  "body": {
-    "type": "string"
-  },
-  "cover_image": {
-    "description": "signed_id of the cover image",
-    "type": "string"
-  },
-  "event_setting_attributes": {
-    "properties": {
-      "confirmation_message_button_link": {
-        "type": "string"
-      },
-      "confirmation_message_button_title": {
-        "type": "string"
-      },
-      "confirmation_message_description": {
-        "type": "string"
-      },
-      "confirmation_message_title": {
-        "type": "string"
-      },
-      "duration_in_seconds": {
-        "type": "integer"
-      },
-      "enable_custom_thank_you_message": {
-        "type": "boolean"
-      },
-      "hide_attendees": {
-        "type": "boolean"
-      },
-      "hide_location_from_non_attendees": {
-        "type": "boolean"
-      },
-      "host": {
-        "type": "string"
-      },
-      "in_person_location": {
-        "description": "A stringified Google Places API result. JSON-serialize the Places API response object before sending. Stored as-is in the database.",
-        "type": "string"
-      },
-      "live_stream_room_setting_attributes": {
-        "properties": {
-          "access_type": {
-            "description": "Access type for the live stream room. 'open' all community members will receive notifications to join, 'secret' invited members will receive notifications to join, 'public_stream' makes the event publicly accessible.",
-            "enum": [
-              "open",
-              "secret",
-              "public_stream"
-            ],
-            "type": "string"
-          },
-          "auto_post_recording_enabled": {
-            "type": "boolean"
-          },
-          "hide_participants_list": {
-            "type": "boolean"
-          },
-          "limit_url_sharing": {
-            "type": "boolean"
-          },
-          "mute_on_join": {
-            "type": "boolean"
-          },
-          "recording_enabled": {
-            "type": "boolean"
-          },
-          "view_type": {
-            "description": "View type for the live stream room. 'speaker_view' shows the speaker view at the top, 'speaker_variant_view' shows the speaker view at the left side, 'grid_view' shows a grid of participants.",
-            "enum": [
-              "speaker_view",
-              "speaker_variant_view",
-              "grid_view"
-            ],
-            "type": "string"
-          }
-        },
-        "type": "object"
-      },
-      "location_type": {
-        "type": "string"
-      },
-      "rsvp_disabled": {
-        "type": "boolean"
-      },
-      "rsvp_limit": {
-        "type": "integer"
-      },
-      "rsvp_limit_enabled": {
-        "type": "boolean"
-      },
-      "send_email_confirmation": {
-        "type": "boolean"
-      },
-      "send_email_reminder": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_confirmation": {
-        "type": "boolean"
-      },
-      "send_in_app_notification_reminder": {
-        "type": "boolean"
-      },
-      "send_publish_email": {
-        "type": "boolean"
-      },
-      "starts_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "ticket_type": {
-        "type": "string"
-      },
-      "virtual_location_url": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "event_type": {
-    "type": "string"
-  },
-  "hide_from_featured_areas": {
-    "type": "boolean"
-  },
-  "meta_tag_attributes": {
-    "properties": {
-      "meta_description": {
-        "type": "string"
-      },
-      "meta_title": {
-        "type": "string"
-      },
-      "opengraph_description": {
-        "type": "string"
-      },
-      "opengraph_image": {
-        "type": "string"
-      },
-      "opengraph_title": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "name": {
-    "type": "string"
-  },
-  "paywall_attributes": {
-    "properties": {
-      "currency_id": {
-        "type": "integer"
-      },
-      "description": {
-        "type": "string"
-      },
-      "price_amount": {
-        "type": "number"
-      }
-    },
-    "type": "object"
-  },
-  "recurring_setting_attributes": {
-    "properties": {
-      "edit_mode": {
-        "type": "string"
-      },
-      "ends_at": {
-        "format": "date-time",
-        "type": "string"
-      },
-      "frequency": {
-        "type": "string"
-      },
-      "occurrences": {
-        "type": "integer"
-      }
-    },
-    "type": "object"
-  },
-  "slug": {
-    "type": "string"
-  },
-  "space_id": {
-    "type": "integer"
-  },
-  "status": {
-    "enum": [
-      "draft",
-      "published"
-    ],
-    "type": "string"
-  },
-  "thumbnail_image": {
-    "description": "signed_id of the thumbnail image",
-    "type": "string"
-  },
-  "topics": {
-    "items": {
-      "type": "integer"
-    },
-    "type": "array"
-  },
-  "user_id": {
-    "type": "integer"
-  }
-}

removedInput schema / properties / payload / properties / event / required
```
Removed value: -[
-  "name",
-  "space_id",
-  "status"
-]
```
removedInput schema / properties / payload / properties / event / type
```
Removed value: -"object"
```

Changedupdate_filter_control1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_form20 fields changed

addedInput schema / $defs

Added value: +{
+  "elements": {
+    "items": {
+      "properties": {
+        "attributes": {
+          "description": "Element-specific attributes. Structure varies by element type.",
+          "type": "object"
+        },
+        "children": {
+          "description": "Child elements nested within this element. Each child follows the same structure as a form_element and can be nested recursively.",
+          "items": {
+            "type": "object"
+          },
+          "type": "array"
+        },
+        "id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "parent_element_id": {
+          "type": [
+            "integer",
+            "null"
+          ]
+        },
+        "position": {
+          "type": "integer"
+        },
+        "type": {
+          "enum": [
+            "text",
+            "field",
+            "button",
+            "layout"
+          ],
+          "type": "string"
+        }
+      },
+      "type": "object"
+    },
+    "type": "array"
+  },
+  "embed_styles": {
+    "properties": {
+      "button": {
+        "properties": {
+          "backgroundColor": {
+            "type": "string"
+          },
+          "color": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "form": {
+        "properties": {
+          "backgroundColor": {
+            "type": "string"
+          },
+          "color": {
+            "type": "string"
+          }
+        },
+        "type": "object"
+      }
+    },
+    "type": [
+      "object",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / elements / $ref
```
Added value: +"#/$defs/elements"
```

removedInput schema / properties / elements / items

Removed value: -{
-  "properties": {
-    "attributes": {
-      "description": "Element-specific attributes. Structure varies by element type.",
-      "type": "object"
-    },
-    "children": {
-      "description": "Child elements nested within this element. Each child follows the same structure as a form_element and can be nested recursively.",
-      "items": {
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "parent_element_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "position": {
-      "type": "integer"
-    },
-    "type": {
-      "enum": [
-        "text",
-        "field",
-        "button",
-        "layout"
-      ],
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

removedInput schema / properties / elements / type
```
Removed value: -"array"
```
addedInput schema / properties / embed_styles / $ref
```
Added value: +"#/$defs/embed_styles"
```

removedInput schema / properties / embed_styles / properties

Removed value: -{
-  "button": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "form": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-}

removedInput schema / properties / embed_styles / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / payload / properties / elements / $ref
```
Added value: +"#/$defs/elements"
```

removedInput schema / properties / payload / properties / elements / items

Removed value: -{
-  "properties": {
-    "attributes": {
-      "description": "Element-specific attributes. Structure varies by element type.",
-      "type": "object"
-    },
-    "children": {
-      "description": "Child elements nested within this element. Each child follows the same structure as a form_element and can be nested recursively.",
-      "items": {
-        "type": "object"
-      },
-      "type": "array"
-    },
-    "id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "parent_element_id": {
-      "type": [
-        "integer",
-        "null"
-      ]
-    },
-    "position": {
-      "type": "integer"
-    },
-    "type": {
-      "enum": [
-        "text",
-        "field",
-        "button",
-        "layout"
-      ],
-      "type": "string"
-    }
-  },
-  "type": "object"
-}

removedInput schema / properties / payload / properties / elements / type
```
Removed value: -"array"
```
addedInput schema / properties / payload / properties / embed_styles / $ref
```
Added value: +"#/$defs/embed_styles"
```

removedInput schema / properties / payload / properties / embed_styles / properties

Removed value: -{
-  "button": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "form": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / embed_styles / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / payload / properties / standalone_page_styles / $ref
```
Added value: +"#/$defs/embed_styles"
```

removedInput schema / properties / payload / properties / standalone_page_styles / properties

Removed value: -{
-  "button": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "form": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / standalone_page_styles / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / standalone_page_styles / $ref
```
Added value: +"#/$defs/embed_styles"
```

removedInput schema / properties / standalone_page_styles / properties

Removed value: -{
-  "button": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "form": {
-    "properties": {
-      "backgroundColor": {
-        "type": "string"
-      },
-      "color": {
-        "type": "string"
-      }
-    },
-    "type": "object"
-  }
-}

removedInput schema / properties / standalone_page_styles / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

Changedupdate_invitation_link10 fields changed

addedInput schema / $defs

Added value: +{
+  "paywall": {
+    "description": "Paywall configuration. Set to null to remove the existing paywall configuration",
+    "properties": {
+      "paywall_coupon_code": {
+        "description": "Optional coupon code for the paywall trial",
+        "type": "string"
+      },
+      "paywall_id": {
+        "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
+        "type": "integer"
+      },
+      "paywall_price_id": {
+        "description": "Eligible recurring paywall price ID",
+        "type": "integer"
+      },
+      "paywall_trial_days": {
+        "description": "Free trial length in days",
+        "maximum": 730,
+        "minimum": 1,
+        "type": "integer"
+      }
+    },
+    "type": [
+      "object",
+      "null"
+    ]
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / paywall / $ref
```
Added value: +"#/$defs/paywall"
```

removedInput schema / properties / payload / properties / paywall / description

Removed value: -"Paywall configuration. Set to null to remove the existing paywall configuration"

removedInput schema / properties / payload / properties / paywall / properties

Removed value: -{
-  "paywall_coupon_code": {
-    "description": "Optional coupon code for the paywall trial",
-    "type": "string"
-  },
-  "paywall_id": {
-    "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
-    "type": "integer"
-  },
-  "paywall_price_id": {
-    "description": "Eligible recurring paywall price ID",
-    "type": "integer"
-  },
-  "paywall_trial_days": {
-    "description": "Free trial length in days",
-    "maximum": 730,
-    "minimum": 1,
-    "type": "integer"
-  }
-}

removedInput schema / properties / payload / properties / paywall / type
```
Removed value: -[
-  "object",
-  "null"
-]
```
addedInput schema / properties / paywall / $ref
```
Added value: +"#/$defs/paywall"
```

removedInput schema / properties / paywall / description

Removed value: -"Paywall configuration. Set to null to remove the existing paywall configuration"

removedInput schema / properties / paywall / properties

Removed value: -{
-  "paywall_coupon_code": {
-    "description": "Optional coupon code for the paywall trial",
-    "type": "string"
-  },
-  "paywall_id": {
-    "description": "Paywall ID; requires paywall_price_id and paywall_trial_days",
-    "type": "integer"
-  },
-  "paywall_price_id": {
-    "description": "Eligible recurring paywall price ID",
-    "type": "integer"
-  },
-  "paywall_trial_days": {
-    "description": "Free trial length in days",
-    "maximum": 730,
-    "minimum": 1,
-    "type": "integer"
-  }
-}

removedInput schema / properties / paywall / type
```
Removed value: -[
-  "object",
-  "null"
-]
```

Changedupdate_member8 fields changed

addedInput schema / $defs

Added value: +{
+  "preferences": {
+    "properties": {
+      "make_my_email_public": {
+        "type": "boolean"
+      },
+      "messaging_enabled": {
+        "type": "boolean"
+      },
+      "messaging_enabled_by_admin": {
+        "type": "boolean"
+      },
+      "visible_in_member_directory": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / preferences / $ref
```
Added value: +"#/$defs/preferences"
```

removedInput schema / properties / payload / properties / preferences / properties

Removed value: -{
-  "make_my_email_public": {
-    "type": "boolean"
-  },
-  "messaging_enabled": {
-    "type": "boolean"
-  },
-  "messaging_enabled_by_admin": {
-    "type": "boolean"
-  },
-  "visible_in_member_directory": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / preferences / type
```
Removed value: -"object"
```
addedInput schema / properties / preferences / $ref
```
Added value: +"#/$defs/preferences"
```

removedInput schema / properties / preferences / properties

Removed value: -{
-  "make_my_email_public": {
-    "type": "boolean"
-  },
-  "messaging_enabled": {
-    "type": "boolean"
-  },
-  "messaging_enabled_by_admin": {
-    "type": "boolean"
-  },
-  "visible_in_member_directory": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / preferences / type
```
Removed value: -"object"
```

Changedupdate_member_tag1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_paywall_affiliate1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_paywall_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_post10 fields changed

addedInput schema / $defs

Added value: +{
+  "tiptap_body": {
+    "description": "The Tiptap body will be updated only for posts that already contain a Tiptap body. If the post does not have a Tiptap body, the tiptap_body will be ignored.",
+    "properties": {
+      "body": {
+        "properties": {
+          "content": {
+            "items": {
+              "properties": {
+                "attrs": {
+                  "type": "object"
+                },
+                "marks": {
+                  "items": {
+                    "type": "object"
+                  },
+                  "type": "array"
+                },
+                "text": {
+                  "type": [
+                    "string",
+                    "null"
+                  ]
+                },
+                "type": {
+                  "type": "string"
+                }
+              },
+              "type": "object"
+            },
+            "type": "array"
+          },
+          "type": {
+            "type": "string"
+          }
+        },
+        "required": [
+          "type",
+          "content"
+        ],
+        "type": "object"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / tiptap_body / $ref
```
Added value: +"#/$defs/tiptap_body"
```

removedInput schema / properties / payload / properties / tiptap_body / description

Removed value: -"The Tiptap body will be updated only for posts that already contain a Tiptap body. If the post does not have a Tiptap body, the tiptap_body will be ignored."

removedInput schema / properties / payload / properties / tiptap_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / payload / properties / tiptap_body / type
```
Removed value: -"object"
```
addedInput schema / properties / tiptap_body / $ref
```
Added value: +"#/$defs/tiptap_body"
```

removedInput schema / properties / tiptap_body / description

Removed value: -"The Tiptap body will be updated only for posts that already contain a Tiptap body. If the post does not have a Tiptap body, the tiptap_body will be ignored."

removedInput schema / properties / tiptap_body / properties

Removed value: -{
-  "body": {
-    "properties": {
-      "content": {
-        "items": {
-          "properties": {
-            "attrs": {
-              "type": "object"
-            },
-            "marks": {
-              "items": {
-                "type": "object"
-              },
-              "type": "array"
-            },
-            "text": {
-              "type": [
-                "string",
-                "null"
-              ]
-            },
-            "type": {
-              "type": "string"
-            }
-          },
-          "type": "object"
-        },
-        "type": "array"
-      },
-      "type": {
-        "type": "string"
-      }
-    },
-    "required": [
-      "type",
-      "content"
-    ],
-    "type": "object"
-  }
-}

removedInput schema / properties / tiptap_body / type
```
Removed value: -"object"
```

Changedupdate_profile_field8 fields changed

addedInput schema / $defs

Added value: +{
+  "profile_field": {
+    "properties": {
+      "allow_null": {
+        "description": "Whether the field may be left empty",
+        "type": "boolean"
+      },
+      "choices_attributes": {
+        "description": "Option changes for a select or checkbox field. Omit id to add an option, send _destroy to remove one",
+        "items": {
+          "properties": {
+            "_destroy": {
+              "description": "Set to true to delete this choice and every member's selection of it",
+              "type": "boolean"
+            },
+            "id": {
+              "description": "Id of an existing choice. Omit to add a new one",
+              "type": "integer"
+            },
+            "sort_key": {
+              "description": "Position of the option, ascending",
+              "type": "integer"
+            },
+            "value": {
+              "description": "Option label",
+              "type": "string"
+            }
+          },
+          "type": "object"
+        },
+        "maxItems": 50,
+        "type": "array"
+      },
+      "description": {
+        "description": "Help text shown to members",
+        "type": "string"
+      },
+      "key": {
+        "description": "Unique identifier for the field within the community. Cannot be changed on a platform field",
+        "maxLength": 100,
+        "minLength": 1,
+        "pattern": "^[a-z0-9_]+$",
+        "type": "string"
+      },
+      "label": {
+        "description": "Field label shown to members",
+        "maxLength": 255,
+        "minLength": 1,
+        "type": "string"
+      },
+      "number_options_attributes": {
+        "description": "Formatting changes for a number field",
+        "properties": {
+          "decimal": {
+            "description": "Number of decimal places",
+            "minimum": 0,
+            "type": "integer"
+          },
+          "format": {
+            "description": "How the number is formatted",
+            "enum": [
+              "number",
+              "percentage",
+              "custom",
+              "unformatted"
+            ],
+            "type": "string"
+          },
+          "id": {
+            "description": "Id of the number options belonging to this profile field",
+            "type": "integer"
+          },
+          "position": {
+            "description": "Which side of the number the custom text sits on",
+            "enum": [
+              "left",
+              "right"
+            ],
+            "type": "string"
+          },
+          "text": {
+            "description": "Custom text shown alongside the number. Required when format is custom",
+            "type": "string"
+          }
+        },
+        "type": "object"
+      },
+      "pages_attributes": {
+        "description": "Visibility changes, addressed by page id",
+        "items": {
+          "properties": {
+            "id": {
+              "description": "Id of a page belonging to this profile field",
+              "type": "integer"
+            },
+            "visible": {
+              "description": "Whether the field is visible on this page",
+              "type": "boolean"
+            }
+          },
+          "required": [
+            "id",
+            "visible"
+          ],
+          "type": "object"
+        },
+        "type": "array"
+      },
+      "placeholder": {
+        "description": "Placeholder text. Only meaningful for text, textarea and link fields",
+        "type": "string"
+      },
+      "required": {
+        "description": "Whether members must fill the field in",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / payload / properties / profile_field / $ref
```
Added value: +"#/$defs/profile_field"
```

removedInput schema / properties / payload / properties / profile_field / properties

Removed value: -{
-  "allow_null": {
-    "description": "Whether the field may be left empty",
-    "type": "boolean"
-  },
-  "choices_attributes": {
-    "description": "Option changes for a select or checkbox field. Omit id to add an option, send _destroy to remove one",
-    "items": {
-      "properties": {
-        "_destroy": {
-          "description": "Set to true to delete this choice and every member's selection of it",
-          "type": "boolean"
-        },
-        "id": {
-          "description": "Id of an existing choice. Omit to add a new one",
-          "type": "integer"
-        },
-        "sort_key": {
-          "description": "Position of the option, ascending",
-          "type": "integer"
-        },
-        "value": {
-          "description": "Option label",
-          "type": "string"
-        }
-      },
-      "type": "object"
-    },
-    "maxItems": 50,
-    "type": "array"
-  },
-  "description": {
-    "description": "Help text shown to members",
-    "type": "string"
-  },
-  "key": {
-    "description": "Unique identifier for the field within the community. Cannot be changed on a platform field",
-    "maxLength": 100,
-    "minLength": 1,
-    "pattern": "^[a-z0-9_]+$",
-    "type": "string"
-  },
-  "label": {
-    "description": "Field label shown to members",
-    "maxLength": 255,
-    "minLength": 1,
-    "type": "string"
-  },
-  "number_options_attributes": {
-    "description": "Formatting changes for a number field",
-    "properties": {
-      "decimal": {
-        "description": "Number of decimal places",
-        "minimum": 0,
-        "type": "integer"
-      },
-      "format": {
-        "description": "How the number is formatted",
-        "enum": [
-          "number",
-          "percentage",
-          "custom",
-          "unformatted"
-        ],
-        "type": "string"
-      },
-      "id": {
-        "description": "Id of the number options belonging to this profile field",
-        "type": "integer"
-      },
-      "position": {
-        "description": "Which side of the number the custom text sits on",
-        "enum": [
-          "left",
-          "right"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "description": "Custom text shown alongside the number. Required when format is custom",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "pages_attributes": {
-    "description": "Visibility changes, addressed by page id",
-    "items": {
-      "properties": {
-        "id": {
-          "description": "Id of a page belonging to this profile field",
-          "type": "integer"
-        },
-        "visible": {
-          "description": "Whether the field is visible on this page",
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "id",
-        "visible"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "placeholder": {
-    "description": "Placeholder text. Only meaningful for text, textarea and link fields",
-    "type": "string"
-  },
-  "required": {
-    "description": "Whether members must fill the field in",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / profile_field / type
```
Removed value: -"object"
```
addedInput schema / properties / profile_field / $ref
```
Added value: +"#/$defs/profile_field"
```

removedInput schema / properties / profile_field / properties

Removed value: -{
-  "allow_null": {
-    "description": "Whether the field may be left empty",
-    "type": "boolean"
-  },
-  "choices_attributes": {
-    "description": "Option changes for a select or checkbox field. Omit id to add an option, send _destroy to remove one",
-    "items": {
-      "properties": {
-        "_destroy": {
-          "description": "Set to true to delete this choice and every member's selection of it",
-          "type": "boolean"
-        },
-        "id": {
-          "description": "Id of an existing choice. Omit to add a new one",
-          "type": "integer"
-        },
-        "sort_key": {
-          "description": "Position of the option, ascending",
-          "type": "integer"
-        },
-        "value": {
-          "description": "Option label",
-          "type": "string"
-        }
-      },
-      "type": "object"
-    },
-    "maxItems": 50,
-    "type": "array"
-  },
-  "description": {
-    "description": "Help text shown to members",
-    "type": "string"
-  },
-  "key": {
-    "description": "Unique identifier for the field within the community. Cannot be changed on a platform field",
-    "maxLength": 100,
-    "minLength": 1,
-    "pattern": "^[a-z0-9_]+$",
-    "type": "string"
-  },
-  "label": {
-    "description": "Field label shown to members",
-    "maxLength": 255,
-    "minLength": 1,
-    "type": "string"
-  },
-  "number_options_attributes": {
-    "description": "Formatting changes for a number field",
-    "properties": {
-      "decimal": {
-        "description": "Number of decimal places",
-        "minimum": 0,
-        "type": "integer"
-      },
-      "format": {
-        "description": "How the number is formatted",
-        "enum": [
-          "number",
-          "percentage",
-          "custom",
-          "unformatted"
-        ],
-        "type": "string"
-      },
-      "id": {
-        "description": "Id of the number options belonging to this profile field",
-        "type": "integer"
-      },
-      "position": {
-        "description": "Which side of the number the custom text sits on",
-        "enum": [
-          "left",
-          "right"
-        ],
-        "type": "string"
-      },
-      "text": {
-        "description": "Custom text shown alongside the number. Required when format is custom",
-        "type": "string"
-      }
-    },
-    "type": "object"
-  },
-  "pages_attributes": {
-    "description": "Visibility changes, addressed by page id",
-    "items": {
-      "properties": {
-        "id": {
-          "description": "Id of a page belonging to this profile field",
-          "type": "integer"
-        },
-        "visible": {
-          "description": "Whether the field is visible on this page",
-          "type": "boolean"
-        }
-      },
-      "required": [
-        "id",
-        "visible"
-      ],
-      "type": "object"
-    },
-    "type": "array"
-  },
-  "placeholder": {
-    "description": "Placeholder text. Only meaningful for text, textarea and link fields",
-    "type": "string"
-  },
-  "required": {
-    "description": "Whether members must fill the field in",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / profile_field / type
```
Removed value: -"object"
```

Changedupdate_space26 fields changed

addedInput schema / $defs

Added value: +{
+  "course_setting_attributes": {
+    "description": "Course space configuration",
+    "properties": {
+      "course_type": {
+        "enum": [
+          "self_paced",
+          "scheduled",
+          "structured"
+        ],
+        "type": "string"
+      },
+      "custom_lesson_label": {
+        "enum": [
+          "activity",
+          "assignment",
+          "challenge",
+          "class",
+          "day",
+          "exercise",
+          "lecture",
+          "lesson",
+          "practice",
+          "session",
+          "topic",
+          "tutorial",
+          "workshop"
+        ],
+        "type": "string"
+      },
+      "custom_section_label": {
+        "enum": [
+          "chapter",
+          "level",
+          "module",
+          "part",
+          "path",
+          "phase",
+          "section",
+          "stage",
+          "track",
+          "unit",
+          "week"
+        ],
+        "type": "string"
+      },
+      "enforce_lessons_order": {
+        "type": "boolean"
+      },
+      "lesson_thumbnails_visible": {
+        "type": "boolean"
+      },
+      "new_comment_notification_enabled": {
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  },
+  "meta_tag_attributes": {
+    "description": "SEO meta tag attributes",
+    "properties": {
+      "meta_description": {
+        "type": "string"
+      },
+      "meta_title": {
+        "type": "string"
+      },
+      "opengraph_description": {
+        "type": "string"
+      },
+      "opengraph_image": {
+        "type": "string"
+      },
+      "opengraph_title": {
+        "type": "string"
+      }
+    },
+    "type": "object"
+  },
+  "visible_tabs": {
+    "description": "Visible tabs configuration for the space",
+    "properties": {
+      "members": {
+        "description": "Show members tab",
+        "type": "boolean"
+      },
+      "past": {
+        "description": "Show past events tab",
+        "type": "boolean"
+      },
+      "posts": {
+        "description": "Show posts tab",
+        "type": "boolean"
+      },
+      "upcoming": {
+        "description": "Show upcoming events tab",
+        "type": "boolean"
+      }
+    },
+    "type": "object"
+  }
+}

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

addedInput schema / properties / course_setting_attributes / $ref
```
Added value: +"#/$defs/course_setting_attributes"
```
removedInput schema / properties / course_setting_attributes / description
```
Removed value: -"Course space configuration"
```

removedInput schema / properties / course_setting_attributes / properties

Removed value: -{
-  "course_type": {
-    "enum": [
-      "self_paced",
-      "scheduled",
-      "structured"
-    ],
-    "type": "string"
-  },
-  "custom_lesson_label": {
-    "enum": [
-      "activity",
-      "assignment",
-      "challenge",
-      "class",
-      "day",
-      "exercise",
-      "lecture",
-      "lesson",
-      "practice",
-      "session",
-      "topic",
-      "tutorial",
-      "workshop"
-    ],
-    "type": "string"
-  },
-  "custom_section_label": {
-    "enum": [
-      "chapter",
-      "level",
-      "module",
-      "part",
-      "path",
-      "phase",
-      "section",
-      "stage",
-      "track",
-      "unit",
-      "week"
-    ],
-    "type": "string"
-  },
-  "enforce_lessons_order": {
-    "type": "boolean"
-  },
-  "lesson_thumbnails_visible": {
-    "type": "boolean"
-  },
-  "new_comment_notification_enabled": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / course_setting_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / meta_tag_attributes / $ref
```
Added value: +"#/$defs/meta_tag_attributes"
```
removedInput schema / properties / meta_tag_attributes / description
```
Removed value: -"SEO meta tag attributes"
```

removedInput schema / properties / meta_tag_attributes / properties

Removed value: -{
-  "meta_description": {
-    "type": "string"
-  },
-  "meta_title": {
-    "type": "string"
-  },
-  "opengraph_description": {
-    "type": "string"
-  },
-  "opengraph_image": {
-    "type": "string"
-  },
-  "opengraph_title": {
-    "type": "string"
-  }
-}

removedInput schema / properties / meta_tag_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / course_setting_attributes / $ref
```
Added value: +"#/$defs/course_setting_attributes"
```
removedInput schema / properties / payload / properties / course_setting_attributes / description
```
Removed value: -"Course space configuration"
```

removedInput schema / properties / payload / properties / course_setting_attributes / properties

Removed value: -{
-  "course_type": {
-    "enum": [
-      "self_paced",
-      "scheduled",
-      "structured"
-    ],
-    "type": "string"
-  },
-  "custom_lesson_label": {
-    "enum": [
-      "activity",
-      "assignment",
-      "challenge",
-      "class",
-      "day",
-      "exercise",
-      "lecture",
-      "lesson",
-      "practice",
-      "session",
-      "topic",
-      "tutorial",
-      "workshop"
-    ],
-    "type": "string"
-  },
-  "custom_section_label": {
-    "enum": [
-      "chapter",
-      "level",
-      "module",
-      "part",
-      "path",
-      "phase",
-      "section",
-      "stage",
-      "track",
-      "unit",
-      "week"
-    ],
-    "type": "string"
-  },
-  "enforce_lessons_order": {
-    "type": "boolean"
-  },
-  "lesson_thumbnails_visible": {
-    "type": "boolean"
-  },
-  "new_comment_notification_enabled": {
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / course_setting_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / meta_tag_attributes / $ref
```
Added value: +"#/$defs/meta_tag_attributes"
```
removedInput schema / properties / payload / properties / meta_tag_attributes / description
```
Removed value: -"SEO meta tag attributes"
```

removedInput schema / properties / payload / properties / meta_tag_attributes / properties

Removed value: -{
-  "meta_description": {
-    "type": "string"
-  },
-  "meta_title": {
-    "type": "string"
-  },
-  "opengraph_description": {
-    "type": "string"
-  },
-  "opengraph_image": {
-    "type": "string"
-  },
-  "opengraph_title": {
-    "type": "string"
-  }
-}

removedInput schema / properties / payload / properties / meta_tag_attributes / type
```
Removed value: -"object"
```
addedInput schema / properties / payload / properties / visible_tabs / $ref
```
Added value: +"#/$defs/visible_tabs"
```
removedInput schema / properties / payload / properties / visible_tabs / description
```
Removed value: -"Visible tabs configuration for the space"
```

removedInput schema / properties / payload / properties / visible_tabs / properties

Removed value: -{
-  "members": {
-    "description": "Show members tab",
-    "type": "boolean"
-  },
-  "past": {
-    "description": "Show past events tab",
-    "type": "boolean"
-  },
-  "posts": {
-    "description": "Show posts tab",
-    "type": "boolean"
-  },
-  "upcoming": {
-    "description": "Show upcoming events tab",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / payload / properties / visible_tabs / type
```
Removed value: -"object"
```
addedInput schema / properties / visible_tabs / $ref
```
Added value: +"#/$defs/visible_tabs"
```

removedInput schema / properties / visible_tabs / description

Removed value: -"Visible tabs configuration for the space"

removedInput schema / properties / visible_tabs / properties

Removed value: -{
-  "members": {
-    "description": "Show members tab",
-    "type": "boolean"
-  },
-  "past": {
-    "description": "Show past events tab",
-    "type": "boolean"
-  },
-  "posts": {
-    "description": "Show posts tab",
-    "type": "boolean"
-  },
-  "upcoming": {
-    "description": "Show upcoming events tab",
-    "type": "boolean"
-  }
-}

removedInput schema / properties / visible_tabs / type
```
Removed value: -"object"
```

Changedupdate_space_group1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_tax_settings1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

Changedupdate_topic1 field changed

changedInput schema / properties / confirm / description

Previous value: -"Must be true for the specific user-requested write."New value: +"Set true only when the user asked for exactly this action."

170 tool updatesv2.0.0Oct 2, 2026
- First observedactivate_workflow
- First observedadd_space_member
- First observedadd_to_access_group
- First observedarchive_access_group
- First observedarchive_paywall
- First observedarchive_profile_field
- First observedban_community_member
- First observedcancel_community_member_subscription
- First observedcreate_access_group
- First observedcreate_comment
- First observedcreate_community_segment
- First observedcreate_contact_note
- First observedcreate_course_lesson
- First observedcreate_course_section
- First observedcreate_direct_upload
- First observedcreate_embed
- First observedcreate_event
- First observedcreate_event_attendee
- First observedcreate_filter_control
- First observedcreate_form_submission
- First observedcreate_image_post
- First observedcreate_invitation
- First observedcreate_lead
- First observedcreate_member
- First observedcreate_member_tag
- First observedcreate_paywall_group
- First observedcreate_post
- First observedcreate_profile_field
- First observedcreate_space
- First observedcreate_space_group
- First observedcreate_space_group_member
- First observedcreate_topic
- First observeddeactivate_workflow
- First observeddelete_comment
- First observeddelete_community_member
- First observeddelete_community_segment
- First observeddelete_course_lesson
- First observeddelete_course_section
- First observeddelete_event
- First observeddelete_event_attendee
- First observeddelete_filter_control
- First observeddelete_form
- First observeddelete_image_post
- First observeddelete_invitation_link
- First observeddelete_lead
- First observeddelete_member_tag
- First observeddelete_paywall
- First observeddelete_paywall_coupon
- First observeddelete_post
- First observeddelete_profile_field
- First observeddelete_space
- First observeddelete_space_group
- First observeddelete_space_group_member
- First observeddelete_topic
- First observedduplicate_community_segment
- First observedduplicate_event
- First observedduplicate_form
- First observedduplicate_image_post
- First observedduplicate_workflow
- First observedexport_community_member_charges
- First observedexport_community_member_subscriptions
- First observedexport_paywall_affiliate_payouts
- First observedget_access_group_community_member
- First observedget_comment
- First observedget_community
- First observedget_connect_settings
- First observedget_course_lesson
- First observedget_course_section
- First observedget_embed
- First observedget_event
- First observedget_filter_configuration
- First observedget_filter_control
- First observedget_form
- First observedget_form_submissions
- First observedget_image_post
- First observedget_leaderboard
- First observedget_member
- First observedget_member_tag
- First observedget_payment_method_settings
- First observedget_post
- First observedget_post_summary
- First observedget_space
- First observedget_space_ai_summaries
- First observedget_space_group
- First observedget_space_group_member
- First observedget_space_member
- First observedget_tagged_member
- First observedget_tax_settings
- First observedget_topic
- First observedget_workflow
- First observedimport_chat_room_message
- First observedinvite_paywall_affiliates
- First observedlist_access_group_community_members
- First observedlist_access_groups
- First observedlist_accounts
- First observedlist_charges
- First observedlist_comments
- First observedlist_contact_notes
- First observedlist_course_lessons
- First observedlist_course_sections
- First observedlist_event_attendees
- First observedlist_events
- First observedlist_filter_controls
- First observedlist_flagged_content
- First observedlist_forms
- First observedlist_image_posts
- First observedlist_invitations
- First observedlist_live_room_transcripts
- First observedlist_live_rooms
- First observedlist_member_access_groups
- First observedlist_member_spaces
- First observedlist_member_tags
- First observedlist_members
- First observedlist_page_profile_fields
- First observedlist_paywall_affiliates
- First observedlist_posts
- First observedlist_profile_fields
- First observedlist_segments
- First observedlist_space_group_members
- First observedlist_space_groups
- First observedlist_space_members
- First observedlist_spaces
- First observedlist_subscriptions
- First observedlist_tagged_members
- First observedlist_topics
- First observedlist_workflows
- First observedmark_paywall_affiliate_payouts_paid
- First observedpublish_paywall
- First observedrefund_community_member_charge
- First observedremove_from_access_group
- First observedremove_member
- First observedremove_space_member
- First observedreorder_course_lessons
- First observedreport_flagged_content
- First observedresume_community_member_subscription
- First observedrevoke_invitation_link
- First observedsearch
- First observedsearch_locations
- First observedsearch_member
- First observedsearch_paywalls
- First observedsend_message
- First observedstart_paywall_affiliate_payouts
- First observedtag_member
- First observedunarchive_access_group
- First observedunarchive_paywall
- First observedunarchive_profile_field
- First observedunfollow_post
- First observeduntag_member
- First observedupdate_access_group
- First observedupdate_chat_preferences
- First observedupdate_community
- First observedupdate_community_segment
- First observedupdate_connect_settings
- First observedupdate_course_lesson
- First observedupdate_course_progress
- First observedupdate_course_section
- First observedupdate_event
- First observedupdate_filter_control
- First observedupdate_form
- First observedupdate_invitation_link
- First observedupdate_member
- First observedupdate_member_tag
- First observedupdate_paywall_affiliate
- First observedupdate_paywall_group
- First observedupdate_post
- First observedupdate_profile_field
- First observedupdate_space
- First observedupdate_space_group
- First observedupdate_tax_settings
- First observedupdate_topic

Deploy Server

One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

C2.6/5.0

Scored 2026-10-07 14:50 across 170 tools

Disambiguation3/5

Many tools map to distinct resources, but the member-management surface is crowded with overlapping actions (create_member, create_lead, remove_member, delete_community_member, ban_community_member), and post tools (create_post, create_image_post, get_post, get_post_summary) require careful reading. With 170 tools, several boundaries are ambiguous enough that an agent could easily misselect.

Naming Consistency4/5

The set overwhelmingly follows a predictable snake_case verb_noun pattern (list_*, get_*, create_*, update_*, delete_*). Minor deviations like send_message, add_space_member, remove_space_member, tag_member, and untag_member are still readable and resource-specific.

Tool Count1/5

170 tools is an extreme mismatch for a coherent MCP surface, far beyond the recommended 3-15 range and even beyond the 50+ threshold that indicates poor scoping. The sheer volume overwhelms discovery and selection.

Completeness2/5

The domain is broad, but obvious lifecycle gaps exist: no create_workflow or update_workflow, no create_paywall, no update_image_post, and live rooms/transcripts are read-only. These missing operations would cause agent dead ends despite the large tool count.

Maintenance

ActivityMaintained

ResponsivenessNo issues

Resources

Need Help?

Related Servers

Related MCP Connectors

CrackedOAuth
io.github.systemsailab
Discover, inspect and run 63,000+ agent tools from one balance. Pay per call, no subscriptions.
Autonomous Agents
1
Carbon VoiceOAuth
app.carbonvoice.mcp
Carbon Voice MCP serves as a bridge that connects AI assistants like ChatGPT, Claude, and Cursor to a user's Carbon Voice account, turning voice messages and conversations into a private, on-demand knowledge base. It provides 28 specialized tools for comprehensive voice messaging management, including creating and sending messages, accessing conversation history with instant transcription, running AI actions (summarization, TLDR generation, meeting notes), and managing workspace collaboration through folders, contacts, and team communications.
Communication Knowledge & Memory Text Summarization
2
mcp-serverOAuth
com.make
Give your AI agents the tools to build, manage, and run automation workflows.
App Automation Developer Tools Workplace & Productivity
2
FreeToolBoxes Agent Tools A
io.github.DAMediaCo
Exactly 50 data transformation and live web verification tools for AI agents.
Data Platforms Browser Automation
1

Related MCP Servers

FluentCommunity Manager
Content Management Systems App Automation Developer Tools
wplaunchify
A
license
B
quality
D
maintenance
AI-powered management of FluentCommunity WordPress plugin content. Enables creating, updating, and managing community posts, spaces, comments, members, and chat through 26+ tools with bulk operations and advanced search capabilities.
Updated a year ago (2025-11-19 05:09 UTC)
26
9 npm
5
MIT
Omnicord - Discord server
App Automation Communication Monitoring
OrygnsCode
A
license
B
quality
A
maintenance
Gives your AI assistant full control of a Discord server: 148 tools for chat, moderation, automod, events, and administration, up to building a complete community server from one paragraph. Every destructive action previews first and waits for your confirmation.
Updated 7 days ago (2026-10-01 14:09 UTC)
155
70 npm
8
Elastic 2.0
Circle MCP Server
Communication Social Media
AnantBisht07
A
license
Not graded
quality
D
maintenance
Enables AI assistants to interact with Circle.so communities through Google OAuth 2.0, providing 20+ tools for comprehensive community management.
Updated 9 months ago (2026-01-13 07:47 UTC)
15 npm
MIT
intercom-mcp-server
Customer Support Communication
OtakuXavier
A
license
Not graded
quality
D
maintenance
Enables interaction with Intercom's customer communications platform via the Intercom REST API, providing 102 tools for managing admins, articles, companies, contacts, conversations, and more.
Updated 4 months ago (2026-06-22 07:22 UTC)
2
MIT