Skip to main content
Glama
thenavidm

Fluent WordPress MCP Server

by thenavidm

Fluent WordPress MCP Server & CLI

npm CI License YouTube X LinkedIn

Fluent WordPress MCP server and CLI for Codex and AI agents. 54 shared tools for current FluentCRM, FluentCommunity and Fluent Forms, isolated private sites, reviewed cross-plugin tasks and bounded snapshots.

One package provides a task CLI, local stdio MCP and versioned desktop bundle. Built and maintained by Navid Moazzez. Built on Slipway, which turns one definition of each tool into the MCP server and the CLI. Complete setup: navid.me.

The terminal illustrates actual commands, not a recorded provider account session. Node 22+ is required for manual installs; private WordPress authentication, installed plugin versions and native user permissions remain separate.

Two ways to use it

Command line

A shell or terminal agent runs only the requested task through the shared handlers.

npx -y --package @thenavidm/fluent-wp-mcp-cli@latest fluent-wp-cli list-accounts --agent

MCP server, for your AI app

Register the local stdio package after privately configuring your intended site and user.

codex mcp add fluent-wp -- npx -y @thenavidm/fluent-wp-mcp-cli@latest

Which one

Use task-specific CLI help/compact output for scripts and shell agents, or local MCP for structured AI tool access. Both enforce the same native handlers and guard. Complete client setup is in INSTALL.md.

Related MCP server: MCP Site Manager

Features

Capability

CLI command

MCP tool

fcrm list contacts

fluent-wp-cli fcrm-list-contacts

fcrm_list_contacts

fcrm update contact

fluent-wp-cli fcrm-update-contact

fcrm_update_contact

fcrm list campaigns

fluent-wp-cli fcrm-list-campaigns

fcrm_list_campaigns

fc list spaces

fluent-wp-cli fc-list-spaces

fc_list_spaces

fc create feed

fluent-wp-cli fc-create-feed

fc_create_feed

fc create comment

fluent-wp-cli fc-create-comment

fc_create_comment

ff list submissions

fluent-wp-cli ff-list-submissions

ff_list_submissions

ff form stats

fluent-wp-cli ff-form-stats

ff_form_stats

List configured sites

fluent-wp-cli list-accounts

list_accounts

Read one native Community member report

fluent-wp-cli fc-analytics-overview

fc_analytics_overview

Review exact ordered cross-plugin tasks

fluent-wp-cli preview-site-batch

preview_site_batch

Execute reviewed cross-plugin tasks

fluent-wp-cli submit-site-batch

submit_site_batch

Save bounded cross-plugin responses privately

fluent-wp-cli save-site-snapshot

save_site_snapshot

Contents

Number

Section

What it covers

1

What you can ask it

What you can ask it

2

Quick install

Quick install

3

Set up Fluent WordPress access

Set up Fluent WordPress access

4

Connect your client

Connect your client

5

Check it works

Check it works

6

Output, flags and exit codes

Output, flags and exit codes

7

MCP or CLI and token cost

MCP or CLI and token cost

8

Every tool and argument

Every tool and argument

9

CRM, Community and Forms workflows

CRM, Community and Forms workflows

10

Exact reviewed batches and snapshots

Exact reviewed batches and snapshots

11

Several private sites

Several private sites

12

Writing safely

Writing safely

13

How the two surfaces work

How the two surfaces work

14

Your data

Your data

15

Environment variables

Environment variables

16

Updates and removal

Updates and removal

17

Troubleshooting

Troubleshooting

18

API coverage and comparisons

API coverage and comparisons

19

Versions and migration

Versions and migration

20

FAQ

FAQ

1. What you can ask it

Read selected CRM contacts, campaigns and automations; inspect Community spaces, feeds, comments, courses and member analytics; read Forms definitions/submissions/stats; apply exactly approved native changes and save requested private snapshots. Actual shared discovery exposes 54 tools: 41 reads and 13 confirmed operations. The 47 selected native routes and seven local/selector/workflow helpers retain all43 legacy names with documented native corrections.

2. Quick install

npm install -g @thenavidm/fluent-wp-mcp-cli@latest
fluent-wp-cli --version
fluent-wp-cli tools
fluent-wp-cli login

Node22+ for manual installation. INSTALL.md includes Codex, every declared client/OS and the versioned desktop bundle.

3. Set up Fluent WordPress access

Create a dedicated WordPress Application Password

  1. Sign into the intended HTTPS WordPress site. Confirm the site and user before connecting any client. Use a dedicated user with the native Fluent permissions needed for your requested work.

  2. Open Users > Profile > Application Passwords. Give this connection a descriptive name, create an Application Password and save it privately. This is a separate credential, not your main WordPress login password. If the section is unavailable, check HTTPS, WordPress version, hosting/security policy and the user's capabilities with your site administrator.

  3. Configure FLUENT_WP_SITE_URL, FLUENT_WP_USER and either FLUENT_WP_APP_PASSWORD or FLUENT_WP_PASSWORD_FILE. Use the HTTPS site root, optionally its WordPress install subdirectory. Do not append wp-json, put a password in the URL, or include a query/fragment. No redirects or HTTP fallback are followed.

  4. Keep secrets in private client settings or a token-only file outside repositories. Password files must be absolute regular non-symlink files, at most 64 KiB. On macOS/Linux, use an owner-private 0600 file and private parent directory. On Windows, restrict the file and parent directory ACLs separately; POSIX modes do not prove Windows privacy.

  5. Run fluent-wp-cli doctor for local configuration, then deliberately run doctor --network for one GET /wp/v2/users/me with context=view. Its output reports a positive user ID only. This verifies one authenticated WordPress read, not site ownership, all plugin permissions, Pro eligibility or a successful mutation.

WordPress Application Password authentication uses HTTP Basic with username:applicationPassword over HTTPS. The client constructs the header; do not supply a Bearer token or import browser cookies. The package does not log into WordPress, load .env files, create an Application Password, or enable plugins for you.

Plugins, permissions and costs

Install and activate the specific FluentCRM, FluentCommunity and Fluent Forms plugins you intend to use. A site's installed plugin versions and native user capabilities determine its routes and output. Discovery exposes the packaged catalogue before authentication; it does not prove every plugin is present. The package is free under AGPL-3.0. Hosting, paid Pro features, plugin licenses and email delivery services remain separate.

CRM contact/tag/list changes and double opt-in may trigger actual emails or automations. Community announcements, comments and reactions can notify real members. Native Forms reports can update stored metadata. Do not create a contact, publish a feed, or run a stateful report merely to test setup.

The source review covers CRM v2, Community v2 and Forms v1, with Forms plugin source 6.2.14 pinned in provenance. This is a reviewed subset of 47 routes, not every Fluent API. Community analytics/admin course routes require their native permissions and may require Pro. Read native permission notes and inspect your installed versions before account work.

Several isolated sites

FLUENT_WP_ACCOUNTS is a private JSON array of unique {name,site_url,username,app_password,password_file} entries. Choose one password method per profile. Each site requires its own URL, user and credential; a selected profile never falls back to global settings or another site after a missing password or 401/403. FLUENT_WP_DEFAULT_ACCOUNT and --account select an exact label.

list_accounts returns labels, the default and credential source only. It does not reveal site URLs, usernames, password paths or credentials, make requests, or prove provider ownership. Password files are cached until restart. Review hashes bind the selected label, normalized site URL, username, ordered inputs/requests and packaged schema; they do not bind a password fingerprint or validate server state.

Native and local limits

There is no universal vendor quota advertised here. The process spaces requests by 250 ms by default, with a 30-second timeout; hosting, security plugins and other clients can impose different limits. Local pacing is not shared quota enforcement. Requests cap JSON bodies at 1 MiB and responses at 5 MiB. No automatic retries, redirect following, polling or page walking occurs.

Native paginated operations accept only their actual arguments. Where page/per_page are exposed, this wrapper bounds them to 10000/100 locally; this is not a universal provider maximum. Course students and space members do not acquire invented pagination flags. Forms single-entry reads that mark entries as read are intentionally outside this subset.

Revoke and remove

Revoke the dedicated Application Password through the intended WordPress user's Profile. Replace or remove private client/file settings, then restart all server processes. Official plugin MCP credentials and WP-CLI access are separate connections. Uninstalling this package does not undo contact edits, messages, announcements, report migrations or saved private snapshots.

4. Connect your client

INSTALL.md covers Codex first, Claude Code, Claude Desktop bundle/manual config, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Cline, Docker and other local stdio clients on macOS/Windows/Linux. Codex requires no Claude Code installation. GUI/remote runtimes need their own private URL/user/password settings and accessible files. This package supplies local stdio, not a public HTTP connector.

codex mcp add fluent-wp -- npx -y @thenavidm/fluent-wp-mcp-cli@latest
codex mcp list

5. Check it works

fluent-wp-cli --version
fluent-wp-cli tools
fluent-wp-cli list-accounts --agent
fluent-wp-cli doctor
fluent-wp-cli doctor --network
fluent-wp-cli fcrm-list-contacts --per-page 1 --agent --select data.id

Credential-free discovery, native request fixtures and direct full/read-only guard checks are separate from actual provider validation. A positive current-user read establishes neither ownership nor every Fluent permission. Authenticated plugin outcomes and desktop GUI installation remain unverified until independently exercised. Section 7 has the measured token costs.

6. Output, flags and exit codes

Native JSON is preserved after recognized credential redaction; ordinary records remain private. --select keeps only requested output fields. Repeated primitive array flags serialize to native PHP [] query fields. Nested subscriber/note objects use JSON values, and --payload or a private absolute --payload-file provides a complete native body. Do not mix body flags with payload/payload_file. A 202 means acceptance, not completed downstream work. HTTP200 JSON success:false/status:false/native error objects refuse.

Flag

Behavior

--agent

Compact JSON and no prompts; never confirms a write

--confirm

Explicit approval for exactly requested confirmed work

--account LABEL

Exact private site profile

--select a,b.c

Filter returned fields locally

--payload / --payload-file

Whole native body, exclusive with flat body flags/each other

--tasks JSON

Repeat one task object per flag

--review-sha256 HASH

Exact unchanged local preview hash

--output-file PATH

Exclusive new private snapshot file

Exit

Meaning

0

Native response/receipt returned; inspect status and downstream effects

1

Unexpected error

2

Usage, schema, a refused or unapproved operation, an unknown command or a hidden write

3

Not found

4

Authentication/permissions

5

API/network or unknown mutation outcome

7

Rate limited

10

Missing or invalid private configuration

7. MCP or CLI and token cost

Both surfaces call the same MCP handlers and guard. MCP clients choose their own tool discovery/loading strategy. The CLI supports selected command help/schema and compact results; it also consumes command/help/output/reasoning tokens.

Measured on 2026-10-05 against 2.0.1, 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

26,470

25,728

Claude Code's default, tool search, every message

1,295

1,294

SKILL.md, read once

1,325

1,385

Codex over the CLI, one task, median of five

150,331

83,099

Codex over MCP, the same task, median of five

76,977

76,746

The task was "find the command that adds a note to a CRM contact, and the flags it requires". Every tool loaded costs less because a contact's fields and a note's, each written out twice as their own arguments and inside payload, are now written once and referred to. Over the CLI, every 2.0.1 run guessed at least once, with commands, crm --help or a bare schema, because 2.0.1's help never said how to list commands, then read the whole command list and the command's schema as well as its help; every extra step carries the whole conversation forward. Every 3.0.0 run asked which and read one command's help. SKILL.md costs 60 more because it now says how approval works over MCP and lists every exit code.

Tool-list bytes or characters divided by four are not API usage, and no other offering was measured.

8. Every tool and argument

fcrm_dashboard_stats

Retrieve overall dashboard statistics including active contacts count, campaigns count, emails sent, active automations, onboarding progress, quick links, recent contacts, recent campaigns, active automations list, and system recommendations.

Required capability: fcrm_view_dashboard

Enforced by ReportPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-dashboard-stats --help
fluent-wp-cli schema fcrm-dashboard-stats

fcrm_list_contacts

Retrieve a paginated list of contacts. Supports both simple filtering (by tags, lists, statuses) and advanced filtering with complex filter groups. Optionally includes custom field values.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

filter_type

Optional; native body and guard rules still apply

string

Type of filtering to apply. enum: ["simple", "advanced"]. default: "simple".

search

Optional; native body and guard rules still apply

string

Search contacts by name, email, or other searchable fields.

sort_by

Optional; native body and guard rules still apply

string

Column to sort by. default: "id".

sort_type

Optional; native body and guard rules still apply

string

Sort direction. enum: ["ASC", "DESC"]. default: "DESC".

has_commerce

Optional; native body and guard rules still apply

string

Filter by commerce integration availability.

custom_fields

Optional; native body and guard rules still apply

string

Set to true to include custom field values in the response. enum: ["true", "false"].

tags

Optional; native body and guard rules still apply

array

Filter by tag IDs (simple filter mode only).

tags[]

Per item when supplied

integer

Array item schema.

statuses

Optional; native body and guard rules still apply

array

Filter by contact statuses (simple filter mode only).

statuses[]

Per item when supplied

string

Array item schema. Enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]

sms_statuses

Optional; native body and guard rules still apply

array

Filter by SMS statuses (simple filter mode only).

sms_statuses[]

Per item when supplied

string

Array item schema. Enum: ["sms_subscribed", "sms_unsubscribed", "sms_pending", "sms_bounced"]

lists

Optional; native body and guard rules still apply

array

Filter by list IDs (simple filter mode only).

lists[]

Per item when supplied

integer

Array item schema.

company_ids

Optional; native body and guard rules still apply

array

Filter by company IDs.

company_ids[]

Per item when supplied

integer

Array item schema.

advanced_filters

Optional; native body and guard rules still apply

string

JSON-encoded advanced filter groups (advanced filter mode only).

per_page

Optional; native body and guard rules still apply

integer

Number of contacts per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number for pagination. default: 1. minimum: 1. maximum: 10000.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-contacts --help
fluent-wp-cli schema fcrm-list-contacts

fcrm_get_contact

Retrieve a single contact by ID or email. Supports eager-loading related data like stats, custom values, custom field definitions, and commerce stats via the with[] parameter.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The contact ID. minimum: 1.

get_by_email

Optional; native body and guard rules still apply

string

If set, looks up the contact by email address instead of the path id. format: "email".

with

Optional; native body and guard rules still apply

array

Relationships and extra data to include. Supported values: stats, subscriber.custom_values, custom_fields, commerce_stat.

with[]

Per item when supplied

string

Array item schema. Enum: ["stats", "subscriber.custom_values", "custom_fields", "commerce_stat"]

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-get-contact --help
fluent-wp-cli schema fcrm-get-contact

fcrm_search_contacts

Search contacts by name or email. Returns a lightweight object of contacts keyed by ID, suitable for dropdowns and autocomplete widgets. Optionally loads default contacts when no search term is provided.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

search

Optional; native body and guard rules still apply

string

Search term to match against contact name and email.

limit

Optional; native body and guard rules still apply

integer

Maximum number of results to return. default: 20. minimum: 1. maximum: 100.

load_default

Optional; native body and guard rules still apply

string

If truthy and no search term is provided, returns the most recent contacts. enum: ["true", "false", "1", "0", "yes"].

values

Optional; native body and guard rules still apply

array

Array of contact IDs to always include in results (useful for pre-selected values).

values[]

Per item when supplied

integer

Array item schema.

offset

Optional; native body and guard rules still apply

integer

Rows to skip before the first result. Combine with limit to page through matches. default: 0.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-search-contacts --help
fluent-wp-cli schema fcrm-search-contacts

fcrm_create_contact

Create a new contact. If __force_update is set to yes, it will update an existing contact with the same email instead of returning an error. Optionally sends a double opt-in email.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

email

Optional; native body and guard rules still apply

string

Contact email address. Must be unique unless __force_update is yes. format: "email".

status

Optional; native body and guard rules still apply

string

Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

first_name

Optional; native body and guard rules still apply

string

First name.

last_name

Optional; native body and guard rules still apply

string

Last name.

prefix

Optional; native body and guard rules still apply

string

Name prefix (e.g., Mr, Mrs, Ms).

contact_type

Optional; native body and guard rules still apply

string

Contact type. enum: ["lead", "customer"].

address_line_1

Optional; native body and guard rules still apply

string

Address line 1.

address_line_2

Optional; native body and guard rules still apply

string

Address line 2.

postal_code

Optional; native body and guard rules still apply

string

Postal/zip code.

city

Optional; native body and guard rules still apply

string

City.

state

Optional; native body and guard rules still apply

string

State or province.

country

Optional; native body and guard rules still apply

string

Two-letter country code.

phone

Optional; native body and guard rules still apply

string

Phone number.

timezone

Optional; native body and guard rules still apply

string

Timezone identifier.

date_of_birth

Optional; native body and guard rules still apply

string

Date of birth (YYYY-MM-DD).

source

Optional; native body and guard rules still apply

string

Contact source.

tags

Optional; native body and guard rules still apply

array

Tag IDs to assign.

tags[]

Per item when supplied

integer

Array item schema.

lists

Optional; native body and guard rules still apply

array

List IDs to assign.

lists[]

Per item when supplied

integer

Array item schema.

double_optin

Optional; native body and guard rules still apply

boolean

Send double opt-in confirmation email.

__force_update

Optional; native body and guard rules still apply

string

If yes, updates existing contact with the same email instead of failing. enum: ["yes", "no"].

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["email", "status"].

payload.email

Yes

string

Contact email address. Must be unique unless __force_update is yes. format: "email".

payload.status

Yes

string

Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

payload.first_name

Optional; native body and guard rules still apply

string

First name.

payload.last_name

Optional; native body and guard rules still apply

string

Last name.

payload.prefix

Optional; native body and guard rules still apply

string

Name prefix (e.g., Mr, Mrs, Ms).

payload.contact_type

Optional; native body and guard rules still apply

string

Contact type. enum: ["lead", "customer"].

payload.address_line_1

Optional; native body and guard rules still apply

string

Address line 1.

payload.address_line_2

Optional; native body and guard rules still apply

string

Address line 2.

payload.postal_code

Optional; native body and guard rules still apply

string

Postal/zip code.

payload.city

Optional; native body and guard rules still apply

string

City.

payload.state

Optional; native body and guard rules still apply

string

State or province.

payload.country

Optional; native body and guard rules still apply

string

Two-letter country code.

payload.phone

Optional; native body and guard rules still apply

string

Phone number.

payload.timezone

Optional; native body and guard rules still apply

string

Timezone identifier.

payload.date_of_birth

Optional; native body and guard rules still apply

string

Date of birth (YYYY-MM-DD).

payload.source

Optional; native body and guard rules still apply

string

Contact source.

payload.tags

Optional; native body and guard rules still apply

array

Tag IDs to assign.

payload.tags[]

Per item when supplied

integer

Array item schema.

payload.lists

Optional; native body and guard rules still apply

array

List IDs to assign.

payload.lists[]

Per item when supplied

integer

Array item schema.

payload.double_optin

Optional; native body and guard rules still apply

boolean

Send double opt-in confirmation email.

payload.__force_update

Optional; native body and guard rules still apply

string

If yes, updates existing contact with the same email instead of failing. enum: ["yes", "no"].

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fcrm-create-contact --help
fluent-wp-cli schema fcrm-create-contact

fcrm_update_contact

Update an existing contact's fields, custom values, tags, and lists. Supports attaching and detaching tags/lists in a single request. The subscriber object or individual fields can be passed in the request body.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The contact ID. minimum: 1.

subscriber

Optional; native body and guard rules still apply

object

Contact data can be nested inside a subscriber object or passed at the top level. minProperties: 1. additionalProperties: false.

subscriber.email

Optional; native body and guard rules still apply

string

Email address (must be unique). format: "email".

subscriber.first_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.last_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.prefix

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.status

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

subscriber.contact_type

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["lead", "customer"].

subscriber.address_line_1

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.address_line_2

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.postal_code

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.city

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.state

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.country

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.phone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.timezone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.date_of_birth

Optional; native body and guard rules still apply

['string', 'null']

Date of birth (YYYY-MM-DD). Send null or empty string to clear.

subscriber.source

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.custom_values

Optional; native body and guard rules still apply

object

Custom field key-value pairs to update. additionalProperties: {"type": "string"}.

subscriber.attach_tags

Optional; native body and guard rules still apply

array

Tag IDs to attach.

subscriber.attach_tags[]

Per item when supplied

integer

Array item schema.

subscriber.detach_tags

Optional; native body and guard rules still apply

array

Tag IDs to detach.

subscriber.detach_tags[]

Per item when supplied

integer

Array item schema.

subscriber.attach_lists

Optional; native body and guard rules still apply

array

List IDs to attach.

subscriber.attach_lists[]

Per item when supplied

integer

Array item schema.

subscriber.detach_lists

Optional; native body and guard rules still apply

array

List IDs to detach.

subscriber.detach_lists[]

Per item when supplied

integer

Array item schema.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["subscriber"].

payload.subscriber

Yes

object

Contact data can be nested inside a subscriber object or passed at the top level. minProperties: 1. additionalProperties: false.

payload.subscriber.email

Optional; native body and guard rules still apply

string

Email address (must be unique). format: "email".

payload.subscriber.first_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.last_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.prefix

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.status

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

payload.subscriber.contact_type

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["lead", "customer"].

payload.subscriber.address_line_1

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.address_line_2

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.postal_code

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.city

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.state

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.country

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.phone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.timezone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.date_of_birth

Optional; native body and guard rules still apply

['string', 'null']

Date of birth (YYYY-MM-DD). Send null or empty string to clear.

payload.subscriber.source

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.subscriber.custom_values

Optional; native body and guard rules still apply

object

Custom field key-value pairs to update. additionalProperties: {"type": "string"}.

payload.subscriber.attach_tags

Optional; native body and guard rules still apply

array

Tag IDs to attach.

payload.subscriber.attach_tags[]

Per item when supplied

integer

Array item schema.

payload.subscriber.detach_tags

Optional; native body and guard rules still apply

array

Tag IDs to detach.

payload.subscriber.detach_tags[]

Per item when supplied

integer

Array item schema.

payload.subscriber.attach_lists

Optional; native body and guard rules still apply

array

List IDs to attach.

payload.subscriber.attach_lists[]

Per item when supplied

integer

Array item schema.

payload.subscriber.detach_lists

Optional; native body and guard rules still apply

array

List IDs to detach.

payload.subscriber.detach_lists[]

Per item when supplied

integer

Array item schema.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fcrm-update-contact --help
fluent-wp-cli schema fcrm-update-contact

fcrm_contact_notes

Retrieve a paginated list of notes for a contact. Supports searching notes by title. Each note includes the user who created it.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The contact ID. minimum: 1.

search

Optional; native body and guard rules still apply

string

Search notes by title.

per_page

Optional; native body and guard rules still apply

integer

Number of notes per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number. default: 1. minimum: 1. maximum: 10000.

include_id

Optional; native body and guard rules still apply

integer

Id of a note that must appear in the response even when it falls outside the current page. When it is not already on the page it is returned separately as included_note, scoped to this contact.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-contact-notes --help
fluent-wp-cli schema fcrm-contact-notes

fcrm_add_contact_note

Add a new note to a contact. The note description supports SmartCode/merge tags which are parsed before saving. If created_at is not provided, it defaults to the current WordPress time.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The contact ID. minimum: 1.

note

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: ["title", "description", "type"].

note.title

Yes

string

Note title.

note.description

Yes

string

Note content (HTML). Supports SmartCode/merge tags.

note.type

Yes

string

Note type. enum: ["note", "call", "email", "meeting", "activity"].

note.created_at

Optional; native body and guard rules still apply

string

Custom creation date. Defaults to current time if not provided. format: "date-time".

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["note"].

payload.note

Yes

object

Actual shared argument definition. required: ["title", "description", "type"].

payload.note.title

Yes

string

Note title.

payload.note.description

Yes

string

Note content (HTML). Supports SmartCode/merge tags.

payload.note.type

Yes

string

Note type. enum: ["note", "call", "email", "meeting", "activity"].

payload.note.created_at

Optional; native body and guard rules still apply

string

Custom creation date. Defaults to current time if not provided. format: "date-time".

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fcrm-add-contact-note --help
fluent-wp-cli schema fcrm-add-contact-note

fcrm_list_tags

Retrieve a paginated list of tags. Optionally includes subscriber counts and a separate array of all tags for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by TagPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

search

Optional; native body and guard rules still apply

string

Search tags by title, slug, or description.

sort_by

Optional; native body and guard rules still apply

string

Column to sort by. enum: ["id", "title", "slug", "created_at"]. default: "id".

sort_order

Optional; native body and guard rules still apply

string

Sort direction. enum: ["ASC", "DESC"]. default: "DESC".

per_page

Optional; native body and guard rules still apply

integer

Number of tags per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number for pagination. default: 1. minimum: 1. maximum: 10000.

exclude_counts

Optional; native body and guard rules still apply

boolean

If set to any truthy value, subscriber counts will not be included for each tag.

all_tags

Optional; native body and guard rules still apply

boolean

If set to any truthy value, includes a flat all_tags array with id, title, and slug of every tag (useful for dropdowns).

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-tags --help
fluent-wp-cli schema fcrm-list-tags

fcrm_list_lists

Retrieve a paginated list of contact lists. Optionally includes subscriber counts and a separate array of all lists for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by ListPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

search

Optional; native body and guard rules still apply

string

Search lists by title, slug, or description.

sort_by

Optional; native body and guard rules still apply

string

Column to sort by. enum: ["id", "title", "slug", "created_at"]. default: "id".

sort_order

Optional; native body and guard rules still apply

string

Sort direction. enum: ["ASC", "DESC"]. default: "DESC".

per_page

Optional; native body and guard rules still apply

integer

Number of lists per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number for pagination. default: 1. minimum: 1. maximum: 10000.

exclude_counts

Optional; native body and guard rules still apply

boolean

If set to any truthy value, totalCount and subscribersCount will not be included for each list.

all_lists

Optional; native body and guard rules still apply

boolean

If set to any truthy value, includes a flat all_lists array with id, title, and slug of every list (useful for dropdowns).

with

Optional; native body and guard rules still apply

array

Extra data to include. subscribersCount adds per-list contact counts via one grouped pivot query.

with[]

Per item when supplied

string

Array item schema.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-lists --help
fluent-wp-cli schema fcrm-list-lists

fcrm_list_campaigns

Retrieve a paginated list of email campaigns. Supports filtering by status, search term, labels, and sorting. Optionally includes campaign statistics.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

