Fluent WordPress MCP Server
Provides tools and a CLI for interacting with WordPress sites via the REST API using Application Password authentication, targeting the FluentCRM, FluentCommunity and Fluent Forms plugins. Enables reading and updating CRM contacts, campaigns and automations; inspecting Community spaces, feeds, comments, courses and member analytics; reading Forms definitions, submissions and stats; applying explicitly approved native changes; and saving bounded private snapshots, with support for several isolated sites and per-user native permission enforcement.
Click on "Deploy Server".
Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state.
In the chat, type
@followed by the MCP server name and your instructions, e.g., "@Fluent WordPress MCP Serverlist my latest FluentCRM contacts and today's Fluent Forms submissions"
That's it! The server will respond to your query, and you can continue using it as needed.
Here is a step-by-step guide with screenshots.
Fluent WordPress MCP Server & CLI
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 --agentMCP 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@latestWhich 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 |
|
|
fcrm update contact |
|
|
fcrm list campaigns |
|
|
fc list spaces |
|
|
fc create feed |
|
|
fc create comment |
|
|
ff list submissions |
|
|
ff form stats |
|
|
List configured sites |
|
|
Read one native Community member report |
|
|
Review exact ordered cross-plugin tasks |
|
|
Execute reviewed cross-plugin tasks |
|
|
Save bounded cross-plugin responses privately |
|
|
Contents
Number | Section | What it covers |
1 | What you can ask it | |
2 | Quick install | |
3 | Set up Fluent WordPress access | |
4 | Connect your client | |
5 | Check it works | |
6 | Output, flags and exit codes | |
7 | MCP or CLI and token cost | |
8 | Every tool and argument | |
9 | CRM, Community and Forms workflows | |
10 | Exact reviewed batches and snapshots | |
11 | Several private sites | |
12 | Writing safely | |
13 | How the two surfaces work | |
14 | Your data | |
15 | Environment variables | |
16 | Updates and removal | |
17 | Troubleshooting | |
18 | API coverage and comparisons | |
19 | Versions and migration | |
20 | 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 loginNode22+ 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
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.
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.
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.
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.
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 list5. 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.idCredential-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 |
| 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 |
| 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-statsfcrm_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 |
| Optional; native body and guard rules still apply | string | Type of filtering to apply. enum: ["simple", "advanced"]. default: "simple". |
| Optional; native body and guard rules still apply | string | Search contacts by name, email, or other searchable fields. |
| Optional; native body and guard rules still apply | string | Column to sort by. default: "id". |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["ASC", "DESC"]. default: "DESC". |
| Optional; native body and guard rules still apply | string | Filter by commerce integration availability. |
| Optional; native body and guard rules still apply | string | Set to |
| Optional; native body and guard rules still apply | array | Filter by tag IDs (simple filter mode only). |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Filter by contact statuses (simple filter mode only). |
| Per item when supplied | string | Array item schema. Enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"] |
| Optional; native body and guard rules still apply | array | Filter by SMS statuses (simple filter mode only). |
| Per item when supplied | string | Array item schema. Enum: ["sms_subscribed", "sms_unsubscribed", "sms_pending", "sms_bounced"] |
| Optional; native body and guard rules still apply | array | Filter by list IDs (simple filter mode only). |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Filter by company IDs. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | string | JSON-encoded advanced filter groups (advanced filter mode only). |
| Optional; native body and guard rules still apply | integer | Number of contacts per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number for pagination. default: 1. minimum: 1. maximum: 10000. |
| 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-contactsfcrm_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 |
| Yes | integer | The contact ID. minimum: 1. |
| Optional; native body and guard rules still apply | string | If set, looks up the contact by email address instead of the path |
| Optional; native body and guard rules still apply | array | Relationships and extra data to include. Supported values: |
| Per item when supplied | string | Array item schema. Enum: ["stats", "subscriber.custom_values", "custom_fields", "commerce_stat"] |
| 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-contactfcrm_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 |
| Optional; native body and guard rules still apply | string | Search term to match against contact name and email. |
| Optional; native body and guard rules still apply | integer | Maximum number of results to return. default: 20. minimum: 1. maximum: 100. |
| 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"]. |
| Optional; native body and guard rules still apply | array | Array of contact IDs to always include in results (useful for pre-selected values). |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | integer | Rows to skip before the first result. Combine with |
| 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-contactsfcrm_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 |
| Optional; native body and guard rules still apply | string | Contact email address. Must be unique unless |
| Optional; native body and guard rules still apply | string | Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | First name. |
| Optional; native body and guard rules still apply | string | Last name. |
| Optional; native body and guard rules still apply | string | Name prefix (e.g., Mr, Mrs, Ms). |
| Optional; native body and guard rules still apply | string | Contact type. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Address line 1. |
| Optional; native body and guard rules still apply | string | Address line 2. |
| Optional; native body and guard rules still apply | string | Postal/zip code. |
| Optional; native body and guard rules still apply | string | City. |
| Optional; native body and guard rules still apply | string | State or province. |
| Optional; native body and guard rules still apply | string | Two-letter country code. |
| Optional; native body and guard rules still apply | string | Phone number. |
| Optional; native body and guard rules still apply | string | Timezone identifier. |
| Optional; native body and guard rules still apply | string | Date of birth (YYYY-MM-DD). |
| Optional; native body and guard rules still apply | string | Contact source. |
| Optional; native body and guard rules still apply | array | Tag IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | boolean | Send double opt-in confirmation email. |
| Optional; native body and guard rules still apply | string | If |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Yes | string | Contact email address. Must be unique unless |
| Yes | string | Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | First name. |
| Optional; native body and guard rules still apply | string | Last name. |
| Optional; native body and guard rules still apply | string | Name prefix (e.g., Mr, Mrs, Ms). |
| Optional; native body and guard rules still apply | string | Contact type. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Address line 1. |
| Optional; native body and guard rules still apply | string | Address line 2. |
| Optional; native body and guard rules still apply | string | Postal/zip code. |
| Optional; native body and guard rules still apply | string | City. |
| Optional; native body and guard rules still apply | string | State or province. |
| Optional; native body and guard rules still apply | string | Two-letter country code. |
| Optional; native body and guard rules still apply | string | Phone number. |
| Optional; native body and guard rules still apply | string | Timezone identifier. |
| Optional; native body and guard rules still apply | string | Date of birth (YYYY-MM-DD). |
| Optional; native body and guard rules still apply | string | Contact source. |
| Optional; native body and guard rules still apply | array | Tag IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | boolean | Send double opt-in confirmation email. |
| Optional; native body and guard rules still apply | string | If |
| 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-contactfcrm_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 |
| Yes | integer | The contact ID. minimum: 1. |
| Optional; native body and guard rules still apply | object | Contact data can be nested inside a |
| Optional; native body and guard rules still apply | string | Email address (must be unique). format: "email". |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | ['string', 'null'] | Date of birth (YYYY-MM-DD). Send null or empty string to clear. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Custom field key-value pairs to update. additionalProperties: {"type": "string"}. |
| Optional; native body and guard rules still apply | array | Tag IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Tag IDs to detach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to detach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Yes | object | Contact data can be nested inside a |
| Optional; native body and guard rules still apply | string | Email address (must be unique). format: "email". |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | ['string', 'null'] | Date of birth (YYYY-MM-DD). Send null or empty string to clear. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Custom field key-value pairs to update. additionalProperties: {"type": "string"}. |
| Optional; native body and guard rules still apply | array | Tag IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Tag IDs to detach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to detach. |
| Per item when supplied | integer | Array item schema. |
| 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-contactfcrm_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 |
| Yes | integer | The contact ID. minimum: 1. |
| Optional; native body and guard rules still apply | string | Search notes by title. |
| Optional; native body and guard rules still apply | integer | Number of notes per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number. default: 1. minimum: 1. maximum: 10000. |
| 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 |
| 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-notesfcrm_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 |
| Yes | integer | The contact ID. minimum: 1. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: ["title", "description", "type"]. |
| Yes | string | Note title. |
| Yes | string | Note content (HTML). Supports SmartCode/merge tags. |
| Yes | string | Note type. enum: ["note", "call", "email", "meeting", "activity"]. |
| Optional; native body and guard rules still apply | string | Custom creation date. Defaults to current time if not provided. format: "date-time". |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Yes | object | Actual shared argument definition. required: ["title", "description", "type"]. |
| Yes | string | Note title. |
| Yes | string | Note content (HTML). Supports SmartCode/merge tags. |
| Yes | string | Note type. enum: ["note", "call", "email", "meeting", "activity"]. |
| Optional; native body and guard rules still apply | string | Custom creation date. Defaults to current time if not provided. format: "date-time". |
| 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-notefcrm_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 |
| Optional; native body and guard rules still apply | string | Search tags by title, slug, or description. |
| Optional; native body and guard rules still apply | string | Column to sort by. enum: ["id", "title", "slug", "created_at"]. default: "id". |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["ASC", "DESC"]. default: "DESC". |
| Optional; native body and guard rules still apply | integer | Number of tags per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number for pagination. default: 1. minimum: 1. maximum: 10000. |
| Optional; native body and guard rules still apply | boolean | If set to any truthy value, subscriber counts will not be included for each tag. |
| Optional; native body and guard rules still apply | boolean | If set to any truthy value, includes a flat |
| 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-tagsfcrm_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 |
| Optional; native body and guard rules still apply | string | Search lists by title, slug, or description. |
| Optional; native body and guard rules still apply | string | Column to sort by. enum: ["id", "title", "slug", "created_at"]. default: "id". |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["ASC", "DESC"]. default: "DESC". |
| Optional; native body and guard rules still apply | integer | Number of lists per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number for pagination. default: 1. minimum: 1. maximum: 10000. |
| Optional; native body and guard rules still apply | boolean | If set to any truthy value, |
| Optional; native body and guard rules still apply | boolean | If set to any truthy value, includes a flat |
| Optional; native body and guard rules still apply | array | Extra data to include. |
| Per item when supplied | string | Array item schema. |
| 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-listsfcrm_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 |
| Optional; native body and guard rules still apply | string | Search campaigns by title. |
| Optional; native body and guard rules still apply | array | Filter by campaign statuses. |
| Per item when supplied | string | Array item schema. Enum: ["draft", "processing", "pending-scheduled", "scheduled", "working", "paused", "archived"] |
| Optional; native body and guard rules still apply | string | Column to sort by. default: "created_at". |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["ASC", "DESC"]. default: "DESC". |
| Optional; native body and guard rules still apply | array | Include related data. Use |
| Per item when supplied | string | Array item schema. Enum: ["stats"] |
| Optional; native body and guard rules still apply | array | Filter by label IDs. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | integer | Number of results per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number. default: 1. minimum: 1. maximum: 10000. |
| 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-campaignsfcrm_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 |
| Yes | integer | The campaign ID. minimum: 1. |
| Optional; native body and guard rules still apply | array | Include related data (e.g., |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | If set, returns the campaign with paginated emails instead of the standard response. |
| 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-campaignfcrm_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 |
| Yes | integer | The campaign ID. minimum: 1. |
| 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-statsfcrm_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 |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["asc", "desc"]. default: "desc". |
| Optional; native body and guard rules still apply | string | Column to sort by. default: "id". |
| Optional; native body and guard rules still apply | string | Search sequences by title. |
| Optional; native body and guard rules still apply | array | Include additional data. Use |
| Per item when supplied | string | Array item schema. Enum: ["stats"] |
| Optional; native body and guard rules still apply | integer | Number of sequences per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number for pagination. default: 1. minimum: 1. maximum: 10000. |
| 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-sequencesfcrm_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 |
| Optional; native body and guard rules still apply | string | Column to sort by. default: "id". |
| Optional; native body and guard rules still apply | string | Sort direction. enum: ["ASC", "DESC"]. default: "DESC". |
| Optional; native body and guard rules still apply | string | Search funnels by title (partial match). |
| Optional; native body and guard rules still apply | array | Filter funnels by label IDs. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Include additional related data. Supported values: |
| Per item when supplied | string | Array item schema. Enum: ["triggers"] |
| Optional; native body and guard rules still apply | integer | Number of funnels per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number for pagination. default: 1. minimum: 1. maximum: 10000. |
| Optional; native body and guard rules still apply | array | Only automations whose contacts carry these tag ids. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Only automations whose contacts are on these list ids. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Filter automations by status, e.g. |
| Per item when supplied | string | Array item schema. |
| 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-automationsfcrm_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 |
| Yes | integer | The funnel ID. minimum: 1. |
| 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-reportfcrm_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 |
| Yes | integer | The contact ID. minimum: 1. |
| Optional; native body and guard rules still apply | string | Filter emails by engagement status. enum: ["open", "click", "unopened"]. |
| Optional; native body and guard rules still apply | string | Email source tab. Use |
| Optional; native body and guard rules still apply | integer | Number of emails per page. default: 15. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Page number. default: 1. minimum: 1. maximum: 10000. |
| 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-emailsfc_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 |
| 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-spacesfc_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 |
| Yes | string | SpaceSlug extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$". |
| 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-spacefc_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 |
| Optional; native body and guard rules still apply | string | Space read via |
| Optional; native body and guard rules still apply | string | User ID read via |
| Optional; native body and guard rules still apply | string | Topic Slug read via |
| Optional; native body and guard rules still apply | string | Search read via |
| Optional; native body and guard rules still apply | string | Status read via |
| Optional; native body and guard rules still apply | integer | Per Page read via |
| Optional; native body and guard rules still apply | integer | Page read via |
| Optional; native body and guard rules still apply | array | Search In read via |
| Optional; native body and guard rules still apply | string | Order By Type read via |
| Optional; native body and guard rules still apply | string | Disable Sticky read via |
| 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-feedsfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Prose-documented delegated edit context, requiring native post edit access. enum: ["view", "edit"]. |
| 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-feedfc_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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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-feedfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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-feedfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| 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-feedfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| 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-commentsfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| 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-commentfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Yes | integer | Comment ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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"]. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| 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-commentfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Yes | integer | Comment ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| 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-commentfc_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 |
| Yes | integer | Feed ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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-feedfc_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 |
| Optional; native body and guard rules still apply | string | Status read via |
| Optional; native body and guard rules still apply | string | Sort By read via |
| Optional; native body and guard rules still apply | string | Topic Slug read via |
| Optional; native body and guard rules still apply | string | Search read via |
| Optional; native body and guard rules still apply | string | With Categories read via |
| 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-coursesfc_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 |
| Yes | integer | Course ID extracted from the URL path. minimum: 1. |
| 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-coursefc_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 |
| Yes | integer | Course ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Search read via |
| Optional; native body and guard rules still apply | string | Sort By read via |
| Optional; native body and guard rules still apply | string | Sort Dir read via |
| 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-studentsfc_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 |
| Yes | integer | Course ID extracted from the URL path. minimum: 1. |
| Optional; native body and guard rules still apply | string | Topic ID read via |
| 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-lessonsfc_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 |
| Yes | string | SpaceSlug extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$". |
| Optional; native body and guard rules still apply | string | Search read via |
| Optional; native body and guard rules still apply | string | Status read via |
| Optional; native body and guard rules still apply | string | Sort By read via |
| Optional; native body and guard rules still apply | string | Sort Dir read via |
| 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-membersfc_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 |
| Yes | string | Username extracted from the URL path. minLength: 1. pattern: "^(?!\.{1,2}$)[^/\\\\\\x00-\\x1f?#]+$". |
| 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-profilefc_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 |
| Optional; native body and guard rules still apply | string | User ID read via |
| 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-postsfc_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 |
| 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-membersfc_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 |
| 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-commentersfc_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 |
| 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-startersfc_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 |
| 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-activityff_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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["ASC", "DESC"]. |
| Optional; native body and guard rules still apply | integer | Actual shared argument definition. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Actual shared argument definition. minimum: 1. maximum: 10000. |
| 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-formsff_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 |
| Yes | integer | Actual shared argument definition. minimum: 1. |
| 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-formff_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 |
| Yes | integer | Actual shared argument definition. minimum: 1. |
| 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-fieldsff_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 |
| Yes | integer | Actual shared argument definition. minimum: 1. |
| Optional; native body and guard rules still apply | integer | Actual shared argument definition. minimum: 1. maximum: 100. |
| Optional; native body and guard rules still apply | integer | Actual shared argument definition. minimum: 1. maximum: 10000. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. minItems: 2. maxItems: 2. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["ASC", "DESC"]. |
| 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-submissionsff_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 |
| Yes | integer | Actual shared argument definition. minimum: 1. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Exact configured private account profile label; not a tenant or provider account ID. |
| 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-reportff_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 |
| Optional; native body and guard rules still apply | integer | Actual shared argument definition. minimum: 1. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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-statsget_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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["view", "embed"]. |
| 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-userlist_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-accountsget_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 |
| 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-schemafc_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 |
| Optional; native body and guard rules still apply | string | Exact configured private site profile label, not a verified site-owner identity. |
| 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-overviewpreview_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 |
| 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. |
| Per item when supplied | object | Array item schema. |
| 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"]. |
| Yes | object | Native arguments without account, confirm, payload_file or output_file; complete payload is allowed. |
| 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-batchsubmit_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 |
| 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. |
| Per item when supplied | object | Array item schema. |
| 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"]. |
| Yes | object | Native arguments without account, confirm, payload_file or output_file; complete payload is allowed. |
| Optional; native body and guard rules still apply | string | Exact configured private site profile label, not a verified site-owner identity. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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-batchread_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 |
| 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. |
| Per item when supplied | object | Array item schema. |
| 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"]. |
| Yes | object | Native arguments without account, confirm, payload_file or output_file; complete payload is allowed. |
| 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-snapshotsave_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 |
| 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. |
| Per item when supplied | object | Array item schema. |
| 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"]. |
| Yes | object | Native arguments without account, confirm, payload_file or output_file; complete payload is allowed. |
| Optional; native body and guard rules still apply | string | Exact configured private site profile label, not a verified site-owner identity. |
| Optional; native body and guard rules still apply | boolean | Set true only when the user asked for exactly this action. |
| 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-snapshotNative 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.
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.
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 |
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.
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 |
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: |
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.
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 |
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.
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 |
| Yes | string | Contact email address. Must be unique unless |
| Yes | string | Contact subscription status. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | First name. |
| Optional; native body and guard rules still apply | string | Last name. |
| Optional; native body and guard rules still apply | string | Name prefix (e.g., Mr, Mrs, Ms). |
| Optional; native body and guard rules still apply | string | Contact type. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Address line 1. |
| Optional; native body and guard rules still apply | string | Address line 2. |
| Optional; native body and guard rules still apply | string | Postal/zip code. |
| Optional; native body and guard rules still apply | string | City. |
| Optional; native body and guard rules still apply | string | State or province. |
| Optional; native body and guard rules still apply | string | Two-letter country code. |
| Optional; native body and guard rules still apply | string | Phone number. |
| Optional; native body and guard rules still apply | string | Timezone identifier. |
| Optional; native body and guard rules still apply | string | Date of birth (YYYY-MM-DD). |
| Optional; native body and guard rules still apply | string | Contact source. |
| Optional; native body and guard rules still apply | array | Tag IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to assign. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | boolean | Send double opt-in confirmation email. |
| Optional; native body and guard rules still apply | string | If |
{
"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.
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 |
| Yes | object | Contact data can be nested inside a |
| Optional; native body and guard rules still apply | string | Email address (must be unique). format: "email". |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["subscribed", "pending", "unsubscribed", "bounced", "complained"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. enum: ["lead", "customer"]. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | ['string', 'null'] | Date of birth (YYYY-MM-DD). Send null or empty string to clear. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Custom field key-value pairs to update. additionalProperties: {"type": "string"}. |
| Optional; native body and guard rules still apply | array | Tag IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | Tag IDs to detach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to attach. |
| Per item when supplied | integer | Array item schema. |
| Optional; native body and guard rules still apply | array | List IDs to detach. |
| 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.
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 |
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.
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 |
| Yes | object | Actual shared argument definition. required: ["title", "description", "type"]. |
| Yes | string | Note title. |
| Yes | string | Note content (HTML). Supports SmartCode/merge tags. |
| Yes | string | Note type. enum: ["note", "call", "email", "meeting", "activity"]. |
| 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.
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 |
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.
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, |
all_lists | query | No | {"type": "boolean", "description": "If set to any truthy value, includes a flat |
with[] | query | No | {"type": "array", "items": {"type": "string"}, "description": "Extra data to include. |
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.
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 |
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.
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., |
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.
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.
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 |
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.
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: |
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. |
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.
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.
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 |
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
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
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
Native argument | Location | Required | Schema |
space | query | No | {"type": "string", "description": "Space read via |
user_id | query | No | {"type": "string", "description": "User ID read via |
topic_slug | query | No | {"type": "string", "description": "Topic Slug read via |
search | query | No | {"type": "string", "description": "Search read via |
status | query | No | {"type": "string", "description": "Status read via |
per_page | query | No | {"type": "integer", "default": 10, "description": "Per Page read via |
page | query | No | {"type": "integer", "default": 1, "description": "Page read via |
search_in | query | No | {"type": "array", "default": ["post_content"], "description": "Search In read via |
order_by_type | query | No | {"type": "string", "description": "Order By Type read via |
disable_sticky | query | No | {"type": "string", "description": "Disable Sticky read via |
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
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.
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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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.
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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | object | Actual shared argument definition. required: []. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| Optional; native body and guard rules still apply | array | Actual shared argument definition. |
| Per item when supplied | string | Array item schema. |
| Yes | string | Actual shared argument definition. minLength: 1. |
| 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.
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
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.
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 |
| 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.
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 |
| 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.
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.
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 |
| Optional; native body and guard rules still apply | string | Actual shared argument definition. |
| 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
Native argument | Location | Required | Schema |
status | query | No | {"type": "string", "description": "Status read via |
sort_by | query | No | {"type": "string", "default": "latest", "description": "Sort By read via |
topic_slug | query | No | {"type": "string", "description": "Topic Slug read via |
search | query | No | {"type": "string", "description": "Search read via |
with_categories | query | No | {"type": "string", "description": "With Categories read via |
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
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
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 |
sort_by | query | No | {"type": "string", "default": "created_at", "description": "Sort By read via |
sort_dir | query | No | {"type": "string", "description": "Sort Dir read via |
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
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 |
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
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 |
status | query | No | {"type": "string", "description": "Status read via |
sort_by | query | No | {"type": "string", "default": "created_at", "description": "Sort By read via |
sort_dir | query | No | {"type": "string", "description": "Sort Dir read via |
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
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.
Native argument | Location | Required | Schema |
user_id | query | No | {"type": "string", "default": "$currentUserId", "description": "User ID read via |
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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 --helpRead 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-commentRead 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 --help123 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-snapshotEach --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 --agent12. 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 |
| Safety |
FLUENT_WP_SURFACE |
| 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 |
FLUENT_WP_HTTP_ALLOWED_ORIGINS | Comma-separated browser origins allowed to call | HTTP |
FLUENT_WP_DEBUG |
| 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-cli17. 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
Personal website: navid.me
Link in bio: navid.bio
Navid Media: navid.media
YouTube: @thenavidm and @thenavidai
X: @thenavidm
Instagram: @thenavidm
LinkedIn: thenavidm
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 toolsfc_analytics_member_activityfc analytics member activityARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 reportCRead-onlyIdempotent
Retained legacy selector mapped to four fixed reviewed native Pro report routes. Not a whole-community analytics export; native report permissions apply.
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | One native report, default top-members. | |
| account | No | Exact configured private site profile label, not a verified site-owner identity. |
TDQS
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.
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.
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.
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.
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.
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 commentersARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 membersARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 startersARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 lessonsBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| topic_id | No | Topic ID read via `$request->get()` in getLessons(). | |
| course_id | Yes | Course ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 studentsBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search read via `$request->getSafe()` in getCourseStudents(). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Sort By read via `$request->getSafe()` in getCourseStudents(). | created_at |
| sort_dir | No | Sort Dir read via `$request->getSafe()` in getCourseStudents(). | |
| course_id | Yes | Course ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 commentADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| comment | No | ||
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. | |
| payload | No | 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. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
TDQS
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.
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.
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.
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.
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.
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 feedBDestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| space | No | ||
| title | No | ||
| survey | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| message | No | ||
| payload | No | 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. | |
| topic_ids | No | ||
| content_type | No | ||
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. | |
| send_announcement_email | No |
TDQS
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.
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.
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.
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.
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.
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 commentADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. | |
| comment_id | Yes | Comment ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 feedADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 courseARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| course_id | Yes | Course ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 feedARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| context | No | Prose-documented delegated edit context, requiring native post edit access. | |
| feed_id | Yes | Feed ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 profileBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| username | Yes | Username extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 spaceBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | SpaceSlug extracted from the URL path. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 commentsARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| feed_id | Yes | Feed ID extracted from the URL path. |
TDQS
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.
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.
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.
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.
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.
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 coursesBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| search | No | Search read via `$request->getSafe()` in getCourses(). | |
| status | No | Status read via `$request->getSafe()` in getCourses(). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Sort By read via `$request->getSafe()` in getCourses(). | latest |
| topic_slug | No | Topic Slug read via `$request->getSafe()` in getCourses(). | |
| with_categories | No | With Categories read via `$request->get()` in getCourses(). |
TDQS
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.
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.
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.
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.
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.
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 feedsARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page read via `$request->get()` in get(). | |
| space | No | Space read via `$request->get()` in get(). | |
| search | No | Search read via `$request->getSafe()` in get(). | |
| status | No | Status read via `$request->getSafe()` in get(). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| user_id | No | User ID read via `$request->getSafe()` in get(). | |
| per_page | No | Per Page read via `$request->get()` in get(). | |
| search_in | No | Search In read via `$request->get()` in get(). | |
| topic_slug | No | Topic Slug read via `$request->getSafe()` in get(). | |
| order_by_type | No | Order By Type read via `$request->getSafe()` in get(). | |
| disable_sticky | No | Disable Sticky read via `$request->get()` in get(). |
TDQS
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.
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.
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.
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.
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.
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 spacesBRead-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
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 feedADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| remove | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. | |
| payload | No | 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. | |
| react_type | No | ||
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
TDQS
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.
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.
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.
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.
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.
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 noteADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The contact ID. | |
| note | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| payload | No | 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. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
TDQS
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.
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.
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.
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.
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.
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 reportARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The funnel ID. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 statsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The campaign ID. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 emailsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The contact ID. | |
| tab | No | Email source tab. Use `fluentsmtp` to show FluentSMTP logs instead of CRM campaign emails. | crm |
| page | No | Page number. | |
| filter | No | Filter emails by engagement status. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| per_page | No | Number of emails per page. |
TDQS
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.
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.
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.
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.
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.
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 notesBRead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The contact ID. | |
| page | No | Page number. | |
| search | No | Search notes by title. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| per_page | No | Number of notes per page. | |
| include_id | No | 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. |
TDQS
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.
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.
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.
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.
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.
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 contactADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| city | No | City. | |
| tags | No | Tag IDs to assign. | |
| No | Contact email address. Must be unique unless `__force_update` is `yes`. | ||
| lists | No | List IDs to assign. | |
| phone | No | Phone number. | |
| state | No | State or province. | |
| prefix | No | Name prefix (e.g., Mr, Mrs, Ms). | |
| source | No | Contact source. | |
| status | No | Contact subscription status. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| country | No | Two-letter country code. | |
| payload | No | 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. | |
| timezone | No | Timezone identifier. | |
| last_name | No | Last name. | |
| first_name | No | First name. | |
| postal_code | No | Postal/zip code. | |
| contact_type | No | Contact type. | |
| double_optin | No | Send double opt-in confirmation email. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. | |
| date_of_birth | No | Date of birth (YYYY-MM-DD). | |
| __force_update | No | If `yes`, updates existing contact with the same email instead of failing. | |
| address_line_1 | No | Address line 1. | |
| address_line_2 | No | Address line 2. |
TDQS
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.
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.
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.
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.
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.
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 statsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
TDQS
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.
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.
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.
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.
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.
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 campaignARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The campaign ID. | |
| with | No | Include related data (e.g., `template`, `subjects`). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| viewCampaign | No | If set, returns the campaign with paginated emails instead of the standard response. |
TDQS
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.
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.
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.
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.
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.
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 contactARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The contact ID. | |
| with | No | Relationships and extra data to include. Supported values: `stats`, `subscriber.custom_values`, `custom_fields`, `commerce_stat`. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| get_by_email | No | If set, looks up the contact by email address instead of the path `id`. |
TDQS
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.
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.
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.
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.
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.
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 automationsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| tags | No | Only automations whose contacts carry these tag ids. | |
| with | No | Include additional related data. Supported values: `triggers`. | |
| lists | No | Only automations whose contacts are on these list ids. | |
| labels | No | Filter funnels by label IDs. | |
| search | No | Search funnels by title (partial match). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Column to sort by. | id |
| per_page | No | Number of funnels per page. | |
| statuses | No | Filter automations by status, e.g. `published` or `draft`. | |
| sort_type | No | Sort direction. | DESC |
TDQS
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.
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.
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.
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.
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.
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 campaignsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number. | |
| with | No | Include related data. Use `stats` to include campaign statistics and labels. | |
| labels | No | Filter by label IDs. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Column to sort by. | created_at |
| per_page | No | Number of results per page. | |
| searchBy | No | Search campaigns by title. | |
| statuses | No | Filter by campaign statuses. | |
| sort_type | No | Sort direction. | DESC |
TDQS
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.
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.
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.
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.
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.
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 contactsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| tags | No | Filter by tag IDs (simple filter mode only). | |
| lists | No | Filter by list IDs (simple filter mode only). | |
| search | No | Search contacts by name, email, or other searchable fields. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Column to sort by. | id |
| per_page | No | Number of contacts per page. | |
| statuses | No | Filter by contact statuses (simple filter mode only). | |
| sort_type | No | Sort direction. | DESC |
| company_ids | No | Filter by company IDs. | |
| filter_type | No | Type of filtering to apply. | simple |
| has_commerce | No | Filter by commerce integration availability. | |
| sms_statuses | No | Filter by SMS statuses (simple filter mode only). | |
| custom_fields | No | Set to `true` to include custom field values in the response. | |
| advanced_filters | No | JSON-encoded advanced filter groups (advanced filter mode only). |
TDQS
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.
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.
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.
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.
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.
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 listsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| with | No | Extra data to include. `subscribersCount` adds per-list contact counts via one grouped pivot query. | |
| search | No | Search lists by title, slug, or description. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Column to sort by. | id |
| per_page | No | Number of lists per page. | |
| all_lists | No | If set to any truthy value, includes a flat `all_lists` array with id, title, and slug of every list (useful for dropdowns). | |
| sort_order | No | Sort direction. | DESC |
| exclude_counts | No | If set to any truthy value, `totalCount` and `subscribersCount` will not be included for each list. |
TDQS
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.
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.
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.
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.
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.
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 sequencesBRead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| with | No | Include additional data. Use `stats` to include email count, subscriber count, and revenue for each sequence. | |
| order | No | Sort direction. | desc |
| search | No | Search sequences by title. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| orderBy | No | Column to sort by. | id |
| per_page | No | Number of sequences per page. |
TDQS
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.
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.
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.
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.
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.
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 tagsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | Page number for pagination. | |
| search | No | Search tags by title, slug, or description. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Column to sort by. | id |
| all_tags | No | If set to any truthy value, includes a flat `all_tags` array with id, title, and slug of every tag (useful for dropdowns). | |
| per_page | No | Number of tags per page. | |
| sort_order | No | Sort direction. | DESC |
| exclude_counts | No | If set to any truthy value, subscriber counts will not be included for each tag. |
TDQS
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.
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.
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.
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.
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.
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 contactsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Maximum number of results to return. | |
| offset | No | Rows to skip before the first result. Combine with `limit` to page through matches. | |
| search | No | Search term to match against contact name and email. | |
| values | No | Array of contact IDs to always include in results (useful for pre-selected values). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| load_default | No | If truthy and no search term is provided, returns the most recent contacts. |
TDQS
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.
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.
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.
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.
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.
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 contactADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The contact ID. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| payload | No | 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. | |
| subscriber | No | ||
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
TDQS
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.
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.
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.
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.
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.
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 postsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| user_id | No | User ID read via `$request->getSafe()` in getScheduledPosts(). | $currentUserId |
TDQS
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.
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.
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.
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.
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.
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 membersARead-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
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | SpaceSlug extracted from the URL path. | |
| search | No | Search read via `$request->getSafe()` in getMembers(). | |
| status | No | Status read via `$request->get()` in getMembers(). | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | Sort By read via `$request->getSafe()` in getMembers(). | created_at |
| sort_dir | No | Sort Dir read via `$request->getSafe()` in getMembers(). |
TDQS
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.
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.
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.
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.
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.
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 commentADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| comment | No | ||
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. | |
| payload | No | 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. | |
| comment_id | Yes | Comment ID extracted from the URL path. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
TDQS
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.
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.
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.
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.
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.
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 feedADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| title | No | ||
| status | No | ||
| survey | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| feed_id | Yes | Feed ID extracted from the URL path. | |
| message | No | ||
| payload | No | 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. | |
| topic_ids | No | ||
| content_type | No | ||
| media_images | No | ||
| new_space_id | No | ||
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. | |
| move_to_profile | No | ||
| send_announcement_email | No |
TDQS
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.
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.
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.
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.
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.
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 fieldsARead-onlyIdempotent
Read current native field definitions; no field edits. Requires fluentform_forms_manager for the selected form.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| form_id | Yes |
TDQS
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.
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.
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.
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.
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.
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 reportADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| form_id | Yes | ||
| statuses | No |
TDQS
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.
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.
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.
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.
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.
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 statsARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| metric | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| form_id | No | ||
| end_date | No | ||
| start_date | No |
TDQS
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.
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.
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.
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.
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.
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 formARead-onlyIdempotent
Read one native form with formMeta; may include private integration/settings data. Requires fluentform_forms_manager for the selected form.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| form_id | Yes |
TDQS
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.
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.
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.
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.
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.
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 formsBRead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| search | No | ||
| status | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| sort_by | No | ||
| per_page | No | ||
| filter_by | No | ||
| date_range | No | ||
| sort_column | No |
TDQS
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.
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.
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.
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.
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.
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 submissionsBRead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| page | No | ||
| search | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| form_id | Yes | ||
| sort_by | No | ||
| per_page | No | ||
| date_range | No | ||
| entry_type | No | ||
| payment_statuses | No |
TDQS
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.
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.
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.
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.
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.
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 userARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| context | No |
TDQS
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.
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.
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.
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.
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.
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 operationARead-onlyIdempotent
Local method/path/query/body schema and pinned provenance for one selected native tool. No provider call or credentials.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Actual native tool name, including fc_update_feed and ff_list_submissions. |
TDQS
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.
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.
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.
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.
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.
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 sitesCRead-onlyIdempotent
Local profile labels/default/credential source only; no site URL, username, password path, provider identity or network request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
TDQS
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.
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.
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.
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.
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.
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 tasksARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. | |
| account | No | Exact configured private site profile label, not a verified site-owner identity. |
TDQS
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.
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.
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.
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.
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.
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 responsesARead-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.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. | |
| account | No | Exact configured private site profile label, not a verified site-owner identity. |
TDQS
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.
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.
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.
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.
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.
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 privatelyADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. | |
| account | No | Exact configured private site profile label, not a verified site-owner identity. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| output_file | Yes | Absolute new file in an existing private directory; restrict Windows ACLs separately. |
TDQS
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.
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.
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.
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.
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.
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 tasksADestructive
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.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered native requests. Each read is one native response/page; no automatic pagination, URL following, polling or cross-site override. | |
| account | No | Exact configured private site profile label, not a verified site-owner identity. | |
| confirm | No | Set true only when the user asked for exactly this action. | |
| review_sha256 | Yes | Exact preview_site_batch hash for unchanged tasks, site profile and schema. |
TDQS
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.
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.
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.
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.
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.
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.
54 tool updates
v3.0.0- First observed
fc_analytics_member_activity - First observed
fc_analytics_overview - First observed
fc_analytics_top_commenters - First observed
fc_analytics_top_members - First observed
fc_analytics_top_post_starters - First observed
fc_course_lessons - First observed
fc_course_students - First observed
fc_create_comment - First observed
fc_create_feed - First observed
fc_delete_comment - First observed
fc_delete_feed - First observed
fc_get_course - First observed
fc_get_feed - First observed
fc_get_profile - First observed
fc_get_space - First observed
fc_list_comments - First observed
fc_list_courses - First observed
fc_list_feeds - First observed
fc_list_spaces - First observed
fc_react_to_feed - First observed
fc_scheduled_posts - First observed
fc_space_members - First observed
fc_update_comment - First observed
fc_update_feed - First observed
fcrm_add_contact_note - First observed
fcrm_automation_report - First observed
fcrm_campaign_stats - First observed
fcrm_contact_emails - First observed
fcrm_contact_notes - First observed
fcrm_create_contact - First observed
fcrm_dashboard_stats - First observed
fcrm_get_campaign - First observed
fcrm_get_contact - First observed
fcrm_list_automations - First observed
fcrm_list_campaigns - First observed
fcrm_list_contacts - First observed
fcrm_list_lists - First observed
fcrm_list_sequences - First observed
fcrm_list_tags - First observed
fcrm_search_contacts - First observed
fcrm_update_contact - First observed
ff_form_fields - First observed
ff_form_report - First observed
ff_form_stats - First observed
ff_get_form - First observed
ff_list_forms - First observed
ff_list_submissions - First observed
get_current_user - First observed
get_operation_schema - First observed
list_accounts - First observed
preview_site_batch - First observed
read_site_snapshot - First observed
save_site_snapshot - First observed
submit_site_batch
TDQS
Scored across 54 tools
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.
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.
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.
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
Related MCP Connectors
Manage WordPress blogs and WooCommerce shops from Claude, ChatGPT, Cursor and other MCP apps.
Supervised API-write gateway for AI agents with policy, human approval and execution receipts.
Governed memory and workspace for any AI: tasks, calendar, mail and pages, with per-action consent.
Security-first WordPress MCP server. 129 tools for Claude, ChatGPT, Gemini. Free on wp.org.
Related MCP Servers
- FlicenseCqualityDmaintenanceEnables 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.3613-
- FlicenseNot gradedqualityCmaintenanceEnables AI agents to manage WordPress sites via ~74 capabilities including content, media, plugins, themes, and more.-
- AlicenseNot gradedqualityAmaintenanceA 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.4GPL 2.0
- AlicenseAqualityCmaintenanceEnables 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.45MIT