searchBy

Optional; native body and guard rules still apply

string

Search campaigns by title.

statuses

Optional; native body and guard rules still apply

array

Filter by campaign statuses.

statuses[]

Per item when supplied

string

Array item schema. Enum: ["draft", "processing", "pending-scheduled", "scheduled", "working", "paused", "archived"]

sort_by

Optional; native body and guard rules still apply

string

Column to sort by. default: "created_at".

sort_type

Optional; native body and guard rules still apply

string

Sort direction. enum: ["ASC", "DESC"]. default: "DESC".

with

Optional; native body and guard rules still apply

array

Include related data. Use stats to include campaign statistics and labels.

with[]

Per item when supplied

string

Array item schema. Enum: ["stats"]

labels

Optional; native body and guard rules still apply

array

Filter by label IDs.

labels[]

Per item when supplied

integer

Array item schema.

per_page

Optional; native body and guard rules still apply

integer

Number of results per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number. default: 1. minimum: 1. maximum: 10000.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-campaigns --help
fluent-wp-cli schema fcrm-list-campaigns

fcrm_get_campaign

Retrieve a single campaign by ID. Optionally include related data (template, subjects) via the with parameter. When viewCampaign is set, returns the campaign with its paginated emails. Also returns available email templates and the server's current time.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The campaign ID. minimum: 1.

with

Optional; native body and guard rules still apply

array

Include related data (e.g., template, subjects).

with[]

Per item when supplied

string

Array item schema.

viewCampaign

Optional; native body and guard rules still apply

string

If set, returns the campaign with paginated emails instead of the standard response.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-get-campaign --help
fluent-wp-cli schema fcrm-get-campaign

fcrm_campaign_stats

Get overview statistics for a campaign including sent count, email status breakdown, and open/click analytics. This is a lighter-weight alternative to the full campaign status endpoint, suitable for dashboard widgets or summary views.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The campaign ID. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-campaign-stats --help
fluent-wp-cli schema fcrm-campaign-stats

fcrm_list_sequences

Retrieve a paginated list of email sequences. Optionally include statistics (email count, subscriber count, revenue) for each sequence. Requires FluentCampaign Pro.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by SequencePolicy::verifyRequest(), the policy default for this route group.

Requires: FluentCampaign Pro. Without it the route does not exist.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

order

Optional; native body and guard rules still apply

string

Sort direction. enum: ["asc", "desc"]. default: "desc".

orderBy

Optional; native body and guard rules still apply

string

Column to sort by. default: "id".

search

Optional; native body and guard rules still apply

string

Search sequences by title.

with

Optional; native body and guard rules still apply

array

Include additional data. Use stats to include email count, subscriber count, and revenue for each sequence.

with[]

Per item when supplied

string

Array item schema. Enum: ["stats"]

per_page

Optional; native body and guard rules still apply

integer

Number of sequences per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number for pagination. default: 1. minimum: 1. maximum: 10000.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-sequences --help
fluent-wp-cli schema fcrm-list-sequences

fcrm_list_automations

Retrieve a paginated list of automation funnels. Supports sorting, searching by title, and filtering by label IDs. Optionally includes trigger definitions.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

sort_by

Optional; native body and guard rules still apply

string

Column to sort by. default: "id".

sort_type

Optional; native body and guard rules still apply

string

Sort direction. enum: ["ASC", "DESC"]. default: "DESC".

search

Optional; native body and guard rules still apply

string

Search funnels by title (partial match).

labels

Optional; native body and guard rules still apply

array

Filter funnels by label IDs.

labels[]

Per item when supplied

integer

Array item schema.

with

Optional; native body and guard rules still apply

array

Include additional related data. Supported values: triggers.

with[]

Per item when supplied

string

Array item schema. Enum: ["triggers"]

per_page

Optional; native body and guard rules still apply

integer

Number of funnels per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number for pagination. default: 1. minimum: 1. maximum: 10000.

tags

Optional; native body and guard rules still apply

array

Only automations whose contacts carry these tag ids.

tags[]

Per item when supplied

integer

Array item schema.

lists

Optional; native body and guard rules still apply

array

Only automations whose contacts are on these list ids.

lists[]

Per item when supplied

integer

Array item schema.

statuses

Optional; native body and guard rules still apply

array

Filter automations by status, e.g. published or draft.

statuses[]

Per item when supplied

string

Array item schema.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-list-automations --help
fluent-wp-cli schema fcrm-list-automations

fcrm_automation_report

Retrieve statistical reporting data for a specific automation funnel. Returns aggregated stats generated by the Reporting service.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The funnel ID. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-automation-report --help
fluent-wp-cli schema fcrm-automation-report

fcrm_contact_emails

Retrieve a paginated list of emails sent to a contact. Supports filtering by open/click status. Can also show FluentSMTP logs when the tab parameter is set to fluentsmtp.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

id

Yes

integer

The contact ID. minimum: 1.

filter

Optional; native body and guard rules still apply

string

Filter emails by engagement status. enum: ["open", "click", "unopened"].

tab

Optional; native body and guard rules still apply

string

Email source tab. Use fluentsmtp to show FluentSMTP logs instead of CRM campaign emails. enum: ["crm", "fluentsmtp"]. default: "crm".

per_page

Optional; native body and guard rules still apply

integer

Number of emails per page. default: 15. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page number. default: 1. minimum: 1. maximum: 10000.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fcrm-contact-emails --help
fluent-wp-cli schema fcrm-contact-emails

fc_list_spaces

Returns the paginated list of spaces with each one formatted for display, including the current user permissions and membership within it.

Controller: SpaceController@getAllSpaces Route source: fluent-community/app/Http/Routes/api.php:34

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-list-spaces --help
fluent-wp-cli schema fc-list-spaces

fc_get_space

Returns one space with its settings, topics, the current user membership and the permissions they hold inside it.

Controller: SpaceController@getBySlug Route source: fluent-community/app/Http/Routes/api.php:10

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

slug

Yes

string

SpaceSlug extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$".

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-get-space --help
fluent-wp-cli schema fc-get-space

fc_list_feeds

Returns a page of posts the current user is allowed to read, transformed for display, with the pinned post of a space returned separately on the first page.

Controller: FeedsController@get Route source: fluent-community/app/Http/Routes/api.php:45

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

space

Optional; native body and guard rules still apply

string

Space read via $request->get() in get().

user_id

Optional; native body and guard rules still apply

string

User ID read via $request->getSafe() in get().

topic_slug

Optional; native body and guard rules still apply

string

Topic Slug read via $request->getSafe() in get().

search

Optional; native body and guard rules still apply

string

Search read via $request->getSafe() in get().

status

Optional; native body and guard rules still apply

string

Status read via $request->getSafe() in get().

per_page

Optional; native body and guard rules still apply

integer

Per Page read via $request->get() in get(). default: 10. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Page read via $request->get() in get(). default: 1. minimum: 1. maximum: 10000.

search_in

Optional; native body and guard rules still apply

array

Search In read via $request->get() in get(). default: ["post_content"].

order_by_type

Optional; native body and guard rules still apply

string

Order By Type read via $request->getSafe() in get().

disable_sticky

Optional; native body and guard rules still apply

string

Disable Sticky read via $request->get() in get().

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-list-feeds --help
fluent-wp-cli schema fc-list-feeds

fc_get_feed

Returns a single post by numeric id; the id is resolved to a slug and then handled exactly as the by-slug endpoint.

Controller: FeedsController@getFeedById Route source: fluent-community/app/Http/Routes/api.php:53

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

context

Optional; native body and guard rules still apply

string

Prose-documented delegated edit context, requiring native post edit access. enum: ["view", "edit"].

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-get-feed --help
fluent-wp-cli schema fc-get-feed

fc_create_feed

Creates a post, renders its Markdown, attaches media and topics, and returns the transformed post ready to prepend to the feed.

Controller: FeedsController@store Route source: fluent-community/app/Http/Routes/api.php:46 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

space

Optional; native body and guard rules still apply

string

Actual shared argument definition.

topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

topic_ids[]

Per item when supplied

string

Array item schema.

send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

message

Optional; native body and guard rules still apply

string

Actual shared argument definition. minLength: 1.

survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

survey.options[]

Per item when supplied

string

Array item schema.

survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["message"].

payload.space

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

payload.topic_ids[]

Per item when supplied

string

Array item schema.

payload.send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.message

Yes

string

Actual shared argument definition. minLength: 1.

payload.survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

payload.survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

payload.survey.options[]

Per item when supplied

string

Array item schema.

payload.survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fc-create-feed --help
fluent-wp-cli schema fc-create-feed

fc_update_feed

Replaces the body and metadata of an existing post, re-renders it, reconciles its media and topics, and records an edit history entry.

Controller: FeedsController@update Route source: fluent-community/app/Http/Routes/api.php:47 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

new_space_id

Optional; native body and guard rules still apply

string

Actual shared argument definition.

move_to_profile

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

survey.options[]

Per item when supplied

string

Array item schema.

survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

status

Optional; native body and guard rules still apply

string

Actual shared argument definition.

send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

media_images

Optional; native body and guard rules still apply

string

Actual shared argument definition.

topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

topic_ids[]

Per item when supplied

string

Array item schema.

message

Optional; native body and guard rules still apply

string

Actual shared argument definition. minLength: 1.

title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["message"].

payload.new_space_id

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.move_to_profile

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

payload.survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

payload.survey.options[]

Per item when supplied

string

Array item schema.

payload.survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.status

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.media_images

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

payload.topic_ids[]

Per item when supplied

string

Array item schema.

payload.message

Yes

string

Actual shared argument definition. minLength: 1.

payload.title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fc-update-feed --help
fluent-wp-cli schema fc-update-feed

fc_delete_feed

Deletes a post from the community.

Controller: FeedsController@deleteFeed Route source: fluent-community/app/Http/Routes/api.php:64 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

fluent-wp-cli fc-delete-feed --help
fluent-wp-cli schema fc-delete-feed

fc_list_comments

Returns every comment on a post in chronological order, with each author profile attached and the current user liked state flagged.

Controller: CommentsController@getComments Route source: fluent-community/app/Http/Routes/api.php:55

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-list-comments --help
fluent-wp-cli schema fc-list-comments

fc_create_comment

Posts a comment or a threaded reply on a feed item, renders its Markdown, links any attached media and bumps the post comment count.

Controller: CommentsController@store Route source: fluent-community/app/Http/Routes/api.php:56 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

comment

Optional; native body and guard rules still apply

string

Actual shared argument definition. minLength: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["comment"].

payload.comment

Yes

string

Actual shared argument definition. minLength: 1.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fc-create-comment --help
fluent-wp-cli schema fc-create-comment

fc_update_comment

Replaces the body of an existing comment, re-renders it, and reconciles its attached media with the submitted list.

Controller: CommentsController@update Route source: fluent-community/app/Http/Routes/api.php:57 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

comment_id

Yes

integer

Comment ID extracted from the URL path. minimum: 1.

comment

Optional; native body and guard rules still apply

string

Actual shared argument definition. minLength: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false. required: ["comment"].

payload.comment

Yes

string

Actual shared argument definition. minLength: 1.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fc-update-comment --help
fluent-wp-cli schema fc-update-comment

fc_delete_comment

Deletes a comment, recounts the comments on its post and hands any attached media to the media cleanup hook.

Controller: CommentsController@deleteComment Route source: fluent-community/app/Http/Routes/api.php:60 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

comment_id

Yes

integer

Comment ID extracted from the URL path. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

fluent-wp-cli fc-delete-comment --help
fluent-wp-cli schema fc-delete-comment

fc_react_to_feed

Adds or removes the current user reaction on a post and returns the updated count : a second route onto the same behaviour as the reactions toggle endpoint.

Controller: CommentsController@addOrRemovePostReact Route source: fluent-community/app/Http/Routes/api.php:59 Toggle semantics are not idempotent; inspect state before deliberately repeating. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

feed_id

Yes

integer

Feed ID extracted from the URL path. minimum: 1.

react_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

remove

Optional; native body and guard rules still apply

string

Actual shared argument definition.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

payload

Optional; native body and guard rules still apply

object

Complete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file. additionalProperties: false.

payload.react_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload.remove

Optional; native body and guard rules still apply

string

Actual shared argument definition.

payload_file

Optional; native body and guard rules still apply

string

Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. minLength: 1.

fluent-wp-cli fc-react-to-feed --help
fluent-wp-cli schema fc-react-to-feed

fc_list_courses

Returns the paginated list of courses the current user may manage, each with its student count and its section and lesson totals.

Controller: CourseAdminController@getCourses Route source: fluent-community/Modules/Course/Http/course_api.php:22

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

status

Optional; native body and guard rules still apply

string

Status read via $request->getSafe() in getCourses().

sort_by

Optional; native body and guard rules still apply

string

Sort By read via $request->getSafe() in getCourses(). default: "latest".

topic_slug

Optional; native body and guard rules still apply

string

Topic Slug read via $request->getSafe() in getCourses().

search

Optional; native body and guard rules still apply

string

Search read via $request->getSafe() in getCourses().

with_categories

Optional; native body and guard rules still apply

string

With Categories read via $request->get() in getCourses().

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-list-courses --help
fluent-wp-cli schema fc-list-courses

fc_get_course

Returns one course in its editable form, with the lock screen configuration, the attached category ids and : when it has students : the completion count and average progress.

Controller: CourseAdminController@findCourse Route source: fluent-community/Modules/Course/Http/course_api.php:24

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

course_id

Yes

integer

Course ID extracted from the URL path. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-get-course --help
fluent-wp-cli schema fc-get-course

fc_course_students

Returns the paginated roster of a course, each student carrying their enrolment pivot and their completion percentage.

Controller: CourseAdminController@getCourseStudents Route source: fluent-community/Modules/Course/Http/course_api.php:29

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

course_id

Yes

integer

Course ID extracted from the URL path. minimum: 1.

search

Optional; native body and guard rules still apply

string

Search read via $request->getSafe() in getCourseStudents().

sort_by

Optional; native body and guard rules still apply

string

Sort By read via $request->getSafe() in getCourseStudents(). default: "created_at".

sort_dir

Optional; native body and guard rules still apply

string

Sort Dir read via $request->getSafe() in getCourseStudents().

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-course-students --help
fluent-wp-cli schema fc-course-students

fc_course_lessons

Returns the lessons of a course in display order, optionally narrowed to one section.

Controller: CourseAdminController@getLessons Route source: fluent-community/Modules/Course/Http/course_api.php:52

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

course_id

Yes

integer

Course ID extracted from the URL path. minimum: 1.

topic_id

Optional; native body and guard rules still apply

string

Topic ID read via $request->get() in getLessons().

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-course-lessons --help
fluent-wp-cli schema fc-course-lessons

fc_space_members

Returns the paginated active membership of a space, each entry carrying the member profile and their role, plus the count of outstanding join requests.

Controller: SpaceController@getMembers Route source: fluent-community/app/Http/Routes/api.php:18

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

slug

Yes

string

SpaceSlug extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$".

search

Optional; native body and guard rules still apply

string

Search read via $request->getSafe() in getMembers().

status

Optional; native body and guard rules still apply

string

Status read via $request->get() in getMembers().

sort_by

Optional; native body and guard rules still apply

string

Sort By read via $request->getSafe() in getMembers(). default: "created_at".

sort_dir

Optional; native body and guard rules still apply

string

Sort Dir read via $request->getSafe() in getMembers().

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-space-members --help
fluent-wp-cli schema fc-space-members

fc_get_profile

Returns one member public profile by username, with the navigation tabs the portal should render for that member.

Controller: ProfileController@getProfile Route source: fluent-community/app/Http/Routes/api.php:89

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

username

Yes

string

Username extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$".

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-get-profile --help
fluent-wp-cli schema fc-get-profile

fc_scheduled_posts

Returns the paginated list of posts one member has scheduled but not yet published, soonest first.

Controller: SchedulePostsController@getScheduledPosts Route source: fluent-community-pro/app/Http/Routes/api.php:112 Requires FluentCommunity Pro and its native scheduled-post permission. It is not a scheduling action.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

user_id

Optional; native body and guard rules still apply

string

User ID read via $request->getSafe() in getScheduledPosts(). default: "$currentUserId".

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-scheduled-posts --help
fluent-wp-cli schema fc-scheduled-posts

fc_analytics_top_members

Returns ten member profiles ordered by lifetime points, drawn from those who joined within the requested range.

Controller: MembersReportsController@getTopMembers Route source: fluent-community-pro/app/Http/Routes/api.php:82 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-analytics-top-members --help
fluent-wp-cli schema fc-analytics-top-members

fc_analytics_top_commenters

Returns the ten members who wrote the most comments within the requested range, each with their comment count.

Controller: MembersReportsController@topCommenters Route source: fluent-community-pro/app/Http/Routes/api.php:84 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-analytics-top-commenters --help
fluent-wp-cli schema fc-analytics-top-commenters

fc_analytics_top_post_starters

Returns the ten members who published the most posts within the requested range, each with their post count.

Controller: MembersReportsController@topPostStarter Route source: fluent-community-pro/app/Http/Routes/api.php:83 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-analytics-top-post-starters --help
fluent-wp-cli schema fc-analytics-top-post-starters

fc_analytics_member_activity

Returns a gap-filled time series of member signups across the requested range.

Controller: MembersReportsController@activity Route source: fluent-community-pro/app/Http/Routes/api.php:81 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli fc-analytics-member-activity --help
fluent-wp-cli schema fc-analytics-member-activity

ff_list_forms

Read one Forms page with current native sorting and date filters. Requires fluentform_dashboard_access and applicable native form permissions. Not an all-forms snapshot.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

search

Optional; native body and guard rules still apply

string

Actual shared argument definition.

status

Optional; native body and guard rules still apply

string

Actual shared argument definition.

filter_by

Optional; native body and guard rules still apply

string

Actual shared argument definition.

date_range

Optional; native body and guard rules still apply

array

Actual shared argument definition.

date_range[]

Per item when supplied

string

Array item schema.

sort_column

Optional; native body and guard rules still apply

string

Actual shared argument definition.

sort_by

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["ASC", "DESC"].

per_page

Optional; native body and guard rules still apply

integer

Actual shared argument definition. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Actual shared argument definition. minimum: 1. maximum: 10000.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli ff-list-forms --help
fluent-wp-cli schema ff-list-forms

ff_get_form

Read one native form with formMeta; may include private integration/settings data. Requires fluentform_forms_manager for the selected form.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

form_id

Yes

integer

Actual shared argument definition. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli ff-get-form --help
fluent-wp-cli schema ff-get-form

ff_form_fields

Read current native field definitions; no field edits. Requires fluentform_forms_manager for the selected form.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

form_id

Yes

integer

Actual shared argument definition. minimum: 1.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli ff-form-fields --help
fluent-wp-cli schema ff-form-fields

ff_list_submissions

Read one native individual-entry page for an explicitly selected form. Corrects old GET /report/submissions. Requires fluentform_entries_viewer for that form. Entry bodies are private; no automatic detail call or mark-as-read action.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

form_id

Yes

integer

Actual shared argument definition. minimum: 1.

per_page

Optional; native body and guard rules still apply

integer

Actual shared argument definition. minimum: 1. maximum: 100.

page

Optional; native body and guard rules still apply

integer

Actual shared argument definition. minimum: 1. maximum: 10000.

search

Optional; native body and guard rules still apply

string

Actual shared argument definition.

entry_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

date_range

Optional; native body and guard rules still apply

array

Actual shared argument definition. minItems: 2. maxItems: 2.

date_range[]

Per item when supplied

string

Array item schema.

payment_statuses

Optional; native body and guard rules still apply

array

Actual shared argument definition.

payment_statuses[]

Per item when supplied

string

Array item schema.

sort_by

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["ASC", "DESC"].

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli ff-list-submissions --help
fluent-wp-cli schema ff-list-submissions

ff_form_report

Read the native form report with explicit approval because ReportService::form invokes ReportHelper::maybeMigrateData. It may update stored reporting data. Requires native form-scoped fluentform_entries_viewer; hidden/refused in read-only mode. No automatic retries.

Kind: Confirmed operation. Native plugin/user permissions apply.

Argument

Required

Type

Details

form_id

Yes

integer

Actual shared argument definition. minimum: 1.

statuses

Optional; native body and guard rules still apply

array

Actual shared argument definition.

statuses[]

Per item when supplied

string

Array item schema.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

fluent-wp-cli ff-form-report --help
fluent-wp-cli schema ff-form-report

ff_form_stats

Read native date-range form statistics. Requires form-scoped fluentform_entries_viewer when form_id is selected; all-forms permission otherwise. Native reports may change via site hooks and version-specific provider behavior. Not guaranteed lifetime revenue or all plugin statistics.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

form_id

Optional; native body and guard rules still apply

integer

Actual shared argument definition. minimum: 1.

start_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

metric

Optional; native body and guard rules still apply

string

Actual shared argument definition.

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli ff-form-stats --help
fluent-wp-cli schema ff-form-stats

get_current_user

One authenticated WordPress current-user GET with view context; verifies one user read, not site ownership or all plugin permissions. Native private output is untrusted.

Kind: Read. Native plugin/user permissions apply.

Argument

Required

Type

Details

context

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["view", "embed"].

account

Optional; native body and guard rules still apply

string

Exact configured private account profile label; not a tenant or provider account ID.

fluent-wp-cli get-current-user --help
fluent-wp-cli schema get-current-user

list_accounts

Local profile labels/default/credential source only; no site URL, username, password path, provider identity or network request.

Kind: Read. Local helper semantics apply.

Argument

Required

Type

Details

No arguments

Not required

Local discovery

No credential or provider request required.

fluent-wp-cli list-accounts --help
fluent-wp-cli schema list-accounts

get_operation_schema

Local method/path/query/body schema and pinned provenance for one selected native tool. No provider call or credentials.

Kind: Read. Local helper semantics apply.

Argument

Required

Type

Details

operation

Yes

string

Actual native tool name, including fc_update_feed and ff_list_submissions. enum: ["fcrm_dashboard_stats", "fcrm_list_contacts", "fcrm_get_contact", "fcrm_search_contacts", "fcrm_create_contact", "fcrm_update_contact", "fcrm_contact_notes", "fcrm_add_contact_note", "fcrm_list_tags", "fcrm_list_lists", "fcrm_list_campaigns", "fcrm_get_campaign", "fcrm_campaign_stats", "fcrm_list_sequences", "fcrm_list_automations", "fcrm_automation_report", "fcrm_contact_emails", "fc_list_spaces", "fc_get_space", "fc_list_feeds", "fc_get_feed", "fc_create_feed", "fc_update_feed", "fc_delete_feed", "fc_list_comments", "fc_create_comment", "fc_update_comment", "fc_delete_comment", "fc_react_to_feed", "fc_list_courses", "fc_get_course", "fc_course_students", "fc_course_lessons", "fc_space_members", "fc_get_profile", "fc_scheduled_posts", "fc_analytics_top_members", "fc_analytics_top_commenters", "fc_analytics_top_post_starters", "fc_analytics_member_activity", "ff_list_forms", "ff_get_form", "ff_form_fields", "ff_list_submissions", "ff_form_report", "ff_form_stats", "get_current_user"].

fluent-wp-cli get-operation-schema --help
fluent-wp-cli schema get-operation-schema

fc_analytics_overview

Retained legacy selector mapped to four fixed reviewed native Pro report routes. Not a whole-community analytics export; native report permissions apply.

Kind: Read. Local helper semantics apply.

Argument

Required

Type

Details

account

Optional; native body and guard rules still apply

string

Exact configured private site profile label, not a verified site-owner identity.

type

Optional; native body and guard rules still apply

string

One native report, default top-members. enum: ["top-members", "top-commenters", "top-post-starters", "activity"].

fluent-wp-cli fc-analytics-overview --help
fluent-wp-cli schema fc-analytics-overview

preview_site_batch

Local native validation/hash for 1–20 CRM/Community writes. Binds selected profile label/site/username, request order and packaged schemas. No password read/provider state check or remote approval token.

Kind: Read. Local helper semantics apply.

Argument

Required

Type

Details

tasks

Yes

array

One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. minItems: 1. maxItems: 20.

tasks[]

Per item when supplied

object

Array item schema.

tasks[].tool

Yes

string

Actual shared argument definition. enum: ["fcrm_create_contact", "fcrm_update_contact", "fcrm_add_contact_note", "fc_create_feed", "fc_update_feed", "fc_delete_feed", "fc_create_comment", "fc_update_comment", "fc_delete_comment", "fc_react_to_feed"].

tasks[].arguments

Yes

object

Native arguments without account, confirm, payload_file or output_file; complete payload is allowed.

account

Optional; native body and guard rules still apply

string

Exact configured private site profile label, not a verified site-owner identity.

fluent-wp-cli preview-site-batch --help
fluent-wp-cli schema preview-site-batch

submit_site_batch

Confirmed 1–20 ordered CRM/Community writes. Validate every request and exact review hash before first request, stop on first failure with known receipts and unattempted indices; no retries/rollback/continuation.

Kind: Confirmed operation. Local helper semantics apply.

Argument

Required

Type

Details

tasks

Yes

array

One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. minItems: 1. maxItems: 20.

tasks[]

Per item when supplied

object

Array item schema.

tasks[].tool

Yes

string

Actual shared argument definition. enum: ["fcrm_create_contact", "fcrm_update_contact", "fcrm_add_contact_note", "fc_create_feed", "fc_update_feed", "fc_delete_feed", "fc_create_comment", "fc_update_comment", "fc_delete_comment", "fc_react_to_feed"].

tasks[].arguments

Yes

object

Native arguments without account, confirm, payload_file or output_file; complete payload is allowed.

account

Optional; native body and guard rules still apply

string

Exact configured private site profile label, not a verified site-owner identity.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

review_sha256

Yes

string

Exact preview_site_batch hash for unchanged tasks, site profile and schema. pattern: "^[a-f0-9]{64}$".

fluent-wp-cli submit-site-batch --help
fluent-wp-cli schema submit-site-batch

read_site_snapshot

Prevalidate 1–20 native reads for one exact private site profile; return at most5 MiB combined CRM/Community/Forms responses. No auto-pages, stateful report, browser cookies, uploads or atomic provider snapshot. Native records may contain private personal data.

Kind: Read. Local helper semantics apply.

Argument

Required

Type

Details

tasks

Yes

array

One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. minItems: 1. maxItems: 20.

tasks[]

Per item when supplied

object

Array item schema.

tasks[].tool

Yes

string

Actual shared argument definition. enum: ["fcrm_dashboard_stats", "fcrm_list_contacts", "fcrm_get_contact", "fcrm_search_contacts", "fcrm_contact_notes", "fcrm_list_tags", "fcrm_list_lists", "fcrm_list_campaigns", "fcrm_get_campaign", "fcrm_campaign_stats", "fcrm_list_sequences", "fcrm_list_automations", "fcrm_automation_report", "fcrm_contact_emails", "fc_list_spaces", "fc_get_space", "fc_list_feeds", "fc_get_feed", "fc_list_comments", "fc_list_courses", "fc_get_course", "fc_course_students", "fc_course_lessons", "fc_space_members", "fc_get_profile", "fc_scheduled_posts", "fc_analytics_top_members", "fc_analytics_top_commenters", "fc_analytics_top_post_starters", "fc_analytics_member_activity", "ff_list_forms", "ff_get_form", "ff_form_fields", "ff_list_submissions", "ff_form_stats", "get_current_user"].

tasks[].arguments

Yes

object

Native arguments without account, confirm, payload_file or output_file; complete payload is allowed.

account

Optional; native body and guard rules still apply

string

Exact configured private site profile label, not a verified site-owner identity.

fluent-wp-cli read-site-snapshot --help
fluent-wp-cli schema read-site-snapshot

save_site_snapshot

Confirmed 1–20 prevalidated native reads delivered only to an exclusive new0600 JSON file. No record body echoed, overwrites, upload or all-pages guarantee. Failures remove only this helper’s newly created file and return indices without native records.

Kind: Confirmed operation. Local helper semantics apply.

Argument

Required

Type

Details

tasks

Yes

array

One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. minItems: 1. maxItems: 20.

tasks[]

Per item when supplied

object

Array item schema.

tasks[].tool

Yes

string

Actual shared argument definition. enum: ["fcrm_dashboard_stats", "fcrm_list_contacts", "fcrm_get_contact", "fcrm_search_contacts", "fcrm_contact_notes", "fcrm_list_tags", "fcrm_list_lists", "fcrm_list_campaigns", "fcrm_get_campaign", "fcrm_campaign_stats", "fcrm_list_sequences", "fcrm_list_automations", "fcrm_automation_report", "fcrm_contact_emails", "fc_list_spaces", "fc_get_space", "fc_list_feeds", "fc_get_feed", "fc_list_comments", "fc_list_courses", "fc_get_course", "fc_course_students", "fc_course_lessons", "fc_space_members", "fc_get_profile", "fc_scheduled_posts", "fc_analytics_top_members", "fc_analytics_top_commenters", "fc_analytics_top_post_starters", "fc_analytics_member_activity", "ff_list_forms", "ff_get_form", "ff_form_fields", "ff_list_submissions", "ff_form_stats", "get_current_user"].

tasks[].arguments

Yes

object

Native arguments without account, confirm, payload_file or output_file; complete payload is allowed.

account

Optional; native body and guard rules still apply

string

Exact configured private site profile label, not a verified site-owner identity.

confirm

Optional; native body and guard rules still apply

boolean

Set true only when the user asked for exactly this action.

output_file

Yes

string

Absolute new file in an existing private directory; restrict Windows ACLs separately. minLength: 1.

fluent-wp-cli save-site-snapshot --help
fluent-wp-cli schema save-site-snapshot

Native request and source reference

All routes append to the selected trusted site root followed by /wp-json. Parameters retain native spelling and PHP array encoding. A body is required when its schema declares native required fields; payload/body flags are mutually exclusive.

Native fcrm_dashboard_stats

GET /fluent-crm/v2/reports/dashboard-stats

Retrieve overall dashboard statistics including active contacts count, campaigns count, emails sent, active automations, onboarding progress, quick links, recent contacts, recent campaigns, active automations list, and system recommendations.

Required capability: fcrm_view_dashboard

Enforced by ReportPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native fcrm_list_contacts

GET /fluent-crm/v2/subscribers

Retrieve a paginated list of contacts. Supports both simple filtering (by tags, lists, statuses) and advanced filtering with complex filter groups. Optionally includes custom field values.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

filter_type

query

No

{"type": "string", "default": "simple", "enum": ["simple", "advanced"], "description": "Type of filtering to apply."}

search

query

No

{"type": "string", "description": "Search contacts by name, email, or other searchable fields."}

sort_by

query

No

{"type": "string", "default": "id", "description": "Column to sort by."}

sort_type

query

No

{"type": "string", "default": "DESC", "enum": ["ASC", "DESC"], "description": "Sort direction."}

has_commerce

query

No

{"type": "string", "description": "Filter by commerce integration availability."}

custom_fields

query

No

{"type": "string", "enum": ["true", "false"], "description": "Set to true to include custom field values in the response."}

tags[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Filter by tag IDs (simple filter mode only)."}

statuses[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["subscribed", "pending", "unsubscribed", "bounced", "complained"]}, "description": "Filter by contact statuses (simple filter mode only)."}

sms_statuses[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["sms_subscribed", "sms_unsubscribed", "sms_pending", "sms_bounced"]}, "description": "Filter by SMS statuses (simple filter mode only)."}

lists[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Filter by list IDs (simple filter mode only)."}

company_ids[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Filter by company IDs."}

advanced_filters

query

No

{"type": "string", "description": "JSON-encoded advanced filter groups (advanced filter mode only)."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of contacts per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number for pagination.", "minimum": 1, "maximum": 10000}

Native fcrm_get_contact

GET /fluent-crm/v2/subscribers/{id}

Retrieve a single contact by ID or email. Supports eager-loading related data like stats, custom values, custom field definitions, and commerce stats via the with[] parameter.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The contact ID.", "minimum": 1}

get_by_email

query

No

{"type": "string", "format": "email", "description": "If set, looks up the contact by email address instead of the path id."}

with[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["stats", "subscriber.custom_values", "custom_fields", "commerce_stat"]}, "description": "Relationships and extra data to include. Supported values: stats, subscriber.custom_values, custom_fields, commerce_stat."}

Native fcrm_search_contacts

GET /fluent-crm/v2/subscribers/search-contacts

Search contacts by name or email. Returns a lightweight object of contacts keyed by ID, suitable for dropdowns and autocomplete widgets. Optionally loads default contacts when no search term is provided.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

search

query

No

{"type": "string", "description": "Search term to match against contact name and email."}

limit

query

No

{"type": "integer", "default": 20, "description": "Maximum number of results to return.", "minimum": 1, "maximum": 100}

load_default

query

No

{"type": "string", "enum": ["true", "false", "1", "0", "yes"], "description": "If truthy and no search term is provided, returns the most recent contacts."}

values[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Array of contact IDs to always include in results (useful for pre-selected values)."}

offset

query

No

{"type": "integer", "default": 0, "description": "Rows to skip before the first result. Combine with limit to page through matches."}

Native fcrm_create_contact

POST /fluent-crm/v2/subscribers

Create a new contact. If __force_update is set to yes, it will update an existing contact with the same email instead of returning an error. Optionally sends a double opt-in email.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native JSON body: required=true.

Body field

Required

Type

Details

email

Yes

string

Contact email address. Must be unique unless __force_update is yes. format: "email".

status

Yes

string

Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

first_name

Optional; native body and guard rules still apply

string

First name.

last_name

Optional; native body and guard rules still apply

string

Last name.

prefix

Optional; native body and guard rules still apply

string

Name prefix (e.g., Mr, Mrs, Ms).

contact_type

Optional; native body and guard rules still apply

string

Contact type. enum: ["lead", "customer"].

address_line_1

Optional; native body and guard rules still apply

string

Address line 1.

address_line_2

Optional; native body and guard rules still apply

string

Address line 2.

postal_code

Optional; native body and guard rules still apply

string

Postal/zip code.

city

Optional; native body and guard rules still apply

string

City.

state

Optional; native body and guard rules still apply

string

State or province.

country

Optional; native body and guard rules still apply

string

Two-letter country code.

phone

Optional; native body and guard rules still apply

string

Phone number.

timezone

Optional; native body and guard rules still apply

string

Timezone identifier.

date_of_birth

Optional; native body and guard rules still apply

string

Date of birth (YYYY-MM-DD).

source

Optional; native body and guard rules still apply

string

Contact source.

tags

Optional; native body and guard rules still apply

array

Tag IDs to assign.

tags[]

Per item when supplied

integer

Array item schema.

lists

Optional; native body and guard rules still apply

array

List IDs to assign.

lists[]

Per item when supplied

integer

Array item schema.

double_optin

Optional; native body and guard rules still apply

boolean

Send double opt-in confirmation email.

__force_update

Optional; native body and guard rules still apply

string

If yes, updates existing contact with the same email instead of failing. enum: ["yes", "no"].

{
  "type": "object",
  "required": [
    "email",
    "status"
  ],
  "properties": {
    "email": {
      "type": "string",
      "format": "email",
      "description": "Contact email address. Must be unique unless `__force_update` is `yes`."
    },
    "status": {
      "type": "string",
      "enum": [
        "subscribed",
        "pending",
        "unsubscribed",
        "bounced",
        "complained"
      ],
      "description": "Contact subscription status."
    },
    "first_name": {
      "type": "string",
      "description": "First name."
    },
    "last_name": {
      "type": "string",
      "description": "Last name."
    },
    "prefix": {
      "type": "string",
      "description": "Name prefix (e.g., Mr, Mrs, Ms)."
    },
    "contact_type": {
      "type": "string",
      "enum": [
        "lead",
        "customer"
      ],
      "description": "Contact type."
    },
    "address_line_1": {
      "type": "string",
      "description": "Address line 1."
    },
    "address_line_2": {
      "type": "string",
      "description": "Address line 2."
    },
    "postal_code": {
      "type": "string",
      "description": "Postal/zip code."
    },
    "city": {
      "type": "string",
      "description": "City."
    },
    "state": {
      "type": "string",
      "description": "State or province."
    },
    "country": {
      "type": "string",
      "description": "Two-letter country code."
    },
    "phone": {
      "type": "string",
      "description": "Phone number."
    },
    "timezone": {
      "type": "string",
      "description": "Timezone identifier."
    },
    "date_of_birth": {
      "type": "string",
      "description": "Date of birth (YYYY-MM-DD)."
    },
    "source": {
      "type": "string",
      "description": "Contact source."
    },
    "tags": {
      "type": "array",
      "items": {
        "type": "integer"
      },
      "description": "Tag IDs to assign."
    },
    "lists": {
      "type": "array",
      "items": {
        "type": "integer"
      },
      "description": "List IDs to assign."
    },
    "double_optin": {
      "type": "boolean",
      "description": "Send double opt-in confirmation email."
    },
    "__force_update": {
      "type": "string",
      "enum": [
        "yes",
        "no"
      ],
      "description": "If `yes`, updates existing contact with the same email instead of failing."
    }
  },
  "additionalProperties": false
}

Native fcrm_update_contact

PUT /fluent-crm/v2/subscribers/{id}

Update an existing contact's fields, custom values, tags, and lists. Supports attaching and detaching tags/lists in a single request. The subscriber object or individual fields can be passed in the request body.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The contact ID.", "minimum": 1}

Native JSON body: required=true.

Body field

Required

Type

Details

subscriber

Yes

object

Contact data can be nested inside a subscriber object or passed at the top level. minProperties: 1. additionalProperties: false.

subscriber.email

Optional; native body and guard rules still apply

string

Email address (must be unique). format: "email".

subscriber.first_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.last_name

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.prefix

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.status

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"].

subscriber.contact_type

Optional; native body and guard rules still apply

string

Actual shared argument definition. enum: ["lead", "customer"].

subscriber.address_line_1

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.address_line_2

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.postal_code

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.city

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.state

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.country

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.phone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.timezone

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.date_of_birth

Optional; native body and guard rules still apply

['string', 'null']

Date of birth (YYYY-MM-DD). Send null or empty string to clear.

subscriber.source

Optional; native body and guard rules still apply

string

Actual shared argument definition.

subscriber.custom_values

Optional; native body and guard rules still apply

object

Custom field key-value pairs to update. additionalProperties: {"type": "string"}.

subscriber.attach_tags

Optional; native body and guard rules still apply

array

Tag IDs to attach.

subscriber.attach_tags[]

Per item when supplied

integer

Array item schema.

subscriber.detach_tags

Optional; native body and guard rules still apply

array

Tag IDs to detach.

subscriber.detach_tags[]

Per item when supplied

integer

Array item schema.

subscriber.attach_lists

Optional; native body and guard rules still apply

array

List IDs to attach.

subscriber.attach_lists[]

Per item when supplied

integer

Array item schema.

subscriber.detach_lists

Optional; native body and guard rules still apply

array

List IDs to detach.

subscriber.detach_lists[]

Per item when supplied

integer

Array item schema.

{
  "type": "object",
  "properties": {
    "subscriber": {
      "type": "object",
      "description": "Contact data can be nested inside a `subscriber` object or passed at the top level.",
      "properties": {
        "email": {
          "type": "string",
          "format": "email",
          "description": "Email address (must be unique)."
        },
        "first_name": {
          "type": "string"
        },
        "last_name": {
          "type": "string"
        },
        "prefix": {
          "type": "string"
        },
        "status": {
          "type": "string",
          "enum": [
            "subscribed",
            "pending",
            "unsubscribed",
            "bounced",
            "complained"
          ]
        },
        "contact_type": {
          "type": "string",
          "enum": [
            "lead",
            "customer"
          ]
        },
        "address_line_1": {
          "type": "string"
        },
        "address_line_2": {
          "type": "string"
        },
        "postal_code": {
          "type": "string"
        },
        "city": {
          "type": "string"
        },
        "state": {
          "type": "string"
        },
        "country": {
          "type": "string"
        },
        "phone": {
          "type": "string"
        },
        "timezone": {
          "type": "string"
        },
        "date_of_birth": {
          "type": [
            "string",
            "null"
          ],
          "description": "Date of birth (YYYY-MM-DD). Send null or empty string to clear."
        },
        "source": {
          "type": "string"
        },
        "custom_values": {
          "type": "object",
          "description": "Custom field key-value pairs to update.",
          "additionalProperties": {
            "type": "string"
          }
        },
        "attach_tags": {
          "type": "array",
          "items": {
            "type": "integer"
          },
          "description": "Tag IDs to attach."
        },
        "detach_tags": {
          "type": "array",
          "items": {
            "type": "integer"
          },
          "description": "Tag IDs to detach."
        },
        "attach_lists": {
          "type": "array",
          "items": {
            "type": "integer"
          },
          "description": "List IDs to attach."
        },
        "detach_lists": {
          "type": "array",
          "items": {
            "type": "integer"
          },
          "description": "List IDs to detach."
        }
      },
      "minProperties": 1,
      "additionalProperties": false
    }
  },
  "required": [
    "subscriber"
  ],
  "additionalProperties": false
}

Native fcrm_contact_notes

GET /fluent-crm/v2/subscribers/{id}/notes

Retrieve a paginated list of notes for a contact. Supports searching notes by title. Each note includes the user who created it.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The contact ID.", "minimum": 1}

search

query

No

{"type": "string", "description": "Search notes by title."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of notes per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number.", "minimum": 1, "maximum": 10000}

include_id

query

No

{"type": "integer", "description": "Id of a note that must appear in the response even when it falls outside the current page. When it is not already on the page it is returned separately as included_note, scoped to this contact."}

Native fcrm_add_contact_note

POST /fluent-crm/v2/subscribers/{id}/notes

Add a new note to a contact. The note description supports SmartCode/merge tags which are parsed before saving. If created_at is not provided, it defaults to the current WordPress time.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The contact ID.", "minimum": 1}

Native JSON body: required=true.

Body field

Required

Type

Details

note

Yes

object

Actual shared argument definition. required: ["title", "description", "type"].

note.title

Yes

string

Note title.

note.description

Yes

string

Note content (HTML). Supports SmartCode/merge tags.

note.type

Yes

string

Note type. enum: ["note", "call", "email", "meeting", "activity"].

note.created_at

Optional; native body and guard rules still apply

string

Custom creation date. Defaults to current time if not provided. format: "date-time".

{
  "type": "object",
  "required": [
    "note"
  ],
  "properties": {
    "note": {
      "type": "object",
      "required": [
        "title",
        "description",
        "type"
      ],
      "properties": {
        "title": {
          "type": "string",
          "description": "Note title."
        },
        "description": {
          "type": "string",
          "description": "Note content (HTML). Supports SmartCode/merge tags."
        },
        "type": {
          "type": "string",
          "enum": [
            "note",
            "call",
            "email",
            "meeting",
            "activity"
          ],
          "description": "Note type."
        },
        "created_at": {
          "type": "string",
          "format": "date-time",
          "description": "Custom creation date. Defaults to current time if not provided."
        }
      }
    }
  },
  "additionalProperties": false
}

Native fcrm_list_tags

GET /fluent-crm/v2/tags

Retrieve a paginated list of tags. Optionally includes subscriber counts and a separate array of all tags for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by TagPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

search

query

No

{"type": "string", "description": "Search tags by title, slug, or description."}

sort_by

query

No

{"type": "string", "default": "id", "enum": ["id", "title", "slug", "created_at"], "description": "Column to sort by."}

sort_order

query

No

{"type": "string", "default": "DESC", "enum": ["ASC", "DESC"], "description": "Sort direction."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of tags per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number for pagination.", "minimum": 1, "maximum": 10000}

exclude_counts

query

No

{"type": "boolean", "description": "If set to any truthy value, subscriber counts will not be included for each tag."}

all_tags

query

No

{"type": "boolean", "description": "If set to any truthy value, includes a flat all_tags array with id, title, and slug of every tag (useful for dropdowns)."}

Native fcrm_list_lists

GET /fluent-crm/v2/lists

Retrieve a paginated list of contact lists. Optionally includes subscriber counts and a separate array of all lists for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by ListPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

search

query

No

{"type": "string", "description": "Search lists by title, slug, or description."}

sort_by

query

No

{"type": "string", "default": "id", "enum": ["id", "title", "slug", "created_at"], "description": "Column to sort by."}

sort_order

query

No

{"type": "string", "default": "DESC", "enum": ["ASC", "DESC"], "description": "Sort direction."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of lists per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number for pagination.", "minimum": 1, "maximum": 10000}

exclude_counts

query

No

{"type": "boolean", "description": "If set to any truthy value, totalCount and subscribersCount will not be included for each list."}

all_lists

query

No

{"type": "boolean", "description": "If set to any truthy value, includes a flat all_lists array with id, title, and slug of every list (useful for dropdowns)."}

with[]

query

No

{"type": "array", "items": {"type": "string"}, "description": "Extra data to include. subscribersCount adds per-list contact counts via one grouped pivot query."}

Native fcrm_list_campaigns

GET /fluent-crm/v2/campaigns

Retrieve a paginated list of email campaigns. Supports filtering by status, search term, labels, and sorting. Optionally includes campaign statistics.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

searchBy

query

No

{"type": "string", "description": "Search campaigns by title."}

statuses[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["draft", "processing", "pending-scheduled", "scheduled", "working", "paused", "archived"]}, "description": "Filter by campaign statuses."}

sort_by

query

No

{"type": "string", "default": "created_at", "description": "Column to sort by."}

sort_type

query

No

{"type": "string", "default": "DESC", "enum": ["ASC", "DESC"], "description": "Sort direction."}

with[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["stats"]}, "description": "Include related data. Use stats to include campaign statistics and labels."}

labels[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Filter by label IDs."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of results per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number.", "minimum": 1, "maximum": 10000}

Native fcrm_get_campaign

GET /fluent-crm/v2/campaigns/{id}

Retrieve a single campaign by ID. Optionally include related data (template, subjects) via the with parameter. When viewCampaign is set, returns the campaign with its paginated emails. Also returns available email templates and the server's current time.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The campaign ID.", "minimum": 1}

with[]

query

No

{"type": "array", "items": {"type": "string"}, "description": "Include related data (e.g., template, subjects)."}

viewCampaign

query

No

{"type": "string", "description": "If set, returns the campaign with paginated emails instead of the standard response."}

Native fcrm_campaign_stats

GET /fluent-crm/v2/campaigns/{id}/overview_stats

Get overview statistics for a campaign including sent count, email status breakdown, and open/click analytics. This is a lighter-weight alternative to the full campaign status endpoint, suitable for dashboard widgets or summary views.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The campaign ID.", "minimum": 1}

Native fcrm_list_sequences

GET /fluent-crm/v2/sequences

Retrieve a paginated list of email sequences. Optionally include statistics (email count, subscriber count, revenue) for each sequence. Requires FluentCampaign Pro.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by SequencePolicy::verifyRequest(), the policy default for this route group.

Requires: FluentCampaign Pro. Without it the route does not exist.

Reviewed native source.

Native argument

Location

Required

Schema

order

query

No

{"type": "string", "default": "desc", "enum": ["asc", "desc"], "description": "Sort direction."}

orderBy

query

No

{"type": "string", "default": "id", "description": "Column to sort by."}

search

query

No

{"type": "string", "description": "Search sequences by title."}

with[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["stats"]}, "description": "Include additional data. Use stats to include email count, subscriber count, and revenue for each sequence."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of sequences per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number for pagination.", "minimum": 1, "maximum": 10000}

Native fcrm_list_automations

GET /fluent-crm/v2/funnels

Retrieve a paginated list of automation funnels. Supports sorting, searching by title, and filtering by label IDs. Optionally includes trigger definitions.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

sort_by

query

No

{"type": "string", "default": "id", "description": "Column to sort by."}

sort_type

query

No

{"type": "string", "default": "DESC", "enum": ["ASC", "DESC"], "description": "Sort direction."}

search

query

No

{"type": "string", "description": "Search funnels by title (partial match)."}

labels[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Filter funnels by label IDs."}

with[]

query

No

{"type": "array", "items": {"type": "string", "enum": ["triggers"]}, "description": "Include additional related data. Supported values: triggers."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of funnels per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number for pagination.", "minimum": 1, "maximum": 10000}

tags[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Only automations whose contacts carry these tag ids."}

lists[]

query

No

{"type": "array", "items": {"type": "integer"}, "description": "Only automations whose contacts are on these list ids."}

statuses[]

query

No

{"type": "array", "items": {"type": "string"}, "description": "Filter automations by status, e.g. published or draft."}

Native fcrm_automation_report

GET /fluent-crm/v2/funnels/{id}/report

Retrieve statistical reporting data for a specific automation funnel. Returns aggregated stats generated by the Reporting service.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The funnel ID.", "minimum": 1}

Native fcrm_contact_emails

GET /fluent-crm/v2/subscribers/{id}/emails

Retrieve a paginated list of emails sent to a contact. Supports filtering by open/click status. Can also show FluentSMTP logs when the tab parameter is set to fluentsmtp.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

Reviewed native source.

Native argument

Location

Required

Schema

id

path

Yes

{"type": "integer", "description": "The contact ID.", "minimum": 1}

filter

query

No

{"type": "string", "enum": ["open", "click", "unopened"], "description": "Filter emails by engagement status."}

tab

query

No

{"type": "string", "default": "crm", "enum": ["crm", "fluentsmtp"], "description": "Email source tab. Use fluentsmtp to show FluentSMTP logs instead of CRM campaign emails."}

per_page

query

No

{"type": "integer", "default": 15, "description": "Number of emails per page.", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page number.", "minimum": 1, "maximum": 10000}

Native fc_list_spaces

GET /fluent-community/v2/spaces/all-spaces

Returns the paginated list of spaces with each one formatted for display, including the current user permissions and membership within it.

Controller: SpaceController@getAllSpaces Route source: fluent-community/app/Http/Routes/api.php:34

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native fc_get_space

GET /fluent-community/v2/spaces/{spaceSlug}/by-slug

Returns one space with its settings, topics, the current user membership and the permissions they hold inside it.

Controller: SpaceController@getBySlug Route source: fluent-community/app/Http/Routes/api.php:10

Reviewed native source.

Native argument

Location

Required

Schema

spaceSlug

path

Yes

{"type": "string", "description": "SpaceSlug extracted from the URL path.", "minLength": 1, "pattern": "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$"}

Native fc_list_feeds

GET /fluent-community/v2/feeds

Returns a page of posts the current user is allowed to read, transformed for display, with the pinned post of a space returned separately on the first page.

Controller: FeedsController@get Route source: fluent-community/app/Http/Routes/api.php:45

Reviewed native source.

Native argument

Location

Required

Schema

space

query

No

{"type": "string", "description": "Space read via $request->get() in get()."}

user_id

query

No

{"type": "string", "description": "User ID read via $request->getSafe() in get()."}

topic_slug

query

No

{"type": "string", "description": "Topic Slug read via $request->getSafe() in get()."}

search

query

No

{"type": "string", "description": "Search read via $request->getSafe() in get()."}

status

query

No

{"type": "string", "description": "Status read via $request->getSafe() in get()."}

per_page

query

No

{"type": "integer", "default": 10, "description": "Per Page read via $request->get() in get().", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "default": 1, "description": "Page read via $request->get() in get().", "minimum": 1, "maximum": 10000}

search_in

query

No

{"type": "array", "default": ["post_content"], "description": "Search In read via $request->get() in get()."}

order_by_type

query

No

{"type": "string", "description": "Order By Type read via $request->getSafe() in get()."}

disable_sticky

query

No

{"type": "string", "description": "Disable Sticky read via $request->get() in get()."}

Native fc_get_feed

GET /fluent-community/v2/feeds/{feed_id}/by-id

Returns a single post by numeric id; the id is resolved to a slug and then handled exactly as the by-slug endpoint.

Controller: FeedsController@getFeedById Route source: fluent-community/app/Http/Routes/api.php:53

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

context

query

No

{"type": "string", "enum": ["view", "edit"], "description": "Prose-documented delegated edit context, requiring native post edit access."}

Native fc_create_feed

POST /fluent-community/v2/feeds

Creates a post, renders its Markdown, attaches media and topics, and returns the transformed post ready to prepend to the feed.

Controller: FeedsController@store Route source: fluent-community/app/Http/Routes/api.php:46 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native JSON body: required=true.

Body field

Required

Type

Details

space

Optional; native body and guard rules still apply

string

Actual shared argument definition.

topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

topic_ids[]

Per item when supplied

string

Array item schema.

send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

message

Yes

string

Actual shared argument definition. minLength: 1.

survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

survey.options[]

Per item when supplied

string

Array item schema.

survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

{
  "type": "object",
  "properties": {
    "space": {
      "type": "string"
    },
    "topic_ids": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "send_announcement_email": {
      "type": "string"
    },
    "content_type": {
      "type": "string"
    },
    "message": {
      "type": "string",
      "minLength": 1
    },
    "survey": {
      "type": "object",
      "properties": {
        "options": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "end_date": {
          "type": "string"
        },
        "type": {
          "type": "string"
        }
      },
      "required": []
    },
    "title": {
      "type": "string"
    }
  },
  "required": [
    "message"
  ],
  "additionalProperties": false
}

Native fc_update_feed

POST /fluent-community/v2/feeds/{feed_id}

Replaces the body and metadata of an existing post, re-renders it, reconciles its media and topics, and records an edit history entry.

Controller: FeedsController@update Route source: fluent-community/app/Http/Routes/api.php:47 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

Native JSON body: required=true.

Body field

Required

Type

Details

new_space_id

Optional; native body and guard rules still apply

string

Actual shared argument definition.

move_to_profile

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey

Optional; native body and guard rules still apply

object

Actual shared argument definition. required: [].

survey.options

Optional; native body and guard rules still apply

array

Actual shared argument definition.

survey.options[]

Per item when supplied

string

Array item schema.

survey.end_date

Optional; native body and guard rules still apply

string

Actual shared argument definition.

survey.type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

status

Optional; native body and guard rules still apply

string

Actual shared argument definition.

send_announcement_email

Optional; native body and guard rules still apply

string

Actual shared argument definition.

content_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

media_images

Optional; native body and guard rules still apply

string

Actual shared argument definition.

topic_ids

Optional; native body and guard rules still apply

array

Actual shared argument definition.

topic_ids[]

Per item when supplied

string

Array item schema.

message

Yes

string

Actual shared argument definition. minLength: 1.

title

Optional; native body and guard rules still apply

string

Actual shared argument definition.

{
  "type": "object",
  "properties": {
    "new_space_id": {
      "type": "string"
    },
    "move_to_profile": {
      "type": "string"
    },
    "survey": {
      "type": "object",
      "properties": {
        "options": {
          "type": "array",
          "items": {
            "type": "string"
          }
        },
        "end_date": {
          "type": "string"
        },
        "type": {
          "type": "string"
        }
      },
      "required": []
    },
    "status": {
      "type": "string"
    },
    "send_announcement_email": {
      "type": "string"
    },
    "content_type": {
      "type": "string"
    },
    "media_images": {
      "type": "string"
    },
    "topic_ids": {
      "type": "array",
      "items": {
        "type": "string"
      }
    },
    "message": {
      "type": "string",
      "minLength": 1
    },
    "title": {
      "type": "string"
    }
  },
  "required": [
    "message"
  ],
  "additionalProperties": false
}

Native fc_delete_feed

DELETE /fluent-community/v2/feeds/{feed_id}

Deletes a post from the community.

Controller: FeedsController@deleteFeed Route source: fluent-community/app/Http/Routes/api.php:64 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

Native fc_list_comments

GET /fluent-community/v2/feeds/{feed_id}/comments

Returns every comment on a post in chronological order, with each author profile attached and the current user liked state flagged.

Controller: CommentsController@getComments Route source: fluent-community/app/Http/Routes/api.php:55

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

Native fc_create_comment

POST /fluent-community/v2/feeds/{feed_id}/comments

Posts a comment or a threaded reply on a feed item, renders its Markdown, links any attached media and bumps the post comment count.

Controller: CommentsController@store Route source: fluent-community/app/Http/Routes/api.php:56 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

Native JSON body: required=true.

Body field

Required

Type

Details

comment

Yes

string

Actual shared argument definition. minLength: 1.

{
  "type": "object",
  "properties": {
    "comment": {
      "type": "string",
      "minLength": 1
    }
  },
  "additionalProperties": false,
  "required": [
    "comment"
  ]
}

Native fc_update_comment

POST /fluent-community/v2/feeds/{feed_id}/comments/{comment_id}

Replaces the body of an existing comment, re-renders it, and reconciles its attached media with the submitted list.

Controller: CommentsController@update Route source: fluent-community/app/Http/Routes/api.php:57 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

comment_id

path

Yes

{"type": "integer", "description": "Comment ID extracted from the URL path.", "minimum": 1}

Native JSON body: required=true.

Body field

Required

Type

Details

comment

Yes

string

Actual shared argument definition. minLength: 1.

{
  "type": "object",
  "properties": {
    "comment": {
      "type": "string",
      "minLength": 1
    }
  },
  "additionalProperties": false,
  "required": [
    "comment"
  ]
}

Native fc_delete_comment

DELETE /fluent-community/v2/feeds/{feed_id}/comments/{comment_id}

Deletes a comment, recounts the comments on its post and hands any attached media to the media cleanup hook.

Controller: CommentsController@deleteComment Route source: fluent-community/app/Http/Routes/api.php:60 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

comment_id

path

Yes

{"type": "integer", "description": "Comment ID extracted from the URL path.", "minimum": 1}

Native fc_react_to_feed

POST /fluent-community/v2/feeds/{feed_id}/react

Adds or removes the current user reaction on a post and returns the updated count : a second route onto the same behaviour as the reactions toggle endpoint.

Controller: CommentsController@addOrRemovePostReact Route source: fluent-community/app/Http/Routes/api.php:59 Toggle semantics are not idempotent; inspect state before deliberately repeating. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

Reviewed native source.

Native argument

Location

Required

Schema

feed_id

path

Yes

{"type": "integer", "description": "Feed ID extracted from the URL path.", "minimum": 1}

Native JSON body: required=false.

Body field

Required

Type

Details

react_type

Optional; native body and guard rules still apply

string

Actual shared argument definition.

remove

Optional; native body and guard rules still apply

string

Actual shared argument definition.

{
  "type": "object",
  "properties": {
    "react_type": {
      "type": "string"
    },
    "remove": {
      "type": "string"
    }
  },
  "additionalProperties": false
}

Native fc_list_courses

GET /fluent-community/v2/admin/courses

Returns the paginated list of courses the current user may manage, each with its student count and its section and lesson totals.

Controller: CourseAdminController@getCourses Route source: fluent-community/Modules/Course/Http/course_api.php:22

Reviewed native source.

Native argument

Location

Required

Schema

status

query

No

{"type": "string", "description": "Status read via $request->getSafe() in getCourses()."}

sort_by

query

No

{"type": "string", "default": "latest", "description": "Sort By read via $request->getSafe() in getCourses()."}

topic_slug

query

No

{"type": "string", "description": "Topic Slug read via $request->getSafe() in getCourses()."}

search

query

No

{"type": "string", "description": "Search read via $request->getSafe() in getCourses()."}

with_categories

query

No

{"type": "string", "description": "With Categories read via $request->get() in getCourses()."}

Native fc_get_course

GET /fluent-community/v2/admin/courses/{course_id}

Returns one course in its editable form, with the lock screen configuration, the attached category ids and : when it has students : the completion count and average progress.

Controller: CourseAdminController@findCourse Route source: fluent-community/Modules/Course/Http/course_api.php:24

Reviewed native source.

Native argument

Location

Required

Schema

course_id

path

Yes

{"type": "integer", "description": "Course ID extracted from the URL path.", "minimum": 1}

Native fc_course_students

GET /fluent-community/v2/admin/courses/{course_id}/students

Returns the paginated roster of a course, each student carrying their enrolment pivot and their completion percentage.

Controller: CourseAdminController@getCourseStudents Route source: fluent-community/Modules/Course/Http/course_api.php:29

Reviewed native source.

Native argument

Location

Required

Schema

course_id

path

Yes

{"type": "integer", "description": "Course ID extracted from the URL path.", "minimum": 1}

search

query

No

{"type": "string", "description": "Search read via $request->getSafe() in getCourseStudents()."}

sort_by

query

No

{"type": "string", "default": "created_at", "description": "Sort By read via $request->getSafe() in getCourseStudents()."}

sort_dir

query

No

{"type": "string", "description": "Sort Dir read via $request->getSafe() in getCourseStudents()."}

Native fc_course_lessons

GET /fluent-community/v2/admin/courses/{course_id}/lessons

Returns the lessons of a course in display order, optionally narrowed to one section.

Controller: CourseAdminController@getLessons Route source: fluent-community/Modules/Course/Http/course_api.php:52

Reviewed native source.

Native argument

Location

Required

Schema

course_id

path

Yes

{"type": "integer", "description": "Course ID extracted from the URL path.", "minimum": 1}

topic_id

query

No

{"type": "string", "description": "Topic ID read via $request->get() in getLessons()."}

Native fc_space_members

GET /fluent-community/v2/spaces/{spaceSlug}/members

Returns the paginated active membership of a space, each entry carrying the member profile and their role, plus the count of outstanding join requests.

Controller: SpaceController@getMembers Route source: fluent-community/app/Http/Routes/api.php:18

Reviewed native source.

Native argument

Location

Required

Schema

spaceSlug

path

Yes

{"type": "string", "description": "SpaceSlug extracted from the URL path.", "minLength": 1, "pattern": "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$"}

search

query

No

{"type": "string", "description": "Search read via $request->getSafe() in getMembers()."}

status

query

No

{"type": "string", "description": "Status read via $request->get() in getMembers()."}

sort_by

query

No

{"type": "string", "default": "created_at", "description": "Sort By read via $request->getSafe() in getMembers()."}

sort_dir

query

No

{"type": "string", "description": "Sort Dir read via $request->getSafe() in getMembers()."}

Native fc_get_profile

GET /fluent-community/v2/profile/{username}

Returns one member public profile by username, with the navigation tabs the portal should render for that member.

Controller: ProfileController@getProfile Route source: fluent-community/app/Http/Routes/api.php:89

Reviewed native source.

Native argument

Location

Required

Schema

username

path

Yes

{"type": "string", "description": "Username extracted from the URL path.", "minLength": 1, "pattern": "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$"}

Native fc_scheduled_posts

GET /fluent-community/v2/scheduled-posts

Returns the paginated list of posts one member has scheduled but not yet published, soonest first.

Controller: SchedulePostsController@getScheduledPosts Route source: fluent-community-pro/app/Http/Routes/api.php:112 Requires FluentCommunity Pro and its native scheduled-post permission. It is not a scheduling action.

Reviewed native source.

Native argument

Location

Required

Schema

user_id

query

No

{"type": "string", "default": "$currentUserId", "description": "User ID read via $request->getSafe() in getScheduledPosts()."}

Native fc_analytics_top_members

GET /fluent-community/v2/analytics/members/top-members

Returns ten member profiles ordered by lifetime points, drawn from those who joined within the requested range.

Controller: MembersReportsController@getTopMembers Route source: fluent-community-pro/app/Http/Routes/api.php:82 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native fc_analytics_top_commenters

GET /fluent-community/v2/analytics/members/top-commenters

Returns the ten members who wrote the most comments within the requested range, each with their comment count.

Controller: MembersReportsController@topCommenters Route source: fluent-community-pro/app/Http/Routes/api.php:84 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native fc_analytics_top_post_starters

GET /fluent-community/v2/analytics/members/top-post-starters

Returns the ten members who published the most posts within the requested range, each with their post count.

Controller: MembersReportsController@topPostStarter Route source: fluent-community-pro/app/Http/Routes/api.php:83 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native fc_analytics_member_activity

GET /fluent-community/v2/analytics/members/activity

Returns a gap-filled time series of member signups across the requested range.

Controller: MembersReportsController@activity Route source: fluent-community-pro/app/Http/Routes/api.php:81 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

Reviewed native source.

Native argument

Location

Required

Schema

No path/query arguments

None

No

Native permissions and body/guard rules still apply.

Native ff_list_forms

GET /fluentform/v1/forms

Read one Forms page with current native sorting and date filters. Requires fluentform_dashboard_access and applicable native form permissions. Not an all-forms snapshot.

Reviewed native source.

Native argument

Location

Required

Schema

search

query

No

{"type": "string"}

status

query

No

{"type": "string"}

filter_by

query

No

{"type": "string"}

date_range

query

No

{"type": "array", "items": {"type": "string"}}

sort_column

query

No

{"type": "string"}

sort_by

query

No

{"type": "string", "enum": ["ASC", "DESC"]}

per_page

query

No

{"type": "integer", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "minimum": 1, "maximum": 10000}

Native ff_get_form

GET /fluentform/v1/forms/{form_id}

Read one native form with formMeta; may include private integration/settings data. Requires fluentform_forms_manager for the selected form.

Reviewed native source.

Native argument

Location

Required

Schema

form_id

path

Yes

{"type": "integer", "minimum": 1}

Native ff_form_fields

GET /fluentform/v1/forms/{form_id}/fields

Read current native field definitions; no field edits. Requires fluentform_forms_manager for the selected form.

Reviewed native source.

Native argument

Location

Required

Schema

form_id

path

Yes

{"type": "integer", "minimum": 1}

Native ff_list_submissions

GET /fluentform/v1/submissions

Read one native individual-entry page for an explicitly selected form. Corrects old GET /report/submissions. Requires fluentform_entries_viewer for that form. Entry bodies are private; no automatic detail call or mark-as-read action.

Reviewed native source.

Native argument

Location

Required

Schema

form_id

query

Yes

{"type": "integer", "minimum": 1}

per_page

query

No

{"type": "integer", "minimum": 1, "maximum": 100}

page

query

No

{"type": "integer", "minimum": 1, "maximum": 10000}

search

query

No

{"type": "string"}

entry_type

query

No

{"type": "string"}

date_range

query

No

{"type": "array", "items": {"type": "string"}, "minItems": 2, "maxItems": 2}

payment_statuses

query

No

{"type": "array", "items": {"type": "string"}}

sort_by

query

No

{"type": "string", "enum": ["ASC", "DESC"]}

Native ff_form_report

GET /fluentform/v1/report/forms/{form_id}

Read the native form report with explicit approval because ReportService::form invokes ReportHelper::maybeMigrateData. It may update stored reporting data. Requires native form-scoped fluentform_entries_viewer; hidden/refused in read-only mode. No automatic retries.

Reviewed native source.

Native argument

Location

Required

Schema

form_id

path

Yes

{"type": "integer", "minimum": 1}

statuses

query

No

{"type": "array", "items": {"type": "string"}}

Native ff_form_stats

GET /fluentform/v1/report/form-stats

Read native date-range form statistics. Requires form-scoped fluentform_entries_viewer when form_id is selected; all-forms permission otherwise. Native reports may change via site hooks and version-specific provider behavior. Not guaranteed lifetime revenue or all plugin statistics.

Reviewed native source.

Native argument

Location

Required

Schema

form_id

query

No

{"type": "integer", "minimum": 1}

start_date

query

No

{"type": "string"}

end_date

query

No

{"type": "string"}

metric

query

No

{"type": "string"}

Native get_current_user

GET /wp/v2/users/me

One authenticated WordPress current-user GET with view context; verifies one user read, not site ownership or all plugin permissions. Native private output is untrusted.

Reviewed native source.

Native argument

Location

Required

Schema

context

query

No

{"type": "string", "enum": ["view", "embed"]}

9. CRM, Community and Forms workflows

Read CRM before an approved change

Discover real contacts, tags and lists first. An approved status/list/tag update can trigger automations; read the current profile and choose only the requested fields. A successful native receipt does not prove all downstream emails or hooks completed.

fluent-wp-cli fcrm-list-contacts --per-page 5 --agent
fluent-wp-cli fcrm-list-tags --per-page 5 --agent
fluent-wp-cli schema fcrm-update-contact
fluent-wp-cli fcrm-update-contact --help

Read Community and edit the intended content

Get a real space slug and feed ID. Feeds use native space/content_type/message, comments use comment, and content edits use POST. Announcement email is a separate effect: approve it explicitly if requested. Scheduled-post discovery is not a scheduling action.

fluent-wp-cli fc-list-spaces --agent
fluent-wp-cli fc-list-feeds --per-page 5 --agent
fluent-wp-cli schema fc-create-feed
fluent-wp-cli schema fc-update-comment

Read Forms submissions without marking an entry

Discover form IDs and request a selected submissions page. entry_type controls native status/favourites filters, sort_by is a direction, and date_range is a two-element array. The package does not silently call a single-entry endpoint that marks entries read. ff_form_report is a confirmed stateful report, separate from ordinary entry/stat reads.

fluent-wp-cli ff-list-forms --per-page 5 --agent
fluent-wp-cli ff-list-submissions --form-id 123 --per-page 5 --agent
fluent-wp-cli schema ff-form-stats
fluent-wp-cli ff-form-report --help

123 is an example ID; replace it with a real ID read from the intended site before making that request.

10. Exact reviewed batches and snapshots

Preview one to twenty exact ordered CRM/Community writes. Every native schema/body is validated before the first request. Preview is local and does not read a password, query provider state, lock a cohort or issue a native official confirmation token. Select the same exact site and unchanged task order when submitting.

fluent-wp-cli preview-site-batch --help
fluent-wp-cli schema submit-site-batch
fluent-wp-cli read-site-snapshot --help
fluent-wp-cli schema save-site-snapshot

Each --tasks flag is one JSON object with tool and arguments. Task arguments cannot override account/confirm or refer to payload_file/output_file. Use a complete immutable payload value when needed. submit-site-batch requires --confirm and the exact --review-sha256 hash; --agent and --yes never supply approval. Execution stops on the first failure and returns knownResults, failedIndex and unattemptedIndices. No retry, rollback or automatic continuation occurs. A failed request can have an unknown result, and a receipt can precede hook/announcement completion.

read_site_snapshot prevalidates one to twenty selected native reads for one site and returns at most 5 MiB combined native responses. Each list is one requested page, not an all-pages backup or atomic provider snapshot. save_site_snapshot requires confirmation and an absolute new file in an existing private directory. It reserves the file exclusively with mode0600, never overwrites, and returns only path/bytes/SHA-256 metadata. Failure removes only its newly created file and reports indices without native records. Keep Windows ACLs and parent-directory privacy separately restricted. Stateful Forms reports are excluded from these read helpers.

11. Several private sites

FLUENT_WP_ACCOUNTS is a private JSON array of unique {name,site_url,username,app_password,password_file} entries. Choose one password method per profile. Each site requires its own URL, user and credential; a selected profile never falls back to global settings or another site after a missing password or 401/403. FLUENT_WP_DEFAULT_ACCOUNT and --account select an exact label.

list_accounts returns labels, the default and credential source only. It does not reveal site URLs, usernames, password paths or credentials, make requests, or prove provider ownership. Password files are cached until restart. Review hashes bind the selected label, normalized site URL, username, ordered inputs/requests and packaged schema; they do not bind a password fingerprint or validate server state.

fluent-wp-cli list-accounts --agent
fluent-wp-cli fcrm-list-contacts --account work --per-page 1 --agent

12. Writing safely

All 13 mutations/stateful reports/private file operations require --confirm or confirm:true through the same write guard. FLUENT_WP_READ_ONLY=1 exposes only 41 reads and directly refuses hidden confirmed calls. FLUENT_WP_ALLOW_DESTRUCTIVE=0 independently refuses confirmed operations. --agent/--yes control formatting and never authorize.

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. FLUENT_WP_CONFIRM=model makes confirm:true enough everywhere, for an agent with no person to ask.

Only the selected trusted HTTPS site and reviewed REST paths are allowed. No credentials in URLs, redirects, arbitrary endpoint requests, browser/session import, automatic retries or vendor code execution occurs. Local preview hashes do not replace native permissions, site-state review or human authorization. The audit log records static operation/guard decisions and who approved each call, then whether it was done or failed, without request bodies; append failures are best effort, not guaranteed compliance logging.

CRM contacts and opt-ins, Community comments/reactions/announcements and stored report metadata can affect real users. Read-only applies to actual side effects, including the GET Forms report that may migrate metadata. No automatic delete, send, database maintenance or rollback is added after a user requests a narrower action.

13. How the two surfaces work

Slipway builds the MCP server, over stdio or --http, and the CLI from each tool's one definition. Commands, schema discovery, validation, site selection, handlers and the write guard are shared; there is no separate CLI API client or second tool implementation. One catalogue powers all 54 tools and commands. Helpers compile only the selected allowlisted native routes, with whole-batch prevalidation before any provider request.

14. Your data

The runtime sends Basic credentials only to your selected HTTPS site. Configured/cached passwords, Basic-encoded credentials, recognized secret-named fields and signed/token URLs are redacted from returned data and errors. Contacts, emails, names, addresses, course students, comments, form entries and ordinary URLs remain potentially private. Redaction does not remove all personal or business information.

Request and select only the necessary records. Treat WordPress content, form submissions, HTML, URLs and provider errors as untrusted data, never executable instructions or authorization. Snapshot files contain the requested private native records, even though the save receipt omits them. Keep files, parent directories and backups private, and decide retention deliberately. No telemetry, remote upload, cookie import, automatic .env loader or credential refresh is included.

15. Environment variables

Variable

Behavior

Group

FLUENT_WP_SITE_URL

Trusted HTTPS site root, optional install subdirectory

Credentials

FLUENT_WP_USER

WordPress username; no colon/control characters

Credentials

FLUENT_WP_APP_PASSWORD

Private dedicated Application Password; never main login

Credentials

FLUENT_WP_PASSWORD_FILE

Absolute owner-private non-symlink password-only file, <=64 KiB

Credentials

FLUENT_WP_ACCOUNTS

Private unique named site_url/username/app_password or password_file profiles

Credentials

FLUENT_WP_DEFAULT_ACCOUNT

Exact selected private site label

Credentials

FLUENT_WP_URL / FLUENT_WP_PASS

Legacy aliases; conflicting canonical values refuse

Compatibility

FLUENT_WP_READ_ONLY

1/true hides and directly refuses 13 confirmed operations

Safety

FLUENT_WP_ALLOW_DESTRUCTIVE

0/false refuses all confirmed operations; default true

Safety

FLUENT_WP_AUDIT_LOG

Private best-effort JSONL guard log, no payloads

Safety

FLUENT_WP_REQUEST_TIMEOUT_MS

30000 default; integer 100–300000; no automatic retry

Tuning

FLUENT_WP_MIN_REQUEST_INTERVAL_MS

250 default; integer 0–10000; process spacing only

Tuning

FLUENT_WP_CONFIRM

human by default; model lets confirm:true alone approve over MCP, for an agent with no person to ask

Safety

FLUENT_WP_SURFACE

full by default; search lists three tools that find, describe and run the rest

Tuning

FLUENT_WP_TOOL_TIMEOUT_MS

Give up on any tool after this long

Tuning

FLUENT_WP_HTTP_PORT, FLUENT_WP_HTTP_HOST, FLUENT_WP_HTTP_TOKEN

For --http: port 8787 and host 127.0.0.1 by default; any other host needs the bearer token

HTTP

FLUENT_WP_HTTP_ALLOWED_ORIGINS

Comma-separated browser origins allowed to call --http; a page from any other site is refused

HTTP

FLUENT_WP_DEBUG

1 prints debug lines on stderr

Tuning

16. Updates and removal

Use npx -y @thenavidm/fluent-wp-mcp-cli@latest for fresh client launches, then reconnect/restart. Global installs require npm update -g @thenavidm/fluent-wp-mcp-cli. Desktop extensions require installing the newly versioned archive. Read the major migration table before replacing old script arguments. Remove only the requested registration, skill, package or extension. Revoke Application Passwords separately; private snapshots and provider changes remain.

npm update -g @thenavidm/fluent-wp-mcp-cli
fluent-wp-cli --version
# Removal only when requested
codex mcp remove fluent-wp
npm uninstall -g @thenavidm/fluent-wp-mcp-cli

17. Troubleshooting

Symptom

Check and resolution

No binary/Node

Install Node22+, check npm global PATH and reopen terminal; npm.cmd can respect Windows policy

Configuration exit10

Set each selected profile URL/user and one password method; no global fallback

Unsafe URL/refused redirect

Use the canonical trusted HTTPS root/install subdirectory, no wp-json/query/fragment/credentials

401/403

Check Application Password revocation, Basic header forwarding, native capabilities and security plugin policy

WordPress user read passes, Fluent fails

User identity does not prove plugin activation, route version, native access or Pro eligibility

404/HTML response

Check installed plugins, exact site root and REST path; redirects/login HTML are not followed

HTTP200 but native failure

success:false, status:false or native code/data.status errors refuse; inspect error receipt

429/timeout

Respect host guidance and inspect mutation state before deliberately repeating; no retry loop

Old feed/comment args

Use space/content_type/message and comment; POST content edits, no guessed PATCH

Wrong Forms entries

Use GET submissions and actual form_id/entry_type/sort_by; aggregate reports are different

Read-only report refusal

ff_form_report is stateful in current source; explicit requested approval is required

Review mismatch/partial batch

Preview unchanged site/tasks again; retain known receipts and do not replay successes

Existing snapshot file

Choose a new absolute file; no overwrite or cross-site append

GUI/remote runtime differs

Give that actual runtime private settings and accessible files; restart/reconnect

18. API coverage and comparisons

Existing official MCPs and CLIs

FluentCRM, Fluent Forms, Fluent Boards, FluentCart and Fluent Support already document official MCP support. These are separate native product connections, not one documented universal server URL. Follow each product's current setup and use only the tools/permissions your installed version exposes. A dedicated official FluentCommunity MCP was not confirmed in the reviewed primary sources.

FluentCRM MCP and Fluent Forms MCP are existing choices. Current Forms free source registers 20 abilities; the launch article describes 20 free and 23 Pro, while three Pro teaser cards in free settings are not registered free abilities. Its preview guards already bind current state, issue single-use tokens expiring after 300 seconds and enforce idempotency/concurrency rules. Our local review hash is not that server-state protection.

wp fluent_crm already provides native server-side stats, email sending, commerce sync, automation simulation and license management. wp fluentform already provides plugin stats and license operations. They run in the site's WP-CLI environment. Our remote Node task CLI calls allowlisted REST routes from your selected local/client runtime; it is not the first Fluent CLI and does not replace WP-CLI's direct database/send/maintenance operations.

Pinned community implementation

The reviewed carlosrodera/fluent-mcp-servers implements 40 CRM and 30 Community tools. Its dynamic mode exposes search/describe/execute metadata tools per server, an existing approach to selected discovery. A stdio entry point named cli is not a standalone task-command interface. The examined native-write factory does not require our mandatory per-call confirmation; annotations alone do not enforce it. This source was inspected, not executed against a private account.

Counts describe different scopes and modes. The community root documentation includes other products; its broader total does not mean this package covers them. No runtime token percentage or general reliability advantage follows from source inspection.

Why build this companion

The useful addition is one remote task CLI/local MCP covering selected CRM, Community and Forms work, exact isolated site profiles, shared mandatory approval and direct read-only refusal, reviewed ordered cross-plugin changes and bounded private snapshots. Those behaviors are implemented and fixture-tested. Official product-native breadth, Forms server-state review tokens and community dynamic discovery retain their own advantages.

Capability

This companion

Existing alternatives

Remote task commands

54 shared commands/tools through actual MCP handlers

Official WP-CLI runs in WordPress; reviewed community entry points are stdio servers

Native route coverage

47 selected routes: 17 CRM, 23 Community, 6 Forms, 1 WordPress

Official/community coverage is product-specific; not all routes counted alike

Ordered changes

Local preview hash, explicit confirmation, stop on first failure

Official Forms has actual provider-state tokens and idempotency guards

Several sites

Independent URL/user/password per exact profile; no global fallback

Reviewed community product configs do not expose the same named-site profiles

Private snapshots

1–20 selected reads, exclusive new file, bounded response sizes

Not a complete backup, migration, atomic database snapshot or native CSV export

Context cost

Measured against 2.0.1 in section 7: a Codex discovery task took a median of 83,099 input tokens over the CLI and 76,746 over MCP

Dynamic community discovery already exists; not measured

19. Versions and migration

Component

Current reviewed version

Package/desktop manifest

3.0.0

Node support

22 or newer

Native API namespaces

CRM v2; Community v2; Forms v1; WordPress v2

Forms source

6.2.14 at pinned commit

Slipway

0.1.17

MCP TypeScript SDK, through Slipway

2.3.0

Schema validators

Ajv8.20.0; ajv-formats3.0.1 locked

Source provenance

Five pinned upstream repos, reviewed2026-10-03

All 43 legacy tool names remain in this major refresh. Keeping a name does not keep a broken method, argument or unsafe side effect. Inspect the actual schema before updating saved scripts.

Legacy area

2.0.0 correction

Caller action

Setup

Canonical SITE_URL/APP_PASSWORD now match documentation; URL/PASS remain aliases

Do not configure conflicting aliases; keep each site credential independent

Community feeds

space/order_by_type replace space_id/sort_by; creation uses space/content_type/message

Use a real native space selector, exact fields and explicit announcement choice

Feed editing

Content edit uses POST with required message; PATCH is separate state/pin behavior

Update the payload; no invented is_sticky action

Comments

Native comment field and POST edits replace message/PATCH

Use --comment and actual feed/comment IDs

Contact updates/notes

Nested subscriber and note objects replace incorrect flat/misnamed bodies

Read nested schemas and send a whole object or private payload file

Campaigns

Native searchBy/statuses/with/labels; arrays serialize as PHP [] query entries

Use actual camel-case and repeated array flags

Forms entries

GET /submissions, required form_id, entry_type, ASC/DESC sort_by

Do not use aggregate POST report route or ignored legacy status/favourite flags

Forms stats

start_date/end_date/metric replace ignored period/group_by

Supply both dates or neither

Forms report

GET may migrate report metadata; now confirmed and excluded from read-only/snapshot reads

Explicitly approve this stateful report; never use it as a setup probe

Community analytics

Legacy selector maps four fixed native Pro member-report paths

Use an allowed type; not arbitrary paths or whole-community analytics

Students/members

Exact native search/sort fields; no invented page/per_page

Inspect schema rather than assume every response supports pagination

The fresh public history excludes the private legacy repository and credentials. The original AGPL-3.0 license is preserved. Five upstream source commits, sanitized snapshots and route corrections are recorded in src/tools/provenance.json. sync:api --check validates the packaged snapshot; --latest reports source-head changes for human review and never overwrites released schemas automatically.

20. FAQ

Selected native FluentCRM, FluentCommunity and Fluent Forms REST routes on the exact HTTPS WordPress site you configure. It includes one WordPress current-user read and local profile/schema/batch/snapshot helpers.

Yes. CRM, Forms, Boards, Cart and Support document separate official MCP integrations. This companion offers a combined local task workflow for the reviewed subset; official product-specific features remain distinct.

Yes. wp fluent_crm and wp fluentform are official WP-CLI commands running in WordPress. This package provides remote Node task commands and local stdio MCP. It does not replace native email sending or maintenance commands.

It implements shared remote task commands, exact private site profiles, mandatory local approval, direct read-only refusal, reviewed ordered CRM/Community changes and bounded private snapshots. These are specific implemented behaviors, not a claim of universal superiority.

Yes. Codex can register the local stdio MCP or invoke fluent-wp-cli with SKILL.md and --agent. Claude Code is an optional separate client.

The package targets Node22+ on macOS, Windows and Linux. CI covers Node22/24 on each OS plus a desktop archive build. Native GUI and provider acceptance require separate evidence.

The versioned .mcpb vendors production dependencies for compatible Claude Desktop custom extensions. Configure the sensitive Application Password or private file plus site/user. Manual bundle updates require installing the new release.

Create a dedicated WordPress Application Password for the intended least-privileged user. Never use the main login password, a Bearer token or browser cookies. Keep it in private settings or an owner-private file outside repositories.

Yes. Each uniquely named profile contains its own site_url, username and password method. --account selects an exact label. Missing/rejected credentials never fall back to another site or global password.

No. doctor checks local settings. doctor --network deliberately reads only the current WordPress user and reports its ID. Plugin permissions, Pro eligibility, ownership and mutation outcomes are separate.

Requested writes are available with explicit --confirm or confirm:true. --agent/--yes never authorize. READ_ONLY hides and directly refuses all thirteen confirmed operations, including the stateful Forms report and private snapshot save.

The pinned Forms service may migrate stored report metadata when ff_form_report is called. The package classifies that side effect as confirmed and excludes the report from read-only and snapshot read helpers.

No. Its hash binds exact site/profile/user, inputs/order/compiled requests and packaged schemas. It is local input review, not provider ownership, a server-state lock or the official Forms single-use five-minute token.

Execution stops at the first failure and reports known results plus failed/unattempted indices. There is no rollback, automatic retry or continuation. Inspect native state before deliberately repeating unknown work.

No. It contains one to twenty selected native responses/pages, at most5 MiB combined. It does not automatically paginate or create an atomic database backup. Stored private records remain sensitive.

No. save_site_snapshot exclusively creates a new absolute file with mode0600 and returns only path/bytes/SHA-256 metadata. It removes only its own new file on failure. Restrict Windows and parent-directory ACLs separately.

This subset reads CRM campaign/automation information and Community scheduled posts. It does not invent campaign sending, scheduling, database maintenance or official MCP-only endpoints. Some contact/feed changes can still trigger real messages.

It depends on the client. In Codex, finding the command that adds a note to a CRM contact took a median of 83,099 input tokens over the CLI and 76,746 over MCP. In Claude Code the CLI costs nothing until it is used, plus about 1,385 tokens for SKILL.md once, where the server costs about 1,294 tokens a message with tool search and 25,728 with every tool loaded. Section 7 has how each was measured.

The code is free under the preserved AGPL-3.0 license. WordPress hosting, paid Fluent Pro features, email delivery and native account limits remain separate. Read THIRD_PARTY_NOTICES.md for bundled dependency licenses.

Fresh npx @latest launches resolve the current npm release; reconnect running clients. Global installs need npm update -g and desktop bundles need reinstalling. Remove only the requested registration/package, revoke the dedicated Application Password separately and review retained private snapshots.

Questions

Open a secret-free issue. Read CONTRIBUTING.md and SECURITY.md.

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

If this is useful, star the repo and come say hi on X.

Dependencies

Runtime: Slipway, which brings the MCP TypeScript SDK, plus Ajv and ajv-formats. Development: TypeScript, Vitest, Vite and MCPB. Exact locked versions appear above. Packaging tools are excluded from desktop runtime.

License

Preserves AGPL-3.0 and existing private legacy history. Read THIRD_PARTY_NOTICES.md. Fluent WordPress service terms and trademarks remain separate.


© 2026 Navid Media. Made with ❤️ by Navid Moazzez.

Available Tools

54 tools
fc_analytics_member_activityfc analytics member activityA
Read-onlyIdempotent

Returns a gap-filled time series of member signups across the requested range.

Controller: MembersReportsController@activity Route source: fluent-community-pro/app/Http/Routes/api.php:81 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

A3.6/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, so the safety profile is covered. The description adds genuine non-annotation context: the response is gap-filled (missing intervals are filled), it requires specific report permissions, and it is scoped to signups rather than being an audience export. It does not, however, describe pagination 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.

Conciseness3/5

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

The purpose sentence is well front-loaded, and the permissions note earns its place. The embedded 'Controller: MembersReportsController@activity' and 'Route source: fluent-community-pro/app/Http/Routes/api.php:81' are implementation metadata that do little to help an agent select or invoke the tool, diluting an otherwise compact 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 read-only analytics tool with no output schema, the description conveys what is returned (a gap-filled signup time series) and the authorization requirement. The lone parameter is fully documented in the schema. It is largely complete, missing only expected response granularity or how the gap-filling behaves.

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% on the single 'account' parameter, so the schema already explains that it is an exact configured profile label, not a tenant/provider ID. The description adds nothing about the parameter, which is acceptable at full coverage but earns no extra credit.

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: 'Returns a gap-filled time series of member signups.' This clearly distinguishes it from sibling analytics tools, and the closing caveat 'not a whole-site audience export' further scopes the output. It stops short of naming the adjacent analytics siblings (fc_analytics_overview, fc_analytics_top_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 description implies usage through two hints: it requires FluentCommunity Pro native report permissions and it is not a whole-site audience export, which rules out some misuses. However, it never says when to choose this over the other fc_analytics_* tools or states prerequisites in a when-to-use form, leaving selection largely to inference.

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

fc_analytics_overviewRead one native Community member reportC
Read-onlyIdempotent

Retained legacy selector mapped to four fixed reviewed native Pro report routes. Not a whole-community analytics export; native report permissions apply.

ParametersJSON Schema
NameRequiredDescriptionDefault
typeNoOne native report, default top-members.
accountNoExact configured private site profile label, not a verified site-owner identity.

TDQS

C2.9/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, so the safety profile is fully covered. The description adds that native report permissions apply, which is useful auth context, but does not explain return behavior or the fixed route mapping beyond the enum.

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 key constraint, with no filler. However, the phrasing is somewhat cryptic ('retained legacy selector mapped to...') and could be clearer.

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 selector with full annotation coverage and 100% schema coverage, the description is adequate but does not explain how this tool relates to the four sibling analytics tools it shadows, leaving an agent uncertain about which to 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 coverage is 100% and the enum is documented in the schema, so the description has little to add. It mentions 'four fixed reviewed native Pro report routes' but does not clarify how the enum values map to those routes, adding marginal value.

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 it maps a selector to 'four fixed reviewed native Pro report routes', which implies a read operation, but never names what is being read (community member reports). The title partly compensates ('Read one native Community member report'), yet the description itself doesn't clearly state the resource or action, and the sibling tools already include explicit per-report tools (fc_analytics_top_members, etc.), which this selector shadows without clear 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?

It notes 'Not a whole-community analytics export' but gives no positive guidance on when to use this selector versus the sibling per-report tools or the dashboard stats. No conditions, 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.

fc_analytics_top_commentersfc analytics top commentersA
Read-onlyIdempotent

Returns the ten members who wrote the most comments within the requested range, each with their comment count.

Controller: MembersReportsController@topCommenters Route source: fluent-community-pro/app/Http/Routes/api.php:84 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

A3.9/5.0
Behavior4/5

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

With annotations declaring readOnlyHint=true, the agent already knows this is a safe read. The description adds valuable context beyond annotations: it requires FluentCommunity Pro native report permissions and clarifies the response is not a whole-site audience export. That permission requirement and scope limitation are useful behavioral details. It doesn't mention pagination or limits, but the top-ten cap is stated.

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?

One sentence states the core behavior, followed by a second sentence with controller and permission context. It is front-loaded and every sentence earns its place. No fluff or repetition.

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?

Given the tool is a read-only analytics report with no output schema, the description adequately covers what it returns (top ten members with comment counts) and the scope limitation and permission requirement. It does not cover pagination or rate limits, but these are likely not applicable for a top-ten list. The absence of an output schema means the description must convey what is returned, which it does.

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 schema description for the 'account' parameter is already 100% coverage, so the schema itself explains it well. The description adds nothing about the parameter, so baseline 3 would apply, but the description does clarify the date range scope implicitly via 'requested range.' Since the schema fully documents the parameter, a 3 or 4 is appropriate; the description adds marginal value by reinforcing the range concept. No parameter count beyond 1, and no required parameters, so this is fairly straightforward.

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: returns the ten members who wrote the most comments within a date range, each with their comment count. This is specific enough to distinguish it from siblings like fc_list_comments (lists comments) or fc_analytics_top_post_starters (top post starters). However, it doesn't explicitly differentiate itself from those siblings in the text, so a 4 rather than 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 specifying the range-based top-ten scope, but it never states when to use this tool versus alternatives like fc_analytics_top_members or fc_analytics_member_activity. No explicit when/when-not guidance or alternatives are given, so this is implied usage only.

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

fc_analytics_top_membersfc analytics top membersA
Read-onlyIdempotent

Returns ten member profiles ordered by lifetime points, drawn from those who joined within the requested range.

Controller: MembersReportsController@getTopMembers Route source: fluent-community-pro/app/Http/Routes/api.php:82 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already cover safety (readOnly, idempotent, non-destructive, openWorld), yet the description adds real value beyond them: an explicit permission requirement (FluentCommunity Pro native report permissions), a result-size cap of ten, and a scope caveat that this is not a whole-site export. Return format details (fields per profile) remain unspecified.

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?

Purpose is front-loaded in the first sentence, with permissions and scope limits following. The Controller and Route source lines are mostly provenance noise for an agent, but the overall definition stays compact and does not bury the operative 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?

With no output schema, the description carries the return-value burden and does state what comes back (ten member profiles ordered by lifetime points). Combined with the stated permission prerequisite and the readOnly/idempotent annotations, an agent has enough to call it correctly; only field-level return detail 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% for the single `account` parameter, so the schema already explains it as an exact configured private account profile label. The description's reference to 'the requested range' does not map to any declared parameter and adds no usable 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 (Returns), resource (member profiles), ordering (lifetime points), cardinality (ten), and cohort filter (joined within range). This is far more precise than a tautology, but it never names or contrasts the sibling analytics tools (top_commenters, top_post_starters, member_activity), so the agent must infer 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 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 explicit alternative is offered among the four sibling fc_analytics_* report tools. The negative note that it is 'not a whole-site audience export' sketches a scope boundary, but the agent is still left to infer which report to pick.

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

fc_analytics_top_post_startersfc analytics top post startersA
Read-onlyIdempotent

Returns the ten members who published the most posts within the requested range, each with their post count.

Controller: MembersReportsController@topPostStarter Route source: fluent-community-pro/app/Http/Routes/api.php:83 Requires FluentCommunity Pro native report permissions; the response is not a whole-site audience export.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

A3.6/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real value beyond them: it discloses the FluentCommunity Pro native report permission requirement and the fact that the result is bounded to ten members rather than a full audience export.

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 first sentence is well front-loaded and earns its place. The controller/route-source line is internal implementation metadata that gives an agent no actionable guidance and dilutes 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?

With no output schema, the description correctly states the return shape (ten members plus post counts), and it notes the permission requirement. Only a slightly fuller statement of the time-range expectation would make it fully self-contained.

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 optional 'account' param is fully documented in the schema. The description adds nothing about how the account label interacts with the report scope, 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+metric: the ten members with the most posts in the requested range, each with a post count. It is clearly distinguishable from comment-oriented siblings, though it never explicitly contrasts itself with fc_analytics_top_members, which could also sound like a ranked member list.

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?

Usage is implied by the reporting context and the permission note, and the trailing clause rules out one misuse (it is not a whole-site audience export). But there is no explicit when-to-use vs. the sibling analytics tools (top_members, top_commenters, member_activity).

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

fc_course_lessonsfc course lessonsB
Read-onlyIdempotent

Returns the lessons of a course in display order, optionally narrowed to one section.

Controller: CourseAdminController@getLessons Route source: fluent-community/Modules/Course/Http/course_api.php:52

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
topic_idNoTopic ID read via `$request->get()` in getLessons().
course_idYesCourse ID extracted from the URL path.

TDQS

B3.4/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 behavior, so the safety profile is covered. The description adds the 'display order' result characteristic, which is genuinely useful beyond annotations, but the controller/route lines are provenance metadata rather than behavioral disclosure.

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 opening sentence is well front-loaded and wastes nothing, but the trailing 'Controller' and 'Route source' lines are developer-oriented provenance that do not help an agent select or invoke the tool. Useful content is roughly one of three lines.

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 listing tool with full schema coverage and annotations covering safety, the definition is nearly sufficient. The remaining gap is return shape (pagination, lesson fields), which matters somewhat since no output schema exists, but the ordering and scoping behavior are stated.

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 course_id, topic_id and account. The description only echoes the section-narrowing role of one parameter and adds no syntax, format, or edge-case detail, 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 ('Returns the lessons of a course') plus the ordering guarantee and the optional section narrowing. It is clearly distinguishable from fc_get_course and fc_course_students, though it never names those siblings to sharpen 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 Guidelines3/5

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

The phrase 'optionally narrowed to one section' implies when to pass topic_id, which is real usage guidance. However there is no explicit when-not, no prerequisites, and no routing to an alternative tool for related needs.

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

fc_course_studentsfc course studentsB
Read-onlyIdempotent

Returns the paginated roster of a course, each student carrying their enrolment pivot and their completion percentage.

Controller: CourseAdminController@getCourseStudents Route source: fluent-community/Modules/Course/Http/course_api.php:29

ParametersJSON Schema
NameRequiredDescriptionDefault
searchNoSearch read via `$request->getSafe()` in getCourseStudents().
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoSort By read via `$request->getSafe()` in getCourseStudents().created_at
sort_dirNoSort Dir read via `$request->getSafe()` in getCourseStudents().
course_idYesCourse ID extracted from the URL path.

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 safe-read profile is covered. The description adds 'paginated', which is genuinely useful behavioral context, but it never explains the pagination mechanics (page/cursor params, defaults) even though no such parameter appears 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?

The valuable sentence is front-loaded and compact. The trailing controller/route-source block is implementation metadata of limited use to an agent selecting the tool, but it is short and does not bury the main point.

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 return-value burden and does so reasonably: it names the roster, the pivot, and the completion percentage. For a read-only, annotation-covered list tool this is close to sufficient; only pagination mechanics are left 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 the schema already documents all five parameters, and the description adds nothing about search, account, sort_by, or sort_dir semantics. Baseline 3 applies. It does not clarify the 'account' label-versus-ID distinction, which the schema already handles.

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: 'Returns the paginated roster of a course'. It even describes the item payload (enrolment pivot, completion percentage), so an agent knows exactly what it gets. It does not name or contrast with any 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?

There is no when-to-use guidance, no exclusions, and no reference to alternatives (e.g. fc_space_members or fc_list_courses). Usage is only weakly implied by 'roster of a course'.

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

fc_create_commentfc create commentA
Destructive

Posts a comment or a threaded reply on a feed item, renders its Markdown, links any attached media and bumps the post comment count.

Controller: CommentsController@store Route source: fluent-community/app/Http/Routes/api.php:56 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
commentNo
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

TDQS

A4.3/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds non-obvious behavior: it renders Markdown, links attached media, mutates the parent feed's comment count, may trigger hooks/announcements/automations affecting other people, and must not be retried. That is exactly the extra context annotations cannot carry.

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 first sentence front-loads purpose and side effects and the confirmation/no-retry warnings come last, which is the right order. The 'Controller:' and 'Route source:' lines are largely noise for an agent making a tool-selection decision.

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 non-idempotent, destructive create tool with no output schema, the description covers confirmation requirements, blast radius via hooks/automations, and retry behavior. Return-value shape is unspecified, but that is a minor gap given the annotations and high schema coverage.

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 high (83%) and the schema itself explains account, confirm, feed_id, payload and payload_file semantics, so the description need not repeat them. However, 'threaded reply' implies parent/thread targeting that has no corresponding parameter, adding slight ambiguity rather than clarity; baseline 3.

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 and resource ('Posts a comment or a threaded reply on a feed item') and enumerates the concrete side effects (Markdown rendering, media linking, comment-count bump). This clearly separates it from fc_update_comment, fc_delete_comment and fc_list_comments without opening their schemas.

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?

The description gives a real precondition ('Explicit local confirmation is required') and a caution against retrying, which shapes when and how to call it. It stops short of naming sibling alternatives or stating when-not to use this tool, so it is context-rich but not fully explicit routing.

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

fc_create_feedfc create feedB
Destructive

Creates a post, renders its Markdown, attaches media and topics, and returns the transformed post ready to prepend to the feed.

Controller: FeedsController@store Route source: fluent-community/app/Http/Routes/api.php:46 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
spaceNo
titleNo
surveyNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
messageNo
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
topic_idsNo
content_typeNo
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.
send_announcement_emailNo

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, openWorldHint=true and idempotentHint=false, but the description adds real value beyond them: the side effects on other people (hooks, announcements, automations), the confirmation requirement, and the 'No retries' semantic. It stops short of describing the return payload's shape, which keeps it below 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?

The behavioral content is front-loaded in a single dense sentence, followed by confirmation and side-effect warnings. The Controller/Route source lines are boilerplate of marginal value to an agent but do not bloat the definition significantly.

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, 11-parameter tool with no output schema and low schema coverage, the description covers behavior and side effects well but leaves parameter semantics and payload construction largely unexplained. It is minimally adequate, not complete.

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 11 parameters and only 36% schema description coverage, the description should compensate but does not. It never explains space, title, survey, message, topic_ids, content_type, or send_announcement_email, nor how payload/payload_file/body flags interact, leaving more than half the parameters undocumented in both places.

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 and resource ('Creates a post') and enumerates the sub-actions (renders Markdown, attaches media and topics, returns the transformed post). It implicitly separates the tool from fc_update_feed/fc_delete_feed by framing it as the creation path, though it never names 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?

It states that 'explicit local confirmation is required' and that hooks/announcements/automations may affect other people, which implies when caution is needed, but it gives no guidance on when to choose this tool over alternatives or what prerequisites exist beyond the confirmation flag. 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.

fc_delete_commentfc delete commentA
Destructive

Deletes a comment, recounts the comments on its post and hands any attached media to the media cleanup hook.

Controller: CommentsController@deleteComment Route source: fluent-community/app/Http/Routes/api.php:60 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.
comment_idYesComment ID extracted from the URL path.

TDQS

A4.1/5.0
Behavior5/5

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

Annotations already declare destructiveHint=true and idempotentHint=false, but the description goes well beyond them: it names the cascading recount, the media cleanup hook, the fact that hooks/announcements/automations can affect other people, and the no-retry policy. That is exactly the extra context an agent needs for a non-idempotent destructive call.

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 action and its side effects are front-loaded in the first sentence, and the confirmation/no-retry warning follows. The controller and route-source lines are developer-facing provenance that consume space without helping an agent decide or invoke, which keeps this short of 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, non-idempotent mutation with no output schema, the description covers the behavioral consequences (recount, media cleanup, downstream hooks) and the invocation caveat (confirm, no retries). Only the authorization precondition for deleting a given comment is left unstated.

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, feed_id and comment_id are all documented in the schema itself. The description adds no syntax, format, or constraint 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.

Purpose5/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 comment') and immediately enumerates the cascading side effects (recount on post, media cleanup hook). An agent can distinguish it from fc_update_comment and fc_create_comment without opening any schema.

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 flags that 'Explicit local confirmation is required' and that there are 'No retries', which is actionable invocation guidance, but it never states when to prefer this tool over alternatives or what precondition (comment ownership, permissions) makes deletion valid. 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.

fc_delete_feedfc delete feedA
Destructive

Deletes a post from the community.

Controller: FeedsController@deleteFeed Route source: fluent-community/app/Http/Routes/api.php:64 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.

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, and idempotentHint=false, so the destructive and non-idempotent nature is covered. The description adds valuable context beyond annotations: it warns about secondary effects on other people via hooks/announcements/automations and explicitly states 'No retries', which is a non-obvious behavioral constraint. This is meaningful additional disclosure.

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 first sentence is concise and front-loaded. However, the inclusion of controller class and route source file paths is implementation detail that doesn't help an agent decide or invoke the tool correctly, adding clutter without utility.

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?

Given the destructive nature and no output schema, the description covers the critical behavioral aspects: confirmation requirement, side effects on others, and no retries. It doesn't explain what happens to associated comments or data, but for a delete operation with annotations declaring destructiveness, this is largely sufficient.

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 baseline is 3. The description doesn't explain parameters further, but the schema already documents all three parameters (account, confirm, feed_id) clearly. The description's note about 'explicit local confirmation' reinforces the 'confirm' parameter's intent, adding slight value 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?

Clearly states a specific verb+resource: deletes a post from the community. Distinguishes it from sibling fc_delete_comment and fc_update_feed by naming the resource. However, it uses 'post' while the tool and siblings use 'feed', a minor naming inconsistency that slightly reduces precision.

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 mentions that explicit local confirmation is required and that hooks/announcements/automations may affect others, which implies caution. But it never explicitly says when to use this tool versus alternatives, nor does it name related tools like fc_update_feed or fc_list_feeds. The guidance 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.

fc_get_coursefc get courseA
Read-onlyIdempotent

Returns one course in its editable form, with the lock screen configuration, the attached category ids and : when it has students : the completion count and average progress.

Controller: CourseAdminController@findCourse Route source: fluent-community/Modules/Course/Http/course_api.php:24

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
course_idYesCourse ID extracted from the URL path.

TDQS

A3.7/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 genuine context beyond that: the response is the editable (not public) representation, and some fields (completion count, average progress) are returned conditionally 'when it has students'. Auth/scope details for the account parameter are left 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?

The payload description is front-loaded in a single dense sentence with no waste. The trailing 'Controller:'/'Route source:' line is code-level provenance that contributes little to tool selection, but it is short and clearly separated from the functional description.

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 single-record fetch with no output schema, the description adequately documents what comes back, including the conditional student metrics. Safety is covered by annotations, so the only real gap is where the course data is scoped from (account/auth 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%, so both parameters (including the non-obvious 'private account profile label' distinction) are already fully documented in the schema. The description adds nothing further about 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.

Purpose4/5

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

The first sentence states a specific verb and resource ('Returns one course') and enumerates the payload (lock screen configuration, category ids, completion count, average progress), which cleanly separates it from fc_list_courses and fc_course_students. It stops short of naming those siblings explicitly, so an agent must infer 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?

Usage is implied rather than stated: the 'editable form' framing signals an admin/edit-context fetch of a single record, which is reasonable guidance. There is no explicit when-to-use vs when-not, no mention of prerequisites, and no routing to fc_list_courses for bulk retrieval.

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

fc_get_feedfc get feedA
Read-onlyIdempotent

Returns a single post by numeric id; the id is resolved to a slug and then handled exactly as the by-slug endpoint.

Controller: FeedsController@getFeedById Route source: fluent-community/app/Http/Routes/api.php:53

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
contextNoProse-documented delegated edit context, requiring native post edit access.
feed_idYesFeed ID extracted from the URL path.

TDQS

A3.5/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 one genuinely useful behavioral detail (numeric id is resolved to a slug and then handled exactly as the by-slug endpoint), but says nothing about auth requirements or what a missing/foreign id yields.

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 purpose sentence is front-loaded and tight, but the trailing 'Controller:' and 'Route source:' lines are implementation metadata that does not help an agent select or invoke the tool, diluting an otherwise efficient 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 simple read-only single-entity fetch this covers the basics, and annotations carry the safety profile. With no output schema, however, the description gives no hint of the returned post shape or error behavior, leaving a modest gap for an agent that must interpret the result.

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 schema already explains account, context (with enum) and feed_id. The description adds only the id-resolution behavior, which is minor semantics beyond the schema.

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 and resource ('Returns a single post by numeric id') and clarifies the id-to-slug resolution, which distinguishes it from fc_list_feeds and the other fc_* feed tools. An agent can tell exactly what it fetches 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 Guidelines3/5

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

Usage is implied by 'returns a single post by numeric id' versus the listing sibling fc_list_feeds, but there is no explicit when-to-use statement, no exclusion of the by-slug/list alternatives, and no guidance on the account/context parameters beyond what the schema states.

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

fc_get_profilefc get profileB
Read-onlyIdempotent

Returns one member public profile by username, with the navigation tabs the portal should render for that member.

Controller: ProfileController@getProfile Route source: fluent-community/app/Http/Routes/api.php:89

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
usernameYesUsername extracted from the URL path.

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, destructiveHint=false, and openWorldHint, so the safety profile is fully covered. The description adds one genuinely new behavioral detail beyond those structured fields: the response carries the navigation tabs the portal should render for that member.

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 first sentence is front-loaded and efficient. The trailing Controller/Route source block is implementation provenance that does not help an agent select or invoke the tool, so the definition is longer than it needs to be.

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 annotation coverage and no output schema, the description is nearly sufficient, and it goes one step further by hinting at the navigation-tab payload. Only the absence of any usage routing keeps it from being 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%, and the account parameter is carefully documented as a configured label rather than a tenant ID. The description only echoes the username lookup, adding nothing 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: 'Returns one member public profile by username'. The scope word 'public profile' and 'member' distinguishes it from contact-oriented siblings like fcrm_get_contact, though it does not name an alternative explicitly.

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 routing guidance. An agent handling a request for member data has no stated basis for choosing this over fcrm_get_contact or get_current_user.

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

fc_get_spacefc get spaceB
Read-onlyIdempotent

Returns one space with its settings, topics, the current user membership and the permissions they hold inside it.

Controller: SpaceController@getBySlug Route source: fluent-community/app/Http/Routes/api.php:10

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesSpaceSlug extracted from the URL path.
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

B3.1/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 fully covered. The description adds useful content about scope of the return (membership and permissions are user-specific), but says nothing about auth requirements, behavior for a missing/unauthorized slug, or the role the `account` parameter plays.

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 first sentence is efficient and front-loaded, but the Controller/Route source block is provenance metadata that does not help an agent select or invoke the tool, so not every line 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, the description must carry return-value burden, and it does partially list the payload contents. However, it omits error/empty behavior for an invalid slug and how the 'current user' context is resolved relative 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% — `slug` and `account` are both documented in the input schema, including the non-obvious clarification that `account` is a profile label, not a tenant ID. The description adds nothing 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.

Purpose4/5

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

States a specific verb and resource ('Returns one space') and enumerates what comes back (settings, topics, membership, permissions), which cleanly separates it from `fc_list_spaces` and `fc_space_members`. It stops short of naming those siblings explicitly, so differentiation is implied rather than stated.

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 gives no when-to-use, prerequisites, or alternative routing. It never says to prefer this over `fc_list_spaces` when a slug is known, nor what to do if the slug is unknown.

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

fc_list_commentsfc list commentsA
Read-onlyIdempotent

Returns every comment on a post in chronological order, with each author profile attached and the current user liked state flagged.

Controller: CommentsController@getComments Route source: fluent-community/app/Http/Routes/api.php:55

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
feed_idYesFeed ID extracted from the URL path.

TDQS

A4/5.0
Behavior4/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 covered. The description adds valuable behavioral context beyond annotations: comments are returned in chronological order, each includes the author profile, and the current user liked state is flagged. However, it does not mention pagination behavior or rate limits, which could be relevant for a list operation.

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?

The description is a single, information-dense sentence that front-loads the key behavior (returns comments) and includes important details (chronological order, author profiles, liked state) without any filler. The additional controller and route source lines are concise and potentially useful for debugging or tracing.

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 annotations covering the safety profile and no output schema, the description provides substantial behavioral context (ordering, included fields, liked state). However, it does not address pagination or potential limits, which could be important for an agent calling this tool with large feeds. The controller and route source add transparency but not call-related completeness.

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 both parameters (account and feed_id). The description mentions 'on a post' but does not elaborate on the feed_id parameter or account parameter beyond what the schema provides. Baseline 3 is appropriate when schema does the heavy lifting.

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 (Returns) and resource (every comment on a post) with scope details: chronological order, author profiles attached, and current user liked state flagged. This clearly distinguishes it from fc_create_comment, fc_update_comment, and fc_delete_comment, which modify comments rather than list them.

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 (listing comments for a given feed), but does not explicitly state when to use this tool versus alternatives like fc_get_feed or fc_list_feeds. There are no exclusions or prerequisites mentioned. An agent can infer the purpose but receives no guidance on alternatives.

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

fc_list_coursesfc list coursesB
Read-onlyIdempotent

Returns the paginated list of courses the current user may manage, each with its student count and its section and lesson totals.

Controller: CourseAdminController@getCourses Route source: fluent-community/Modules/Course/Http/course_api.php:22

ParametersJSON Schema
NameRequiredDescriptionDefault
searchNoSearch read via `$request->getSafe()` in getCourses().
statusNoStatus read via `$request->getSafe()` in getCourses().
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoSort By read via `$request->getSafe()` in getCourses().latest
topic_slugNoTopic Slug read via `$request->getSafe()` in getCourses().
with_categoriesNoWith Categories read via `$request->get()` in getCourses().

TDQS

B3.3/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 the safety profile is covered. The description still adds real value beyond that: the result set is permission-scoped to courses the user may manage, and each item carries student/section/lesson counts. It doesn't explain pagination mechanics despite claiming 'paginated', which keeps 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.

Conciseness3/5

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

The first sentence is front-loaded and information-dense, but the two trailing lines citing 'CourseAdminController@getCourses' and the route file/line are internal implementation trivia that do not help an agent select or invoke the tool. Roughly a third of the description is noise.

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 usefully describes what each returned course contains, and there are no required parameters to explain. However, it advertises pagination while the schema exposes no page/cursor/limit parameter and the description gives no paging instructions, and filter semantics for search/status/sort_by 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 all six parameters, and the description adds no per-parameter meaning (nothing about search matching, status values, or sort behavior). Baseline 3 is correct when structured fields carry the full 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 and resource ('Returns the paginated list of courses') plus a meaningful scope ('the current user may manage') and the payload contents (student count, section and lesson totals). This clearly separates it from resource-adjacent siblings like fc_list_spaces and fc_get_course, though it never names an alternative explicitly.

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 statement of when to prefer fc_get_course or fc_course_students, and no mention of how the filter parameters (search, status, topic_slug) should be used. The only usage signal is the implied 'may manage' permission scope, which the agent must infer.

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

fc_list_feedsfc list feedsA
Read-onlyIdempotent

Returns a page of posts the current user is allowed to read, transformed for display, with the pinned post of a space returned separately on the first page.

Controller: FeedsController@get Route source: fluent-community/app/Http/Routes/api.php:45

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage read via `$request->get()` in get().
spaceNoSpace read via `$request->get()` in get().
searchNoSearch read via `$request->getSafe()` in get().
statusNoStatus read via `$request->getSafe()` in get().
accountNoExact configured private account profile label; not a tenant or provider account ID.
user_idNoUser ID read via `$request->getSafe()` in get().
per_pageNoPer Page read via `$request->get()` in get().
search_inNoSearch In read via `$request->get()` in get().
topic_slugNoTopic Slug read via `$request->getSafe()` in get().
order_by_typeNoOrder By Type read via `$request->getSafe()` in get().
disable_stickyNoDisable Sticky read via `$request->get()` in get().

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/non-destructive, so safety is covered. The description adds genuinely useful behavior: results are permission-filtered ('current user is allowed to read'), transformed for display, paginated ('a page'), and the space's pinned post is surfaced separately on the first page only. That pinned-post edge case is non-obvious and valuable.

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 purpose sentence is front-loaded and information-dense with no filler. The two trailing controller/route lines are developer metadata that do not help an agent invoke the tool, which slightly dilutes an otherwise tight 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?

With no output schema, the description still sketches the return shape (a page of display-transformed posts plus a separately returned pinned post), and the 100%-covered schema handles the 11 parameters. Pagination defaults and sort ordering are not addressed, but the core behavior an agent needs is present.

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 11 parameters are documented in the schema and the baseline is 3. The description mentions 'page' and 'first page' but adds no syntax, format, or interaction detail (e.g., how search/search_in combine, per_page limits) beyond what the schema already 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 ('Returns a page of posts the current user is allowed to read') with scope qualifier. However it does not distinguish itself from siblings like fc_get_feed or fc_list_spaces, so an agent gets a clear purpose but no sibling differentiation. The controller/route lines are metadata rather than 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?

The description says what it returns but never states when to use it versus alternatives such as fc_get_feed, fc_list_spaces, or fc_list_comments. No prerequisites, no exclusions, no routing guidance is provided.

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

fc_list_spacesfc list spacesB
Read-onlyIdempotent

Returns the paginated list of spaces with each one formatted for display, including the current user permissions and membership within it.

Controller: SpaceController@getAllSpaces Route source: fluent-community/app/Http/Routes/api.php:34

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account 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, destructiveHint=false and openWorldHint, so the safety profile is covered. The description usefully adds that results are paginated and that each item is enriched with the current user's permissions and membership, but gives no pagination mechanics or auth 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?

The purpose sentence is front-loaded and efficient, with no wasted words. The trailing Controller/Route metadata is developer-facing noise that does not help an agent select or invoke the tool, but it is a minor cost.

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?

There is no output schema, and the description does compensate by describing the shape of returned items (spaces plus user permissions and membership) and noting pagination. Combined with annotations covering the safety profile and a fully documented parameter, the definition is nearly complete, lacking only pagination mechanics.

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?

With one parameter and 100% schema description coverage, the schema already documents 'account' thoroughly (including the warning that it is not a tenant or provider account ID). The description adds nothing about the parameter, so the baseline of 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 ('Returns the paginated list of spaces') and adds scope detail about what each entry contains. It is clearly distinct from fc_get_space (singular) and fc_space_members, though it never names a sibling to differentiate explicitly.

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 fc_get_space, fc_space_members, or the analytics siblings, nor any exclusions or prerequisites. The agent must infer usage entirely from the purpose sentence.

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

fc_react_to_feedfc react to feedA
Destructive

Adds or removes the current user reaction on a post and returns the updated count : a second route onto the same behaviour as the reactions toggle endpoint.

Controller: CommentsController@addOrRemovePostReact Route source: fluent-community/app/Http/Routes/api.php:59 Toggle semantics are not idempotent; inspect state before deliberately repeating. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
removeNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
react_typeNo
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

TDQS

A3.5/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, and the description reinforces these with 'Toggle semantics are not idempotent' plus operational detail the annotations cannot express: requiring explicit user confirmation, prohibiting retries, and warning that hooks/announcements/automations may affect other people. It also discloses the return value ('returns the updated count'), which matters because there is no output schema.

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 first sentence is front-loaded and dense with real constraints, but the 'Controller: `CommentsController@addOrRemovePostReact`' and 'Route source: ...' lines are implementation trivia that do not help an agent select or invoke the tool. The useful safety constraints are appended after that noise.

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 7 parameters, a nested payload object and no output schema, the description does a fair job on safety and return value but leaves the reaction-type vocabulary and remove semantics entirely undocumented. It is usable but not complete for a mutation tool with this parameter surface.

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 71%, in the middle band where the description should partly compensate, yet it says nothing about any parameter. The two core parameters of this action, 'remove' and 'react_type', have no description in either the schema or the description, so the agent cannot learn accepted react_type values or the exact semantics of the remove flag.

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 ('Adds or removes the current user reaction on a post and returns the updated count'), so the agent knows exactly what operation it performs and that it is a toggle. It does not name a sibling tool for contrast, though no sibling in the list performs reactions, so the disambiguation burden is low.

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 concrete operating conditions: 'inspect state before deliberately repeating', 'Explicit local confirmation is required', and 'No retries', which tells the agent how and when to invoke it safely. It does not name an alternative tool to prefer, but no reaction alternative exists in the sibling set, so the guidance is effectively complete.

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

fcrm_add_contact_notefcrm add contact noteA
Destructive

Add a new note to a contact. The note description supports SmartCode/merge tags which are parsed before saving. If created_at is not provided, it defaults to the current WordPress time.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe contact ID.
noteNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

TDQS

A3.6/5.0
Behavior4/5

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

Beyond the annotations (destructive, non-idempotent, openWorld), the description discloses that SmartCode/merge tags are parsed before saving, that created_at defaults to the current WordPress time, that a specific capability is enforced by SubscriberPolicy::verifyRequest(), and that hooks/announcements/automations may affect other people with no retries. That is meaningful side-effect and auth context. It does not detail reversibility or return behavior, 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.

Conciseness3/5

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

The purpose is front-loaded and the note-specific behavior is compact, but the policy boilerplate ('Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group') is internal jargon that adds bulk without actionable meaning for the agent. The formatting and bold headers aid scanning, so it is adequate rather than wasteful.

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 6-parameter, nested, destructive mutation with no output schema, the description covers capability requirements, confirmation, side effects, and retry policy, which is substantial. It does not explain the note sub-object fields or the payload/account routing parameters, leaving a modest gap, but the absence of an output schema means return values need not be described.

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, establishing a baseline of 3. The description adds the merge-tag parsing behavior for the note description and reinforces the created_at default, but says nothing about the account, confirm, payload, or payload_file parameters.

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 opening sentence states a specific verb and resource ('Add a new note to a contact'), which is enough to distinguish it from list/read siblings like fcrm_contact_notes or fcrm_get_contact. It stops short of explicitly naming the sibling it is not, so an agent must infer the add-vs-read split from the verb 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 supplies real prerequisites — a required capability and explicit local confirmation — which frame when the call is legitimate. However, it never names an alternative tool or states a when-to-use/when-not-to-use condition relative to siblings, and the 'which one applies depends on the action being performed' clause is vague rather than directive.

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

fcrm_automation_reportfcrm automation reportA
Read-onlyIdempotent

Retrieve statistical reporting data for a specific automation funnel. Returns aggregated stats generated by the Reporting service.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe funnel ID.
accountNoExact configured private account profile label; not a tenant or provider account ID.

TDQS

A3.5/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint, so safety is covered. The description adds real context beyond them: the auth capability required (fcrm_read_funnels or fcrm_write_funnels) and that it is enforced by FunnelPolicy::verifyRequest(), which tells the agent a request may be rejected on capability grounds.

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?

Purpose and return shape are front-loaded in the first two sentences, which is efficient. The trailing policy boilerplate ('_Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group._') is mildly noisy but short.

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 2-parameter tool with annotations and no output schema, the description covers purpose, return nature, and the authorization gate. It omits how the funnel ID is obtained and how it relates to the other stats/report tools, but nothing essential to invoking 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%, including a precise note that 'account' is a configured private account profile label, not a tenant/provider ID. The description adds nothing about either parameter, 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: 'Retrieve statistical reporting data for a specific automation funnel', and adds what the payload is ('aggregated stats generated by the Reporting service'). It does not differentiate from sibling reporting tools like fcrm_campaign_stats or fcrm_dashboard_stats, so an agent cannot tell which stats endpoint to pick without inspecting 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?

There is no when-to-use or when-not-to-use guidance relative to the many sibling analytics tools. The 'Required capability' note is an authorization prerequisite, not usage guidance about choosing this tool over alternatives.

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

fcrm_campaign_statsfcrm campaign statsA
Read-onlyIdempotent

Get overview statistics for a campaign including sent count, email status breakdown, and open/click analytics. This is a lighter-weight alternative to the full campaign status endpoint, suitable for dashboard widgets or summary views.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe campaign ID.
accountNoExact configured private account profile label; not a tenant or provider account ID.

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/openWorld, so the safety profile is covered. The description adds meaningful context beyond that: the required capability (fcrm_read_emails or fcrm_manage_emails) and the policy (CampaignPolicy::verifyRequest) enforcing it, which is real value for an agent.

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?

Purpose is front-loaded in the first sentence, with the usage framing immediately after. The capability/policy note is somewhat verbose but earns its place as actionable context; nothing is padded.

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 usefully enumerates the returned metrics, and annotations plus the capability note cover the safety and auth picture. An agent has enough to invoke it correctly, though return shape/pagination detail is 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 both the required id and the account parameters are already documented in the schema. The description adds no format, syntax, or meaning beyond what the structured fields provide, 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 ('Get overview statistics for a campaign') and enumerates the metrics returned (sent count, status breakdown, open/click analytics). It differentiates from the fuller status endpoint, though that alternative is not named by its exact sibling identifier (e.g., fcrm_get_campaign).

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?

Frames this as a 'lighter-weight alternative' to the full campaign status endpoint and gives concrete scenarios ('dashboard widgets or summary views'). It implies when to prefer it over the heavier endpoint but does not state explicit exclusions for 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.

fcrm_contact_emailsfcrm contact emailsA
Read-onlyIdempotent

Retrieve a paginated list of emails sent to a contact. Supports filtering by open/click status. Can also show FluentSMTP logs when the tab parameter is set to fluentsmtp.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe contact ID.
tabNoEmail source tab. Use `fluentsmtp` to show FluentSMTP logs instead of CRM campaign emails.crm
pageNoPage number.
filterNoFilter emails by engagement status.
accountNoExact configured private account profile label; not a tenant or provider account ID.
per_pageNoNumber of emails per page.

TDQS

A4.1/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 goes beyond them by disclosing the authorization requirement and the policy that enforces it, which an agent needs before calling. It stops short of describing pagination metadata or result ordering, hence 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?

Three short sentences, front-loaded with what the tool returns, then the optional mode, then the permission requirement — nothing is buried. The trailing policy-implementation note ("Enforced by SubscriberPolicy::verifyRequest()") is somewhat internal and could be trimmed, which keeps this 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 read-only list tool with full schema coverage and annotations carrying the safety profile, the description covers purpose, filtering, mode switching and authorization. The absence of an output schema is acceptable here since the description states the returned entity (emails) and that results are paginated, though item shape and paging metadata remain unspecified.

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 (id, tab, page, filter, account, per_page) is already documented with types, defaults, enums and ranges. The description reinforces the tab and filter semantics but adds no format or interaction 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.

Purpose5/5

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

The description states a specific verb and resource ("Retrieve a paginated list of emails sent to a contact") and scopes it to a single contact, so an agent knows exactly what data comes back. It also names the two modes (CRM campaign emails vs. FluentSMTP logs), which no sibling tool provides, so the tool is unambiguous within this server.

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

Usage Guidelines4/5

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

It gives the condition for the alternate mode ("when the `tab` parameter is set to `fluentsmtp`") and states the required capability (`fcrm_read_contacts` or `fcrm_manage_contacts`), which is genuine prerequisite guidance. It does not contrast against neighbors like `fcrm_get_contact` or `fcrm_contact_notes`, but those are clearly different resources, so the omission is minor.

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

fcrm_contact_notesfcrm contact notesB
Read-onlyIdempotent

Retrieve a paginated list of notes for a contact. Supports searching notes by title. Each note includes the user who created it.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe contact ID.
pageNoPage number.
searchNoSearch notes by title.
accountNoExact configured private account profile label; not a tenant or provider account ID.
per_pageNoNumber of notes per page.
include_idNoId of a note that must appear in the response even when it falls outside the current page. When it is not already on the page it is returned separately as `included_note`, scoped to this contact.

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, and destructiveHint=false, so the description doesn't need to restate safety. It adds some context (pagination, search support, creator info) but doesn't explain pagination limits, auth enforcement details beyond the capability name, or response structure. With annotations covering the safety profile, a 3 is appropriate.

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 main purpose is front-loaded in the first sentence, and additional details follow succinctly. The capability and enforcement notes are separate and slightly verbose but still earned. Overall efficient with minimal waste.

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 and no output schema, the description covers the basics but is incomplete. It doesn't specify return format, sorting, or the exact behavior of include_id beyond what the schema mentions. The ambiguous capability note adds uncertainty rather than clarity.

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 itself. The description mentions searching by title and pagination, which maps to some parameters, but adds no syntax or format details beyond what the schema provides. Baseline 3 is correct 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?

The description states a specific verb and resource ('Retrieve a paginated list of notes for a contact') and adds scope details like title search and creator inclusion. It's clear but does not explicitly differentiate from the sibling 'fcrm_add_contact_note' or 'fcrm_contact_emails' to help the agent choose.

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 guidance, prerequisites, or alternatives. It mentions a required capability but frames it ambiguously ('which one applies depends on the action being performed'), leaving the agent to guess between fcrm_read_contacts and fcrm_manage_contacts.

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

fcrm_create_contactfcrm create contactA
Destructive

Create a new contact. If __force_update is set to yes, it will update an existing contact with the same email instead of returning an error. Optionally sends a double opt-in email.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
cityNoCity.
tagsNoTag IDs to assign.
emailNoContact email address. Must be unique unless `__force_update` is `yes`.
listsNoList IDs to assign.
phoneNoPhone number.
stateNoState or province.
prefixNoName prefix (e.g., Mr, Mrs, Ms).
sourceNoContact source.
statusNoContact subscription status.
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
countryNoTwo-letter country code.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
timezoneNoTimezone identifier.
last_nameNoLast name.
first_nameNoFirst name.
postal_codeNoPostal/zip code.
contact_typeNoContact type.
double_optinNoSend double opt-in confirmation email.
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.
date_of_birthNoDate of birth (YYYY-MM-DD).
__force_updateNoIf `yes`, updates existing contact with the same email instead of failing.
address_line_1NoAddress line 1.
address_line_2NoAddress line 2.

TDQS

A4.1/5.0
Behavior5/5

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

Goes well beyond the annotations by disclosing the required capability, the SubscriberPolicy::verifyRequest enforcement, the mandatory local-confirmation gate, downstream side effects on other people, the no-retry policy, and the upsert-versus-error behavior of `__force_update`. That is unusually rich behavioral context for a destructive, non-idempotent write.

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?

Purpose and upsert behavior are front-loaded and efficient. The closing capability/policy block is dense and slightly awkward ("`fcrm_read_contacts` or `fcrm_manage_contacts` : which one applies depends on the action being performed"), a mild structural blemish on otherwise tight prose.

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 24-parameter, nested-object, destructive write with no output schema, the description covers the critical unknowns: confirmation requirement, policy enforcement, duplicate-email behavior, opt-in email, and retry policy. Return values are unspecified but no output schema exists to anchor them, and the schema handles all field-level 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 the schema already documents every field. The description's notes on `__force_update` and double opt-in largely restate schema text ("instead of returning an error", "Send double opt-in confirmation email"), so it adds 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 and resource ("Create a new contact") and clarifies the upsert branch via `__force_update`, which meaningfully distinguishes it from fcrm_update_contact. It never explicitly names the update sibling, so the differentiation is inferable rather than stated.

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?

Clear conditions are given: explicit local confirmation is required, hooks/announcements/automations may affect other people, and no retries. The `__force_update` condition and the `confirm` flag guidance add real routing help, but no alternative tool (e.g. fcrm_update_contact) is named for the modify-existing case.

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

fcrm_dashboard_statsfcrm dashboard statsA
Read-onlyIdempotent

Retrieve overall dashboard statistics including active contacts count, campaigns count, emails sent, active automations, onboarding progress, quick links, recent contacts, recent campaigns, active automations list, and system recommendations.

Required capability: fcrm_view_dashboard

Enforced by ReportPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuinely useful context beyond the annotations by disclosing the required capability (fcrm_view_dashboard) and that it is enforced by ReportPolicy::verifyRequest(), which tells the agent a permission gate exists.

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 core content is front-loaded in a single enumeration sentence, which is efficient. The trailing capability/policy block is somewhat noisy and partially duplicates the annotation-level safety info, but it is short and does not bury the main point.

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 usefully enumerates the returned statistics, and it discloses the authorization requirement. For a zero-required-parameter read tool this is nearly complete; only routing guidance against the sibling analytics tools 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 the single 'account' parameter is documented in the schema as a private account profile label rather than a tenant/provider ID. The description adds nothing about the parameter, so the baseline of 3 applies since the schema carries the load.

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 (Retrieve) and resource (overall dashboard statistics) and enumerates exactly what the payload contains (active contacts, campaigns, emails sent, automations, onboarding, quick links, recent items, recommendations). It is clear what the tool does, though it does not explicitly distinguish itself from the closest analytics siblings such as fcrm_automation_report or fc_analytics_overview.

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 call this versus the many sibling analytics/report tools. The only usage-adjacent information is the required-capability note, which is an authorization constraint rather than a when-to-use rule.

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

fcrm_get_campaignfcrm get campaignA
Read-onlyIdempotent

Retrieve a single campaign by ID. Optionally include related data (template, subjects) via the with parameter. When viewCampaign is set, returns the campaign with its paginated emails. Also returns available email templates and the server's current time.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe campaign ID.
withNoInclude related data (e.g., `template`, `subjects`).
accountNoExact configured private account profile label; not a tenant or provider account ID.
viewCampaignNoIf set, returns the campaign with paginated emails instead of the standard response.

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/non-destructive, so the bar is lower, yet the description still adds real context: the required capability (fcrm_read_emails or fcrm_manage_emails), the enforcing policy (CampaignPolicy::verifyRequest()), and that templates and server time are returned. This auth/policy disclosure is genuine value beyond 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?

Purpose is front-loaded, followed by parameter behavior, then the auth requirement. Reasonably sized, though the policy/capability block reads as boilerplate that slightly dilutes the core sentence.

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 tool with full annotation coverage and 100% schema documentation, the description is nearly complete; it even sketches the return payload (templates, server time). No output schema exists but the description covers the salient return content adequately.

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 four parameters. The description restates the `with` and `viewCampaign` behavior (paginated emails vs standard response) but adds no syntax, format, or accepted-value detail beyond what the schema 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 specific verb+resource ('Retrieve a single campaign by ID'), which distinguishes it from the list-oriented sibling fcrm_list_campaigns by scoping to a single record. However, it never names the sibling explicitly, so differentiation is inferred rather than stated.

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?

Usage is implied by the 'by ID' framing and the conditional behavior of `with`/`viewCampaign`, but there is no explicit when-to-use guidance nor any statement about when to prefer this over fcrm_list_campaigns or fcrm_campaign_stats.

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

fcrm_get_contactfcrm get contactA
Read-onlyIdempotent

Retrieve a single contact by ID or email. Supports eager-loading related data like stats, custom values, custom field definitions, and commerce stats via the with[] parameter.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe contact ID.
withNoRelationships and extra data to include. Supported values: `stats`, `subscriber.custom_values`, `custom_fields`, `commerce_stat`.
accountNoExact configured private account profile label; not a tenant or provider account ID.
get_by_emailNoIf set, looks up the contact by email address instead of the path `id`.

TDQS

A3.7/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, so the safety profile is covered. The description adds real value beyond that by disclosing the required capability (`fcrm_read_contacts` or `fcrm_manage_contacts`) and the enforcing policy, which the agent needs before attempting the call.

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 core sentence is front-loaded and efficient. The capability block is somewhat heavy with bold markdown and internal policy naming, but it does carry actionable information rather than padding.

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 lookup with no output schema, the description covers the lookup key, the eager-loading option and the authorization requirement. It stops short of describing the returned contact shape or the not-found behavior, a minor gap given the rich annotations and complete input 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 `id`, `with`, `account` and `get_by_email`, including the enum of relationship values. The description restates what `with[]` does (eager-load related data) but adds no syntax or format detail beyond the schema, so the baseline 3 holds.

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 and resource ('Retrieve a single contact') and pins the lookup key ('by ID or email'), which cleanly separates it from the sibling list/search tools. It also names the eager-loading extension point, so an agent understands the full scope of the 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?

There is no guidance on when to pick this over fcrm_list_contacts or fcrm_search_contacts, nor any stated preconditions for the lookup (e.g. behavior when the ID is unknown). The capability note describes authorization, not tool selection.

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

fcrm_list_automationsfcrm list automationsA
Read-onlyIdempotent

Retrieve a paginated list of automation funnels. Supports sorting, searching by title, and filtering by label IDs. Optionally includes trigger definitions.

Required capability: fcrm_read_funnels or fcrm_write_funnels : which one applies depends on the action being performed.

Enforced by FunnelPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
tagsNoOnly automations whose contacts carry these tag ids.
withNoInclude additional related data. Supported values: `triggers`.
listsNoOnly automations whose contacts are on these list ids.
labelsNoFilter funnels by label IDs.
searchNoSearch funnels by title (partial match).
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoColumn to sort by.id
per_pageNoNumber of funnels per page.
statusesNoFilter automations by status, e.g. `published` or `draft`.
sort_typeNoSort direction.DESC

TDQS

A3.7/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 safety is covered. The description adds genuinely useful context beyond that: the required capability (fcrm_read_funnels or fcrm_write_funnels) and the enforcing policy (FunnelPolicy::verifyRequest()). The caveat that the applicable capability 'depends on the action' is slightly odd for a read-only list tool but not contradictory.

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 core purpose is front-loaded in one sentence, followed by a compact capability summary. The trailing capability/policy block is somewhat boilerplate but short and informative, with no wasted prose.

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 11 optional parameters, full schema coverage, and annotations covering the safety profile, the definition is close to complete; it also states the auth capability requirement. The main gap is the absence of an output schema with no description of the return shape, though pagination is at least implied.

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 11 parameters are already documented in the schema; the baseline is 3. The description restates a subset (title search, label filtering, trigger inclusion) without adding syntax, defaults, or constraints beyond what the schema provides (e.g., page/per_page limits, sort_type enum).

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 ('Retrieve a paginated list of automation funnels') plus the supported operations (sort, search by title, filter by label IDs, optional triggers). This clearly distinguishes it from contact/feed/form siblings, but does not explicitly contrast it with the other fcrm list/search 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?

The description enumerates capabilities (sorting, title search, label filtering, trigger inclusion), which implies when each feature applies, but gives no explicit when-to-use guidance or alternatives among the many sibling list tools. Usage is inferable but not stated.

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

fcrm_list_campaignsfcrm list campaignsA
Read-onlyIdempotent

Retrieve a paginated list of email campaigns. Supports filtering by status, search term, labels, and sorting. Optionally includes campaign statistics.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by CampaignPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number.
withNoInclude related data. Use `stats` to include campaign statistics and labels.
labelsNoFilter by label IDs.
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoColumn to sort by.created_at
per_pageNoNumber of results per page.
searchByNoSearch campaigns by title.
statusesNoFilter by campaign statuses.
sort_typeNoSort direction.DESC

TDQS

A3.5/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 two useful facts beyond that: results are paginated and campaign statistics are opt-in via the `with` parameter, plus an auth capability requirement — though that requirement is left ambiguous ('depends on the action being performed').

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 core three sentences are tight and front-loaded, with the resource and pagination stated first. The trailing capability/policy block is boilerplate-heavy and its conditional phrasing is muddy, slightly diluting an otherwise efficient description.

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, 9-parameter list tool with no output schema, the description covers purpose, filters, sorting, pagination and the optional stats payload. The only real gap is that with no output schema the description could sketch the returned campaign record shape, but everything needed to call it correctly is present.

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 9 parameters is already documented in the schema, including defaults, ranges and the status enum. The description only restates the filter categories (status, search, labels, sort) at a higher level and adds no syntax, format or defaulting detail beyond the schema — 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?

States a specific verb and resource ('Retrieve a paginated list of email campaigns') and enumerates the supported filter/sort capabilities, so the agent knows exactly what the tool returns. It does not explicitly contrast itself with the nearby siblings fcrm_get_campaign or fcrm_campaign_stats, which would have earned 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?

Usage is only implied: the description names filtering and sorting options, suggesting 'use this when you need a filtered campaign list', but never states when to prefer this over fcrm_get_campaign, fcrm_campaign_stats, or fcrm_list_sequences. The capability note ('which one applies depends on the action being performed') adds no routing guidance.

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

fcrm_list_contactsfcrm list contactsA
Read-onlyIdempotent

Retrieve a paginated list of contacts. Supports both simple filtering (by tags, lists, statuses) and advanced filtering with complex filter groups. Optionally includes custom field values.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
tagsNoFilter by tag IDs (simple filter mode only).
listsNoFilter by list IDs (simple filter mode only).
searchNoSearch contacts by name, email, or other searchable fields.
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoColumn to sort by.id
per_pageNoNumber of contacts per page.
statusesNoFilter by contact statuses (simple filter mode only).
sort_typeNoSort direction.DESC
company_idsNoFilter by company IDs.
filter_typeNoType of filtering to apply.simple
has_commerceNoFilter by commerce integration availability.
sms_statusesNoFilter by SMS statuses (simple filter mode only).
custom_fieldsNoSet to `true` to include custom field values in the response.
advanced_filtersNoJSON-encoded advanced filter groups (advanced filter mode only).

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, openWorldHint and destructiveHint=false, so the safety profile is covered. The description adds genuinely useful context beyond them: the required capability (fcrm_read_contacts/fcrm_manage_contacts) and the enforcing policy hook, which an agent needs to know before calling. It stops short of describing pagination limits or 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.

Conciseness4/5

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

The functional description is front-loaded in three tight sentences, and the capability/policy note is clearly separated. The policy-enforcement boilerplate is slightly verbose but does carry real authorization meaning, so little is wasted.

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 15-parameter read tool with 100% schema coverage and no output schema, the description covers purpose, filtering modes, and auth requirements adequately. The main omission is guidance on how simple vs advanced mode maps to parameters and what the advanced_filters JSON should contain, but the schema carries most of that burden.

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 every parameter is documented in the schema itself, so baseline is 3. The description echoes the filtering concepts (tags, lists, statuses, custom fields) but adds no syntax, format, or interaction 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 ('Retrieve a paginated list of contacts') and names the two filtering modes plus optional custom-field inclusion. It does not, however, differentiate from the sibling fcrm_search_contacts or fcrm_get_contact, so an agent cannot tell from the description alone which contact-retrieval tool to pick.

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 describing simple vs advanced filtering modes and mentions the required capability, but never states when to choose this over fcrm_search_contacts or fcrm_get_contact, nor any exclusion conditions. Mode selection is left to inference from the filter_type param.

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

fcrm_list_listsfcrm list listsA
Read-onlyIdempotent

Retrieve a paginated list of contact lists. Optionally includes subscriber counts and a separate array of all lists for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by ListPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
withNoExtra data to include. `subscribersCount` adds per-list contact counts via one grouped pivot query.
searchNoSearch lists by title, slug, or description.
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoColumn to sort by.id
per_pageNoNumber of lists per page.
all_listsNoIf set to any truthy value, includes a flat `all_lists` array with id, title, and slug of every list (useful for dropdowns).
sort_orderNoSort direction.DESC
exclude_countsNoIf set to any truthy value, `totalCount` and `subscribersCount` will not be included for each list.

TDQS

A3.7/5.0
Behavior4/5

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

Beyond the readOnly/idempotent annotations, it discloses a genuine behavioral constraint the annotations don't cover: the required `fcrm_manage_contact_cats` capability and its enforcement via ListPolicy::verifyRequest(). It does not describe pagination limits or response shape, but the auth disclosure is substantive.

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 core purpose is front-loaded in the first sentence and the optional behaviors follow. The bolded capability line and policy citation are somewhat noisy formatting for a read tool, but the content is not padded.

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 9-param, zero-required read tool with a fully documented schema and read-only annotations, the description covers purpose, optional enrichments, and the access requirement. No output schema exists, but the paginated-list return shape is inferable from the parameters; nothing critical 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 schema already documents all nine parameters including `with`, `all_lists`, and `exclude_counts`. The description restates the subscriber-count and dropdown behaviors already in the schema, adding no new syntax or format detail. Baseline 3 is correct.

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 ("Retrieve a paginated list of contact lists") and names the two optional enrichments, so an agent can tell it apart from fcrm_list_contacts. It does not explicitly contrast itself with the nearest sibling, but the resource distinction 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 implies usage contexts (dropdown/select usage via `all_lists`, subscriber counts via `with`), which is better than nothing. However, it gives no explicit when-to-use or when-not-to-use guidance relative to alternatives such as fcrm_list_contacts or fcrm_search_contacts.

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

fcrm_list_sequencesfcrm list sequencesB
Read-onlyIdempotent

Retrieve a paginated list of email sequences. Optionally include statistics (email count, subscriber count, revenue) for each sequence. Requires FluentCampaign Pro.

Required capability: fcrm_read_emails or fcrm_manage_emails : which one applies depends on the action being performed.

Enforced by SequencePolicy::verifyRequest(), the policy default for this route group.

Requires: FluentCampaign Pro. Without it the route does not exist.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
withNoInclude additional data. Use `stats` to include email count, subscriber count, and revenue for each sequence.
orderNoSort direction.desc
searchNoSearch sequences by title.
accountNoExact configured private account profile label; not a tenant or provider account ID.
orderByNoColumn to sort by.id
per_pageNoNumber of sequences per page.

TDQS

B3.2/5.0
Behavior3/5

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

Annotations already cover readOnlyHint, idempotentHint, and non-destructive. The description adds meaningful capability gating ('Requires FluentCampaign Pro' and the fcrm_read_emails/fcrm_manage_emails requirement), which is useful beyond annotations. However, it doesn't explain pagination behavior, default ordering, or the stats payload 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?

The core sentence is tight and front-loaded. However, the capability/licensing block is dense boilerplate with bureaucratic phrasing ('Enforced by SequencePolicy::verifyRequest(), the policy default for this route group') that adds bulk without clarifying agent behavior.

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 paginated list tool with full schema coverage and read-only annotations, the description covers purpose, optional stats, and the Pro requirement. It lacks pagination guidance and return-shape hints, but no output schema is declared, so some of that gap is acceptable.

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 already documented in the schema. The description only restates the 'with=stats' option, 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.

Purpose4/5

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

Clear verb+resource: 'Retrieve a paginated list of email sequences.' It distinguishes itself from siblings like fcrm_list_campaigns and fcrm_list_automations by naming 'email sequences'. No explicit sibling contrast, so not 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 states an optional 'with=stats' flag but gives no guidance on when to use this tool versus fcrm_list_campaigns, fcrm_automation_report, or fcrm_dashboard_stats. No when-not or alternative routing.

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

fcrm_list_tagsfcrm list tagsA
Read-onlyIdempotent

Retrieve a paginated list of tags. Optionally includes subscriber counts and a separate array of all tags for dropdown/select usage.

Required capability: fcrm_manage_contact_cats

Enforced by TagPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNoPage number for pagination.
searchNoSearch tags by title, slug, or description.
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoColumn to sort by.id
all_tagsNoIf set to any truthy value, includes a flat `all_tags` array with id, title, and slug of every tag (useful for dropdowns).
per_pageNoNumber of tags per page.
sort_orderNoSort direction.DESC
exclude_countsNoIf set to any truthy value, subscriber counts will not be included for each tag.

TDQS

A3.7/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 adds genuinely new behavioral context: the required capability `fcrm_manage_contact_cats` and that it is enforced by TagPolicy::verifyRequest(), which tells the agent about an auth prerequisite 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.

Conciseness4/5

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

Front-loaded purpose sentence followed by two short, relevant notes. The bolded capability/policy block is slightly noisy in formatting but the content earns its place as auth context.

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 no output schema, 8 fully-described parameters, and rich annotations, the description supplies the missing auth requirement and the optional-behavior flags. Nothing critical for correct invocation appears 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 8 parameters, including the all_tags and exclude_counts flags. The description restates the counts/all_tags behavior but adds no syntax or format 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.

Purpose4/5

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

States a specific verb and resource ('Retrieve a paginated list of tags') and notes two optional behaviors (subscriber counts, flat all_tags array). It does not differentiate itself from sibling list tools, but no sibling also handles tags, so ambiguity is low.

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?

Usage context is implied through parameter notes ('useful for dropdowns'), giving a hint about when to enable all_tags, but there is no explicit when-to-use vs alternatives guidance or exclusion criteria.

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

fcrm_search_contactsfcrm search contactsA
Read-onlyIdempotent

Search contacts by name or email. Returns a lightweight object of contacts keyed by ID, suitable for dropdowns and autocomplete widgets. Optionally loads default contacts when no search term is provided.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group.

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNoMaximum number of results to return.
offsetNoRows to skip before the first result. Combine with `limit` to page through matches.
searchNoSearch term to match against contact name and email.
valuesNoArray of contact IDs to always include in results (useful for pre-selected values).
accountNoExact configured private account profile label; not a tenant or provider account ID.
load_defaultNoIf truthy and no search term is provided, returns the most recent contacts.

TDQS

A3.7/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 behavior. The description adds genuinely useful context beyond them: the lightweight keyed-by-ID return shape, the load_default fallback when no term is given, and the required capability (fcrm_read_contacts or fcrm_manage_contacts) enforced by SubscriberPolicy. This auth/permission disclosure is real value not present 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?

Front-loaded with the core action and return shape in the first two sentences, then the fallback behavior and auth requirement. No filler, though the capability/policy enforcement block is slightly ceremonial for a read tool.

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 usefully characterizes the return (lightweight, keyed by ID) and the no-term default behavior, and it discloses the permission requirement. Minor gaps remain (e.g., how the `values` always-include parameter interacts with paging), but it is substantively complete for a search 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 is already documented in the schema; baseline 3 applies. The description reinforces the search-term and load_default behaviors but adds no syntax, format, 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+resource (search contacts) and goes further by describing the return shape ('lightweight object of contacts keyed by ID') and the intended surface (dropdowns/autocomplete). It distinguishes itself functionally from siblings like fcrm_list_contacts by emphasizing lightweight search output, though it never names the sibling to make the contrast explicit.

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 when to use it via 'suitable for dropdowns and autocomplete widgets' and notes the no-search-term fallback (load_default). However, it gives no explicit guidance on when to prefer this over fcrm_list_contacts or fcrm_get_contact, leaving the routing decision to inference.

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

fcrm_update_contactfcrm update contactA
Destructive

Update an existing contact's fields, custom values, tags, and lists. Supports attaching and detaching tags/lists in a single request. The subscriber object or individual fields can be passed in the request body.

Required capability: fcrm_read_contacts or fcrm_manage_contacts : which one applies depends on the action being performed.

Enforced by SubscriberPolicy::verifyRequest(), the policy default for this route group. Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
idYesThe contact ID.
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
subscriberNo
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

TDQS

A3.9/5.0
Behavior5/5

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

Goes well beyond the annotations (destructiveHint=true, idempotentHint=false, openWorldHint=true) by disclosing that the operation is policy-enforced (SubscriberPolicy::verifyRequest), requires explicit local confirmation, may trigger hooks/announcements/automations affecting other people, and must not be retried. That is exactly the kind of side-effect and safety context structured fields 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?

Purpose is front-loaded and the capability/confirmation block is broken out cleanly. It is mildly cluttered by internal jargon (_Enforced by `SubscriberPolicy::verifyRequest()`_) that an agent doesn't need to invoke the tool, but overall the structure is efficient.

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, nested-object mutation with a strong annotation set, the description covers the essential gaps: capability requirement, confirmation expectation, side effects, and no-retry warning. No output schema exists, but a successful update's return is not what gates correct invocation. Minor shortfall is the absence of any note on partial-update semantics for the nested payload.

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 the key parameters. The line about the subscriber object or individual top-level fields mirrors the $defs description ("Contact data can be nested inside a `subscriber` object or passed at the top level"), so it adds little new semantic value. 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: "Update an existing contact's fields, custom values, tags, and lists." The update verb inherently separates it from fcrm_create_contact, fcrm_get_contact, fcrm_list_contacts, and fcrm_search_contacts. However, no sibling is named explicitly, so this falls short of the top band.

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 operational conditions (required capability, explicit local confirmation, no retries) rather than a when-to-use-this-vs-alternatives rule. The agent can infer that this is the mutation route for contacts, but nothing tells it when to prefer this over, say, fcrm_add_contact_note or fcrm_create_contact. Usage is implied, not spelled out.

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

fc_scheduled_postsfc scheduled postsA
Read-onlyIdempotent

Returns the paginated list of posts one member has scheduled but not yet published, soonest first.

Controller: SchedulePostsController@getScheduledPosts Route source: fluent-community-pro/app/Http/Routes/api.php:112 Requires FluentCommunity Pro and its native scheduled-post permission. It is not a scheduling action.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
user_idNoUser ID read via `$request->getSafe()` in getScheduledPosts().$currentUserId

TDQS

A4.1/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds real context beyond them: pagination, soonest-first ordering, a Pro-plus-permission gate, and a clarification that this is a read of scheduled items rather than a scheduling action.

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 core behavior is front-loaded in one sentence, followed by routing and requirement notes. The controller/route-source line is developer-facing metadata rather than agent-facing guidance, but it is compact and not misleading.

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 full annotation coverage and no output schema, the description covers scope, ordering, and gating. The remaining gap is the return shape (fields per post, how pagination is advanced given no page parameter), which an agent must discover empirically.

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 both account and user_id, including the $currentUserId default. The description only implies the member scoping via 'one member' and adds no 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.

Purpose5/5

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

The opening sentence gives a specific verb (Returns), resource (posts scheduled but not yet published), scope (one member), and ordering (soonest first), which is enough to distinguish it from every sibling in the fc_* family.

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

Usage Guidelines4/5

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

It states a prerequisite (requires FluentCommunity Pro and the native scheduled-post permission) and an explicit exclusion ('It is not a scheduling action'), which prevents a common mis-invocation. It stops short of naming an alternative tool for actually scheduling a post.

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

fc_space_membersfc space membersA
Read-onlyIdempotent

Returns the paginated active membership of a space, each entry carrying the member profile and their role, plus the count of outstanding join requests.

Controller: SpaceController@getMembers Route source: fluent-community/app/Http/Routes/api.php:18

ParametersJSON Schema
NameRequiredDescriptionDefault
slugYesSpaceSlug extracted from the URL path.
searchNoSearch read via `$request->getSafe()` in getMembers().
statusNoStatus read via `$request->get()` in getMembers().
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNoSort By read via `$request->getSafe()` in getMembers().created_at
sort_dirNoSort Dir read via `$request->getSafe()` in getMembers().

TDQS

A3.5/5.0
Behavior3/5

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

Annotations already declare readOnlyHint=true, idempotentHint=true, and destructiveHint=false, establishing a safe read profile. The description adds that results are paginated and include outstanding join request counts, but doesn't explain pagination mechanics or any auth/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.

Conciseness3/5

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

The first sentence is dense and front-loads the core behavior. However, the subsequent controller/route source lines are developer-oriented provenance metadata that doesn't help an agent decide or invoke the tool, adding length without aiding usage.

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 complete schema descriptions, the definition is adequate. But it lacks guidance on pagination behavior, alternative tools for member analytics, or how the join-request count should be interpreted, leaving some contextual gaps for an agent.

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 six parameters including constraints and the special 'account' clarification. The description doesn't add parameter-level detail beyond what the schema provides, which is the baseline expectation.

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 (Returns) and resource (paginated active membership of a space), plus names exactly what each entry carries. This clearly distinguishes it from siblings like fc_list_spaces or fc_analytics_member_activity.

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 through 'active membership' but doesn't state when to use this tool versus alternatives like fc_analytics_top_members or fc_list_spaces. No explicit when/when-not guidance is provided.

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

fc_update_commentfc update commentA
Destructive

Replaces the body of an existing comment, re-renders it, and reconciles its attached media with the submitted list.

Controller: CommentsController@update Route source: fluent-community/app/Http/Routes/api.php:57 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
commentNo
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
comment_idYesComment ID extracted from the URL path.
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.

TDQS

A3.9/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, but the description adds real value beyond them: it discloses that media is reconciled against the submitted list (i.e. attachments can be dropped), that hooks/announcements/automations can affect other people, and that no retries are permitted. It stops short of saying exactly what happens to media omitted from the list.

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 purpose is front-loaded in the first sentence and the operational caveats follow compactly. The controller/route-source metadata is arguably filler for an agent, but it is brief and does not bury the important content.

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 7-parameter mutation with a nested payload object and no output schema, the description covers the key behavioral risks (confirmation requirement, side effects, no retries, media reconciliation). It could still clarify how the top-level comment, payload, and payload_file variants relate, but the schema covers those at 86%.

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 account, confirm, feed_id, comment_id, payload and payload_file. The description's mention of a 'submitted list' of media does not map to any visible parameter, adding little semantic detail beyond what the schema supplies. 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 (Replaces) and resource (body of an existing comment) plus secondary effects (re-render, media reconciliation). This clearly distinguishes it from the sibling fc_create_comment and fc_delete_comment operations.

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 states a precondition ('Explicit local confirmation is required') and warns of downstream side effects, which implies when this is safe to call. However it never states when to use this vs. alternatives or when not to use it, leaving the routing decision to be inferred from the name.

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

fc_update_feedfc update feedA
Destructive

Replaces the body and metadata of an existing post, re-renders it, reconciles its media and topics, and records an edit history entry.

Controller: FeedsController@update Route source: fluent-community/app/Http/Routes/api.php:47 Explicit local confirmation is required; hooks, announcements and automations may affect other people. No retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
titleNo
statusNo
surveyNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
feed_idYesFeed ID extracted from the URL path.
messageNo
payloadNoComplete native JSON body; do not mix with body flags or payload_file. Arrays use repeated JSON object flags or a whole native array in a private file.
topic_idsNo
content_typeNo
media_imagesNo
new_space_idNo
payload_fileNoAbsolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags.
move_to_profileNo
send_announcement_emailNo

TDQS

A3.6/5.0
Behavior4/5

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

Goes well beyond the annotations: annotations only declare destructive/openWorld/not-idempotent, while the description adds that confirmation is mandatory, that no retries are possible, that other people may be affected via hooks/announcements, and that media/topics get reconciled and an edit-history entry is written. It still doesn't say what happens to fields omitted from the replacement, which is the main residual gap.

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 opening sentence is dense and front-loaded, and the confirmation/no-retries warning is well placed. The 'Controller: ... Route source: ...' line is developer-facing metadata that adds little for an agent deciding whether and how to call the tool, so not every sentence 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 destructive, open-world, 15-parameter mutation with no output schema, the behavioral side is adequately covered but the parameter side is not: nothing explains replacement vs. partial semantics, field omission behavior, or the payload/payload_file exclusivity that a caller must get right.

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% across 15 parameters, so the description must compensate — and it doesn't. The critical payload vs. payload_file vs. body-flag mutual exclusion, and the mapping of top-level fields to the nested payload, are documented only in the schema fragments, not in the description.

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?

Names a specific verb and resource ('Replaces the body and metadata of an existing post') plus the consequential side effects (re-render, media/topic reconciliation, edit-history entry). The word 'existing' cleanly separates it from fc_create_feed and fc_delete_feed.

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?

States a precondition ('Explicit local confirmation is required') and a hazard ('hooks, announcements and automations may affect other people'), which implies when to proceed carefully. However, it never says when to choose this over siblings such as fc_update_comment or fc_delete_feed, and the 'confirm' parameter's semantics are left to the schema.

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

ff_form_fieldsff form fieldsA
Read-onlyIdempotent

Read current native field definitions; no field edits. Requires fluentform_forms_manager for the selected form.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
form_idYes

TDQS

A3.9/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 the safety profile is covered. The description adds a genuine behavioral fact not in the structured data: the calling user must hold the fluentform_forms_manager permission for the selected form. It does not cover return shape 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 clauses, front-loaded with the read scope and qualification. 'no field edits' is largely redundant with readOnlyHint=true, costing a little, but nothing is padded.

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?

There is no output schema, so the description must carry the return semantics, and 'current native field definitions' communicates that adequately. The permission prerequisite and read-only scope round out the essentials, leaving only failure modes unspecified.

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 50%: the 'account' parameter is well documented in the schema, while 'form_id' carries only a minimum constraint. The description adds no parameter-level meaning, so the baseline of 3 applies given mid-level coverage.

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 and resource: 'Read current native field definitions,' which tells an agent exactly what is returned and distinguishes it from mutation tools. It does not, however, name the sibling it differs from (e.g. ff_get_form, ff_list_forms), so the distinction must be inferred.

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?

'no field edits' scopes the operation and 'Requires fluentform_forms_manager for the selected form' states a concrete precondition that determines whether the call will succeed. There is no explicit routing guidance against alternatives like ff_get_form, but the required-permission context is actionable.

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

ff_form_reportff form reportA
Destructive

Read the native form report with explicit approval because ReportService::form invokes ReportHelper::maybeMigrateData. It may update stored reporting data. Requires native form-scoped fluentform_entries_viewer; hidden/refused in read-only mode. No automatic retries.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
confirmNoSet true only when the user asked for exactly this action.
form_idYes
statusesNo

TDQS

A3.7/5.0
Behavior4/5

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

Annotations declare destructiveHint=true and readOnlyHint=false, matching the described data mutation. The description adds valuable context beyond structured fields: the exact internal service calls (ReportService::form invokes ReportHelper::maybeMigrateData), the permission requirement, read-only mode refusal, and the no-retry policy. This is well above the bar set by 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?

Four sentences with high information density. The mutation warning is front-loaded. Some phrases could be tighter, but every sentence adds material information (mutation, permission, read-only refusal, retry policy).

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 mutating, non-idempotent tool with no output schema and partial parameter coverage, the description covers the critical behavioral traits: mutation side effect, required permission, read-only refusal, and retry behavior. It does not explain return values, but no output schema exists. Could mention what 'native form report' returns, but overall complete enough.

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 50%. The description does not explain the parameters at all, but it adds behavioral context (approval, permission) that affects how parameters should be used (e.g., 'confirm' should reflect explicit user approval). Baseline 3 is appropriate given partial schema documentation.

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 ('Read the native form report'), and the naming against siblings like ff_form_stats and ff_list_submissions is implicitly distinct. It does not explicitly differentiate from ff_form_stats, which might sound similar, but the resource ('native form report') is specific enough.

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 when to use ('with explicit approval') and states a prerequisite ('Requires native form-scoped fluentform_entries_viewer'), but does not compare against alternatives like ff_form_stats. The guidance is contextual but not a full routing decision.

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

ff_form_statsff form statsA
Read-onlyIdempotent

Read native date-range form statistics. Requires form-scoped fluentform_entries_viewer when form_id is selected; all-forms permission otherwise. Native reports may change via site hooks and version-specific provider behavior. Not guaranteed lifetime revenue or all plugin statistics.

ParametersJSON Schema
NameRequiredDescriptionDefault
metricNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
form_idNo
end_dateNo
start_dateNo

TDQS

A3.7/5.0
Behavior4/5

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

Annotations already declare read-only, idempotent, non-destructive behavior, so the bar is lower. The description still adds real context: the permission model, that reports may change via site hooks and version-specific provider behavior, and that results are not guaranteed lifetime revenue or all plugin statistics.

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 sentences, front-loaded with the core purpose before the caveats. Dense but each sentence carries information; no obvious 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 and low parameter coverage, the description usefully covers permissions, environmental volatility, and scope limits. It leaves metric and account semantics unexplained, but overall it is complete enough for an agent to call the tool safely.

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 only 20%, so the description must compensate and only partly does. It clarifies date-range semantics and the form_id permission linkage, but metric, account, and the date formats remain undocumented in both places.

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 ('Read') and resource ('native date-range form statistics'), which is clear. However, it does not distinguish itself from the close sibling ff_form_report, leaving the agent to guess which stats tool to pick.

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 useful prerequisite guidance ('Requires form-scoped fluentform_entries_viewer when form_id is selected; all-forms permission otherwise'), which implies when it can be used. But there is no explicit when-to-use vs the sibling ff_form_report, and no exclusions beyond the scope disclaimer.

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

ff_get_formff get formA
Read-onlyIdempotent

Read one native form with formMeta; may include private integration/settings data. Requires fluentform_forms_manager for the selected form.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
form_idYes

TDQS

A3.7/5.0
Behavior4/5

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

Annotations cover readOnly, idempotent, and non-destructive. The description adds that it may include private integration/settings data and states a permission requirement, which is useful behavioral context beyond the annotations. It does not detail auth mechanics further 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?

Two sentences, front-loaded with the primary action and scope. No wasted words, though the permission note could be phrased more tightly.

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 tool with no output schema, the description covers purpose, sensitive data possibility, and permission requirement. It lacks guidance on return structure (which is fine without output schema) and explicit alternatives, leaving a small 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 50%; the 'account' parameter has a schema description but 'form_id' only has constraints. The description does not add meaning beyond what the schema provides for either parameter. Baseline 3 when schema partially covers parameters.

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 (Read) and resource (one native form with formMeta), which is clearer than the name alone. It does not explicitly distinguish from siblings like ff_list_forms or ff_form_fields, though 'Read one' implies singular retrieval. Good but lacking 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 Guidelines3/5

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

Adds a permission prerequisite ('Requires fluentform_forms_manager for the selected form'), which implies context. However, it gives no guidance on when to use this tool versus alternatives like ff_list_forms or ff_form_fields. Usage is only loosely implied.

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

ff_list_formsff list formsB
Read-onlyIdempotent

Read one Forms page with current native sorting and date filters. Requires fluentform_dashboard_access and applicable native form permissions. Not an all-forms snapshot.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
searchNo
statusNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
sort_byNo
per_pageNo
filter_byNo
date_rangeNo
sort_columnNo

TDQS

B3.4/5.0
Behavior4/5

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

Annotations already cover readOnly/idempotent/non-destructive, and the description adds material context beyond them: the required access scope and the fact that this returns a single page rather than a complete snapshot. It stops short of describing pagination mechanics 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.

Conciseness5/5

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

Three short, front-loaded sentences with no filler: scope first, precondition second, boundary third. Every sentence adds a distinct fact.

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 nine-parameter read tool with 11% schema coverage and no output schema, the description is too thin: most parameters are undocumented in both places, and there is no guidance on pagination, result size, or how the date/sort filters compose. Auth and scope are covered well, but the parameter surface is largely left to inference.

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 11% (just 'account'), and nine parameters exist, so the description carries the compensation burden. Its phrase 'native sorting and date filters' loosely gestures at sort_by/sort_column and date_range/filter_by but explains nothing about page, per_page, search, status, or the ASC/DESC enum.

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 ('Read one Forms page') and bounds the scope with 'Not an all-forms snapshot,' which implicitly separates it from a full-listing or single-form tool. It does not name ff_get_form or any sibling explicitly, so the differentiation is by inference rather than declaration.

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?

Gives a real precondition ('Requires fluentform_dashboard_access and applicable native form permissions') that tells the agent when it can be called, and the 'not an all-forms snapshot' note hints at scope limits. There is no explicit when-not or named alternative that the agent should use instead for a full listing.

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

ff_list_submissionsff list submissionsB
Read-onlyIdempotent

Read one native individual-entry page for an explicitly selected form. Corrects old GET /report/submissions. Requires fluentform_entries_viewer for that form. Entry bodies are private; no automatic detail call or mark-as-read action.

ParametersJSON Schema
NameRequiredDescriptionDefault
pageNo
searchNo
accountNoExact configured private account profile label; not a tenant or provider account ID.
form_idYes
sort_byNo
per_pageNo
date_rangeNo
entry_typeNo
payment_statusesNo

TDQS

B3.3/5.0
Behavior4/5

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

Annotations already declare readOnly/idempotent/no-destructive, so the bar is lower, and the description adds real behavioral context beyond them: the required permission scope, that entry bodies are private, and that no automatic detail or mark-as-read call occurs. It omits pagination/return-shape behavior, keeping it 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?

Four tight sentences, front-loaded with the core read action, then constraints and permission. Little waste, though 'Corrects old GET /report/submissions' is arguably migration trivia rather than invocation guidance.

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, low-coverage, no-output-schema tool, the description is thin: filtering/pagination semantics are entirely undocumented and the return format is only gestured at ('entry bodies are private'). It should do far more to compensate for the schema 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 11% (just the 'account' label) across 9 parameters, so the description carries the burden of explaining page, search, date_range, entry_type, payment_statuses, sort_by, and per_page — and it explains none of them. It adds nothing beyond the one schema-documented field.

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: 'Read one native individual-entry page for an explicitly selected form.' This distinguishes it from aggregate siblings like ff_form_report and ff_form_stats, though it doesn't name those siblings directly.

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?

Gives useful context ('Corrects old GET /report/submissions', requires fluentform_entries_viewer) but never states when to choose this over ff_form_report or ff_form_stats, nor when pagination/detail calls are appropriate. Usage is implied rather than directed.

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

get_current_userRead current WordPress userA
Read-onlyIdempotent

One authenticated WordPress current-user GET with view context; verifies one user read, not site ownership or all plugin permissions. Native private output is untrusted.

ParametersJSON Schema
NameRequiredDescriptionDefault
accountNoExact configured private account profile label; not a tenant or provider account ID.
contextNo

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, openWorld and non-destructive, so the safety profile is covered. The description adds genuine extra context: it requires authentication, it uses view context, and it explicitly warns that the native private output is untrusted. That trust warning and the scope caveat are behavior beyond what the annotations convey.

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

Conciseness4/5

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

It is a single sentence with the core operation front-loaded and no filler. The semicolon-clause structure is dense but every clause carries information. Slightly cryptic phrasing keeps 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 two-parameter, zero-required read tool with no output schema and full annotation coverage, the description supplies auth requirements, scope limits, and an output-trust caveat. The only gap is the partial coverage of the context parameter, which the agent can partly recover from the enum.

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 50%: the account parameter is documented while the context enum is not. The description's phrase 'with view context' adds some meaning to the context parameter by indicating the default/typical value, but it does not explain embed or the account profile label semantics. Marginal value over the schema, fitting a 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: an authenticated WordPress current-user GET that reads one user. It scopes what the read does and does not verify (site ownership, all plugin permissions). However, it never names or distinguishes itself from plausible siblings like fc_get_profile or list_accounts, leaving the agent to infer which identity-read tool 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 statement of when to use this tool versus an alternative such as fc_get_profile. The negative scoping ('not site ownership or all plugin permissions') bounds what it returns but does not guide tool selection. An agent gets no routing help from the text.

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

get_operation_schemaInspect a current native operationA
Read-onlyIdempotent

Local method/path/query/body schema and pinned provenance for one selected native tool. No provider call or credentials.

ParametersJSON Schema
NameRequiredDescriptionDefault
operationYesActual native tool name, including fc_update_feed and ff_list_submissions.

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, non-destructive, and closed-world behavior, so the bar is low. The description adds genuine context beyond them: it is a purely local lookup requiring no credentials and it returns 'pinned provenance,' disclosing that schema versions are anchored. That is useful extra 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 dense sentences with no filler, and the core deliverable (method/path/query/body schema) is front-loaded. Occasionally cryptic jargon like 'pinned provenance' costs a little readability, but the structure is 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?

No output schema exists, so the description carries more of the return-value burden. It names the returned components (method/path/query/body schema and provenance) but does not sketch their shape or structure for a meta-tool spanning dozens of operations, leaving a modest 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%, and the single 'operation' enum is fully documented in the schema itself, so the baseline is 3. The description adds only a general sense of what the parameter selects ('one selected native tool') without elaborating on enum semantics 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: it returns the local method/path/query/body schema and pinned provenance for one selected native tool. This implicitly distinguishes it from the sibling native tools, which actually invoke providers, but it never names a sibling explicitly. Clear and specific without relying on 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 Guidelines3/5

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

The phrase 'No provider call or credentials' implies this is a safe inspection path used before invoking a native tool, but the description never states when to choose it over just calling the native operation. Usage is left to inference rather than explicit when/when-not guidance.

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

list_accountsList configured sitesC
Read-onlyIdempotent

Local profile labels/default/credential source only; no site URL, username, password path, provider identity or network request.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

C2.9/5.0
Behavior4/5

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

Annotations already cover the safety profile (readOnly/openWorld false/idempotent), but the description adds meaningful context beyond them: output is local profile data only and explicitly excludes site URL, username, password path, and provider identity, i.e. it will not leak credentials. The 'no network request' claim reinforces rather than contradicts openWorldHint=false.

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-loads the positive scope clause before the exclusions, which is good. However, it is a semicolon-joined fragment with no main verb, so the brevity comes at the cost of readability rather than being crisp prose.

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 0-parameter, read-only tool this is nearly adequate; with no output schema the description is the only place to explain the return payload, and it does sketch the fields (labels, default, credential source). It still leaves the account-vs-site ambiguity and the shape/count of results unresolved, so it falls short of complete.

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. The description correctly offers no parameter detail, and there is nothing for it to compensate for.

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 a verbless fragment that names return-scope items ('Local profile labels/default/credential source only') but never says what the tool does. The name (list_accounts) and title (List configured sites) disagree on the resource, so the agent gets mixed signals about whether it is listing accounts or sites.

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 explicit when-to-use, no prerequisites, and no named alternative sibling. The only indirect guidance is the negative-clause style ('no ... network request'), which hints this is the local-only variant versus tools that make network calls, but that is inference rather than stated guidance.

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

preview_site_batchReview exact ordered cross-plugin tasksA
Read-onlyIdempotent

Local native validation/hash for 1–20 CRM/Community writes. Binds selected profile label/site/username, request order and packaged schemas. No password read/provider state check or remote approval token.

ParametersJSON Schema
NameRequiredDescriptionDefault
tasksYesOne to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override.
accountNoExact configured private site profile label, not a verified site-owner identity.

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/non-destructive, so the bar is lower, and the description still adds meaningful traits: the operation is entirely local, does not read passwords, does not check provider state, and does not mint a remote approval token. It also states what gets bound (profile label/site/username, request order, packaged schemas), which goes beyond the annotation set.

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 dense sentences, front-loaded with the core action and followed by scope limitations, with no filler. The phrasing is jargon-heavy ('Local native validation/hash', 'packaged schemas'), which costs some readability but wastes no words.

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 must carry the return contract itself, and it only hints at a 'validation/hash' result without explaining what the preview returns or how the hash feeds into submit_site_batch. The boundary clauses are helpful, but for a preview tool the expected output and failure shape are left underspecified.

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 both parameters, including the tasks min/maxItems and the arguments rule. The description echoes the 1–20 range and gestures at the profile label, adding little syntax or format detail beyond the structured fields; 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 concrete function: local native validation/hash of 1–20 CRM/Community writes, which is a specific verb+resource and clearly a preview (not an executor). It does not, however, name or contrast against the obvious sibling submit_site_batch, so the agent must infer the distinction from the name and the word 'local'.

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?

Usage is implied rather than stated: 'Local native validation/hash' signals a dry-run step, and the boundary clauses ('No password read/provider state check or remote approval token') define scope. But there is no explicit when-to-use or when-not guidance, and no routing to submit_site_batch as the execute counterpart.

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

read_site_snapshotRead bounded cross-plugin responsesA
Read-onlyIdempotent

Prevalidate 1–20 native reads for one exact private site profile; return at most5 MiB combined CRM/Community/Forms responses. No auto-pages, stateful report, browser cookies, uploads or atomic provider snapshot. Native records may contain private personal data.

ParametersJSON Schema
NameRequiredDescriptionDefault
tasksYesOne to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override.
accountNoExact configured private site profile label, not a verified site-owner identity.

TDQS

A3.7/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). The description adds real behavioral value beyond them: the 5 MiB combined cap, the 1–20 task bound, absence of pagination/cookies/uploads, and a privacy warning that records may contain personal data.

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 read scope front-loaded and the constraints trailing. Dense but not wasteful; there is a minor typo ('at most5 MiB') but no filler sentences.

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 steps in to state the combined response bound and privacy caveat, which is the key return-value information. It could say more about per-task error handling, but it is largely complete for a bounded 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%, so the two parameters are already documented. The description reinforces the 1–20 bound and 'exact private site profile' intent but adds no syntax or format detail beyond the schema. 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 action (prevalidate/read 1–20 native reads) against a named resource set (CRM/Community/Forms responses) for an exact private site profile. It is distinguishable from siblings like preview_site_batch and save_site_snapshot, though it never names 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?

It gives scope (one exact private site profile, 1–20 tasks) and exclusions ('no auto-pages... uploads or atomic provider snapshot'), which imply the intended use. However, it never says when to prefer this tool over preview_site_batch or submit_site_batch, leaving the main routing decision to inference.

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

save_site_snapshotSave bounded cross-plugin responses privatelyA
Destructive

Confirmed 1–20 prevalidated native reads delivered only to an exclusive new0600 JSON file. No record body echoed, overwrites, upload or all-pages guarantee. Failures remove only this helper’s newly created file and return indices without native records.

ParametersJSON Schema
NameRequiredDescriptionDefault
tasksYesOne to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override.
accountNoExact configured private site profile label, not a verified site-owner identity.
confirmNoSet true only when the user asked for exactly this action.
output_fileYesAbsolute new file in an existing private directory; restrict Windows ACLs separately.

TDQS

A3.7/5.0
Behavior4/5

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

The annotations already indicate readOnlyHint=false, destructiveHint=true, openWorldHint=true, and idempotentHint=false. The description adds specific behavioral context beyond these hints: it states that no record body is echoed, that overwrites are not allowed, that there is no upload or all-pages guarantee, and that failures remove only the newly created file and return indices without native records. This goes meaningfully beyond the annotations, though it does not detail rate limits or authentication 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?

The description is a single, dense sentence that front-loads the core action and follows with critical constraints. It is appropriately sized, though the compact phrasing may require careful parsing. Every clause carries information, but the structure is somewhat terse.

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?

The tool is complex: it orchestrates up to 20 native calls, writes a file, and has destructive aspects. The description covers key behaviors such as failure handling, file exclusivity, and lack of guarantees, which is substantial. However, given no output schema exists, it could provide more detail about the return format (e.g., what indices are returned upon failure) or confirm requirements, leaving a small 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 schema already fully documents all four parameters, including the tasks array with its constraints and the account, confirm, and output_file fields. The description mentions 'prevalidated native reads' and 'exclusive new0600 JSON file', which loosely relate to the tasks and output_file parameters but do not add syntax or format details 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.

Purpose4/5

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

The description states a specific composite action: it performs 1–20 prevalidated native reads and writes the responses to an exclusive private JSON file. It is differentiated from sibling tools like preview_site_batch and submit_site_batch by stating that it delivers only to an exclusive new0600 JSON file and that failures remove only this helper's newly created file. However, it does not explicitly compare itself to those siblings, so it doesn't reach the level 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 for confirmed, prevalidated native reads and mentions constraints such as no overwrites and no all-pages guarantee. It does not provide explicit when-to-use or when-not-to-use guidance relative to alternatives like read_site_snapshot or preview_site_batch, so an agent must infer the appropriate context.

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

submit_site_batchExecute reviewed cross-plugin tasksA
Destructive

Confirmed 1–20 ordered CRM/Community writes. Validate every request and exact review hash before first request, stop on first failure with known receipts and unattempted indices; no retries/rollback/continuation.

ParametersJSON Schema
NameRequiredDescriptionDefault
tasksYesOne to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override.
accountNoExact configured private site profile label, not a verified site-owner identity.
confirmNoSet true only when the user asked for exactly this action.
review_sha256YesExact preview_site_batch hash for unchanged tasks, site profile and schema.

TDQS

A4.3/5.0
Behavior5/5

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

Beyond the annotations (destructiveHint=true, idempotentHint=false), the description discloses the critical execution semantics: validation of every request and hash before the first write, stop-on-first-failure, known receipts, unattempted indices, and no retries/rollback/continuation. This is exactly the partial-failure behavior an agent needs and cannot get 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.

Conciseness5/5

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

A single dense sentence with the preconditions front-loaded (confirmed, ordered, validate-before-write) and failure semantics following. No redundant restatement of the name or title; every clause conveys a distinct 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 complex batch-mutation tool with no output schema, the description covers preconditions and failure behavior well, and 'known receipts and unattempted indices' signals the shape of a partial result. Minor gaps remain around confirm/hash-mismatch handling, but it is largely complete.

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 already carries the parameter definitions (baseline 3). The description adds meaningful semantics on top: the tasks array is ordered, the count is bounded to 1–20, and the hash must match an unchanged review batch before any request fires.

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 operation (executing 1–20 ordered CRM/Community writes) on a defined resource, and the 'Confirmed' + review-hash framing distinguishes it from a preview step. It never explicitly names preview_site_batch as the prerequisite sibling, so the differentiation is implied rather than stated.

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?

The description makes clear this is the execution step for an already-reviewed batch ('Confirmed', 'exact review hash'), which is actionable context. It does not state exclusions or name preview_site_batch as the required prior call, leaving some inference to the agent.

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.

  1. 54 tool updatesv3.0.0
    • First observedfc_analytics_member_activity
    • First observedfc_analytics_overview
    • First observedfc_analytics_top_commenters
    • First observedfc_analytics_top_members
    • First observedfc_analytics_top_post_starters
    • First observedfc_course_lessons
    • First observedfc_course_students
    • First observedfc_create_comment
    • First observedfc_create_feed
    • First observedfc_delete_comment
    • First observedfc_delete_feed
    • First observedfc_get_course
    • First observedfc_get_feed
    • First observedfc_get_profile
    • First observedfc_get_space
    • First observedfc_list_comments
    • First observedfc_list_courses
    • First observedfc_list_feeds
    • First observedfc_list_spaces
    • First observedfc_react_to_feed
    • First observedfc_scheduled_posts
    • First observedfc_space_members
    • First observedfc_update_comment
    • First observedfc_update_feed
    • First observedfcrm_add_contact_note
    • First observedfcrm_automation_report
    • First observedfcrm_campaign_stats
    • First observedfcrm_contact_emails
    • First observedfcrm_contact_notes
    • First observedfcrm_create_contact
    • First observedfcrm_dashboard_stats
    • First observedfcrm_get_campaign
    • First observedfcrm_get_contact
    • First observedfcrm_list_automations
    • First observedfcrm_list_campaigns
    • First observedfcrm_list_contacts
    • First observedfcrm_list_lists
    • First observedfcrm_list_sequences
    • First observedfcrm_list_tags
    • First observedfcrm_search_contacts
    • First observedfcrm_update_contact
    • First observedff_form_fields
    • First observedff_form_report
    • First observedff_form_stats
    • First observedff_get_form
    • First observedff_list_forms
    • First observedff_list_submissions
    • First observedget_current_user
    • First observedget_operation_schema
    • First observedlist_accounts
    • First observedpreview_site_batch
    • First observedread_site_snapshot
    • First observedsave_site_snapshot
    • First observedsubmit_site_batch

TDQS

B3.1/5.0

Scored across 54 tools

Disambiguation3/5

Within each product family (fcrm_, fc_, ff_) the list/get/create/update/delete tools are mostly distinct, but there is real overlap: fc_analytics_overview is explicitly a 'legacy selector mapped to four fixed routes' that duplicates the four specific fc_analytics_* tools, fcrm_dashboard_stats/fcrm_campaign_stats/fcrm_automation_report are competing stats endpoints, and the four generic batch/snapshot tools (preview_site_batch, submit_site_batch, read_site_snapshot, save_site_snapshot) shadow the individual read/write tools. An agent could easily pick the wrong stats or batch tool.

Naming Consistency3/5

Inside the fcrm_ and fc_ prefixes there is a fairly predictable verb_noun pattern (list_contacts, get_contact, create_contact, update_contact), with minor exceptions like fcrm_contact_notes (noun-only) and fcrm_add_contact_note. However the server mixes four naming families (fcrm_, fc_, ff_) plus an unprefixed generic set (get_current_user, list_accounts, preview_site_batch) and fc_analytics_overview breaking its own prefix, so the overall surface is readable but not uniform.

Tool Count2/5

54 tools is very heavy for an MCP surface, and while the server does span three products (FluentCRM, FluentCommunity, FluentForms) plus generic helpers, the count is well past the comfortable 3-15 range. Several tools are near-duplicates (batch wrappers vs. single calls, legacy analytics selector vs. four specific analytics tools), so not every tool clearly earns its place.

Completeness3/5

Read coverage is broad and the community side has full CRUD for feeds and comments, but there are notable gaps: FluentCRM campaigns, sequences, and automations are read-only (no create/update/delete), and the FluentForms family is entirely read-only with no form or submission write operations. Agents can work around some gaps but cannot complete full lifecycle workflows in several domains.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Related MCP Connectors

Related MCP Servers

  • F
    license
    C
    quality
    D
    maintenance
    Enables management of FluentCRM marketing automation directly from Cursor, including contact management, tags, lists, campaigns, automations, and webhooks. Allows users to interact with their FluentCRM WordPress plugin through natural language conversations with Claude.
    36
    13
    -
  • A
    license
    Not graded
    quality
    A
    maintenance
    A free WordPress plugin that turns your site into a governed MCP server, exposing 153 curated WordPress abilities (posts, media, users, WooCommerce, ACF, SEO) as tools for AI agents like Claude and Cursor. Every ability is off by default, scoped to a least-privilege user, capability-gated, and logged.
    4
    GPL 2.0
  • A
    license
    A
    quality
    C
    maintenance
    Enables AI assistants to read and edit WordPress sites over the REST API, including Divi 4, Divi 5, and Gutenberg content, with safety features like round-trip verification, draft-based editing, and dry-run previews.
    45
    MIT