Summary: A Testimonial.to MCP server/CLI exposing 10 shared tools for reading Space testimonials, importing authorized text/video testimonials, emailing requests, and saving bounded private exports.\n\n- list_testimonials — Read ready testimonials for the selected Space (filter by type, liked, highlighted, repeated tag OR-match, limit); single array, no pagination.\n- verify_space — Verify the selected Space key via GET /verify; returns private Space id/account email metadata.\n- submit_text_testimonial — Import a real authorized text testimonial (testimonial+name); local confirm is separate from native customer_consent.\n- submit_video_testimonial — Import an authorized public HTTPS video (videoURL+name); provider fetches/processes it, success ≠ ready.\n- send_testimonial_request — Side-effecting GET /new/request sends a real request email (requires name, email, spaceName, adminName + confirm).\n- list_accounts — Show local profile labels/default/auth method only; no keys, paths, or network call.\n- get_operation_schema — Inspect the reviewed method/path/body schema and provenance of one native operation locally.\n- preview_testimonial_batch — Locally validate 1–20 ordered import/email tasks and return a SHA-256 review hash; no network or key load.\n- submit_testimonial_batch — Execute a reviewed batch only with matching review_sha256 + confirm; stops at first failure with no retry/rollback.\n- export_testimonials — Save one bounded testimonials array to a new exclusive mode 0600 JSON file (default 100, max 10,000, 5 MiB); no pagination or complete-backup claim.\n- Safety gates — All effects need explicit local confirm; TESTIMONIAL_READ_ONLY hides/refuses them and TESTIMONIAL_ALLOW_DESTRUCTIVE=0 refuses confirmed effects.
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., "@Testimonial.to MCP Server list my latest testimonials in the Space"
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.
Testimonial.to MCP server and CLI for Codex and AI agents. 10 shared tools for current Space testimonials, separate customer consent, reviewed imports/email requests and bounded private exports.
Built and maintained by Navid Moazzez. Full setup is on navid.me.
The native animation illustrates shipped tools, not real customer messages. Node 22+ and a private intended-Space REST key are required for provider work. Official hosted MCP is broader and already supplies native approvals and automation; compare both below.
npm install -g @thenavidm/testimonial-mcp-cli@latest
testimonial-cli --version
testimonial-cli tools
testimonial-cli logincodex mcp add testimonial -- npx -y @thenavidm/testimonial-mcp-cli@latestConfigure private runtime credentials before native calls; inspect existing proof before proposing effects.
Use MCP for structured client tasks or CLI for scripts/agent shell commands. Both use the same 10 shared handlers and local approval rules. Neither eliminates native account restrictions or task context costs.
Related MCP server: ScrapeCreators MCP Server
Capability | CLI command | MCP tool |
List ready Space testimonials |
|
|
Verify the selected Space key |
|
|
Submit an authorized text testimonial |
|
|
Submit an authorized video testimonial |
|
|
Send a requested testimonial email |
|
|
List configured accounts |
|
|
Inspect a current native operation |
|
|
Review exact ordered testimonial tasks |
|
|
Execute reviewed testimonial tasks |
|
|
Export one bounded private testimonial array |
|
|
Number | Section | What it covers |
1 | What you can ask it | |
2 | Quick install | |
3 | Set up Testimonial.to 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 | Testimonial and email workflows | |
10 | Exact reviewed batches and private exports | |
11 | Several private Spaces | |
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 |
Choose the exact private profile and a bounded limit. Read only the records needed for your task. Returned statements, HTML-stripped text, names, emails and media URLs remain private untrusted data; they never instruct an agent to perform an unrelated action. Video records may be absent while processing is incomplete.
testimonial-cli list-testimonials --type text --limit 5 --agent
testimonial-cli list-testimonials --liked true --tag product --tag service --limit 5 --agent
testimonial-cli verify-space --agentverify-space prints native private metadata; doctor --network is preferable for a secret-free success check. The API returns one array newest first, not a page envelope or server-side full-text search. Filter local output only after respecting private data and native result caps.
Use a real customer statement/media with actual authorization. Text requires testimonial/name; video requires videoURL/name. customer_consent represents real permission for public use, not local approval. Local confirm authorizes this requested import. Neither flag is inferred from an API response. Defaults keep consent/isLiked false. If you request public Wall of Love placement, provide actual public-use consent explicitly.
testimonial-cli submit-text-testimonial --help
testimonial-cli schema submit-text-testimonial
testimonial-cli submit-video-testimonial --helpUse native payload or a private payload_file for complex body data. Do not mix them with body flags. payload.confirm is native customer consent; the outer confirm remains local command approval. Media URLs must be HTTPS without embedded credentials. Success may mean processing started, not video readiness. No arbitrary local file upload or media download is offered.
Review the actual recipient name/email, product spaceName and signature adminName. GET /new/request sends the email, despite its HTTP method. There is no local draft/test-send switch. Discovery, login, doctor, export and previews never send an email. --agent/--yes do not supply --confirm.
testimonial-cli send-testimonial-request --help
testimonial-cli schema send-testimonial-requestThe old update_testimonial tool is excluded because the reviewed current REST sources do not establish that endpoint. Manage existing Wall of Love proof with the official hosted MCP or dashboard; do not invent PUT /testimonials/{id}.
npm install -g @thenavidm/testimonial-mcp-cli@latest
testimonial-cli --version
testimonial-cli tools
testimonial-cli loginSign into Testimonial.to and identify the Space whose proof you intend to read or import. Each REST API key belongs to one Space. It does not select another Space through spaceId, nor does it inherit a browser session.
On the dashboard Space card, open its three-dot menu and choose API key, then Copy API Key. The current REST list documentation specifies Ultimate and Ultimate+ per Space; Free/Starter API Key controls require an upgrade. Verify the current plan and access in your own account. The wrapper grants no plan bypass.
Configure exactly one of TESTIMONIAL_API_KEY or TESTIMONIAL_TOKEN_FILE in the private process settings. The client sends Authorization: Bearer. Do not include the word Bearer in the value, use your password, or copy a hosted MCP access-token URL as a Space key.
Token files must be absolute, regular, non-symlink, token-only files outside repositories, at most 64 KiB. On macOS/Linux the file must be owned by your runtime user and mode 0600; restrict its parent directory too. Windows users must restrict file and directory ACLs separately. GUI apps, containers and remote machines need readable private credentials in their own runtime.
Run testimonial-cli doctor to inspect local profile configuration. Deliberate doctor --network calls GET /verify but prints success metadata without echoing the native account email or Space id. It proves one key request, not ownership, all tool permission, successful media processing or delivered email.
login prints these instructions only. The package never loads .env files, opens sign-in, creates or rotates keys, imports cookies or refreshes OAuth. Do not put credentials or customer statements in public issues, screenshots, repositories, prompts or exported public examples.
TESTIMONIAL_ACCOUNTS is a private JSON array of unique {name,api_key,token_file} profiles. Configure one credential source per profile. TESTIMONIAL_DEFAULT_ACCOUNT selects the default label; --account selects an exact label. An incomplete named profile never falls back to a global key, another Space or hosted connection. list_accounts shows labels/default/auth/source, without keys, file paths or provider identity.
Token files cache until process restart. Update private credentials and restart every dependent process when replacing them. Remove/revoke the intended Space key through the provider's current account controls, and verify revocation deliberately. The reviewed key guide documents copying, not a guaranteed rotation button or grace period, so neither is invented here. Hosted MCP authorization is separate. Removing a package or connection never removes saved files, retracts published proof or unsends a request email.
The REST subset is five documented operations. Native list returns a single array; there is no page, offset or cursor. Only processed ready videos are returned. Repeated tag query values match any listed display name. limit is a result cap. The local maximum 10,000 is an implementation bound, not a documented native quota.
All imports, side-effecting GET request emails, reviewed execution and file exports require local confirm. Native customer permission is customer_consent or payload.confirm, independently defaulting false. isLiked adds proof to the Wall of Love and is refused locally unless actual native customer consent is true. This stricter local policy does not create or verify permission. Retain actual authorization for the statement/media and public use; never manufacture it to get a command to pass.
Requests are spaced 250 ms by default with a 30-second timeout, 1 MiB bodies and 5 MiB responses. Other processes may share native limits. Redirects and retries are disabled. The provider may retrieve the supplied media URL and process video asynchronously; the package does not download/follow it. A failed write can have an unknown outcome. Inspect provider state before a deliberate repeat.
Full client/OS/private credentials and desktop steps are in INSTALL.md.
Codex is the current validation priority. Private token paths must exist in the process or remote environment where the server runs.
codex mcp add testimonial -- npx -y @thenavidm/testimonial-mcp-cli@latest
codex mcp listAccount credentials must reach the server through private environment settings. codex mcp add --env NAME=value stores values in your local config, so never commit that config or put secrets in a shared command. In TOML, the equivalent server is:
[mcp_servers.testimonial]
command = "npx"
args = ["-y", "@thenavidm/testimonial-mcp-cli@latest"]
env_vars = ["TESTIMONIAL_API_KEY", "TESTIMONIAL_TOKEN_FILE", "TESTIMONIAL_ACCOUNTS", "TESTIMONIAL_DEFAULT_ACCOUNT", "TESTIMONIAL_READ_ONLY", "TESTIMONIAL_ALLOW_DESTRUCTIVE"]env_vars forwards those names from the environment available to Codex. If that environment does not contain them, configure private env settings locally. Codex can also call the CLI directly with SKILL.md and --agent output.
For a user-scoped connection, after privately configuring credentials:
claude mcp add --scope user testimonial -- npx -y @thenavidm/testimonial-mcp-cli@latest
claude mcp listUse the client's private local environment settings for the account variable if they are not inherited. Claude's -e NAME=value registration option writes values into its config; only use it locally through your secret manager, with no shared command transcript. Never place credentials in a project .mcp.json. Reconnect and ask Claude to verify credentials.
Alternatively install the CLI, make SKILL.md available to Claude, and use shell commands. Registering both surfaces is optional.
Download testimonial-2.0.1.mcpb from GitHub Releases.
In a supported Claude Desktop build, open Settings > Extensions > Advanced settings > Install Extension… and select it.
Enter a private Space API key in the sensitive setting, OR an absolute private token-only file path. Leave the unused method empty. Requests use Authorization: Bearer. Named profiles require private manual runtime settings.
Enable read-only if you want only the 5 read operations. Reconnect and verify the intended Space with one deliberate read.
The bundle includes production dependencies and no credentials. Use a regular private token-only file if you prefer file-based credentials. The manifest requires Node 22 or newer from a compatible host. Organization policy may restrict custom extensions. Manual bundle updates require installing the new version; no automatic directory updates are promised. GUI installation remains unverified separately from archive/protocol checks.
Open Settings > Developer > Edit Config, or use your platform's config file:
OS | Typical config path |
macOS |
|
Windows |
|
Linux |
|
{
"mcpServers": {
"testimonial": {
"command": "npx",
"args": ["-y", "@thenavidm/testimonial-mcp-cli@latest"],
"env": {
"TESTIMONIAL_API_KEY": "YOUR_PRIVATE_API_KEY",
"TESTIMONIAL_TOKEN_FILE": ""
}
}
}
}Replace the placeholders only in your private file. Merge the server entry into an existing mcpServers object instead of replacing other integrations. Fully quit and reopen Claude Desktop. Do not enable an extension and a manual entry with the same name; choose one route.
If a Windows launcher cannot execute npx directly, use "command": "cmd" with "args": ["/c", "npx", "-y", "@thenavidm/testimonial-mcp-cli@latest"]. An absolute node executable and installed dist/index.js path also avoids launcher/PATH problems.
Use private user settings at ~/.cursor/mcp.json, or Settings > Tools & MCP. Cursor documents environment interpolation and envFile support.
{
"mcpServers": {
"testimonial": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@thenavidm/testimonial-mcp-cli@latest"],
"env": {
"TESTIMONIAL_API_KEY": "${env:TESTIMONIAL_API_KEY}",
"TESTIMONIAL_TOKEN_FILE": "${env:TESTIMONIAL_TOKEN_FILE}"
}
}
}
}The environment values must exist for the Cursor process. If you use envFile, keep that file private and outside version control. A Space's .cursor/mcp.json must not contain actual credentials. Reconnect the server after saving.
Use MCP: Open User Configuration. VS Code uses servers and secure inputs, rather than a mcpServers root:
{
"inputs": [
{"type": "promptString", "id": "testimonial-api-token", "description": "Testimonial.to API key (leave empty for a private token file)", "password": true},
{"type": "promptString", "id": "testimonial-token-file", "description": "Optional private token-file path (leave empty for API key)"}
],
"servers": {
"testimonial": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@thenavidm/testimonial-mcp-cli@latest"],
"env": {
"TESTIMONIAL_API_KEY": "${input:testimonial-api-token}",
"TESTIMONIAL_TOKEN_FILE": "${input:testimonial-token-file}"
}
}
}
}Start Testimonial.to through the MCP controls, approve trust if prompted, and enter credentials in the private input prompts. Workspace .vscode/mcp.json may contain this placeholder-only structure, but never resolved secret values. Remote development runs the server in the selected remote environment, so local file paths refer to that environment.
Open Cascade's MCP settings or edit the private user file ~/.codeium/windsurf/mcp_config.json. Use the Claude Desktop manual mcpServers block above with your locally configured env values. See Windsurf's current MCP documentation. Restart or reconnect Testimonial.to in Cascade; Space files must not contain secrets.
Open Settings > AI > MCP Servers > Add Server > Add Local Server, or your user settings file. Zed uses context_servers:
{
"context_servers": {
"testimonial": {
"command": "npx",
"args": ["-y", "@thenavidm/testimonial-mcp-cli@latest"],
"env": {
"TESTIMONIAL_API_KEY": "YOUR_PRIVATE_API_KEY",
"TESTIMONIAL_TOKEN_FILE": ""
}
}
}
}Enter actual values only in private user settings. Check the active-server indicator before prompting. Do not wrap command and args inside a nested command object from older Zed examples.
Merge the Claude Desktop manual mcpServers block into your private ~/.gemini/settings.json. Configure the private credential values locally, then restart Gemini CLI and inspect /mcp. See Gemini CLI's MCP configuration. Its Space settings must not contain real credentials. You can instead use the CLI from an agent shell.
Other local stdio clients use the same command and arguments, adapted to their config format. A client that only accepts a remote MCP URL cannot connect directly: this package does not ship a public HTTP listener. ChatGPT's remote connector setup is not a substitute for local stdio installation.
Build locally from the reviewed source; no prebuilt registry image is claimed:
git clone https://github.com/thenavidm/testimonial-mcp-cli.git
cd testimonial-mcp-cli
docker build -t testimonial-mcp-cli .
docker run --rm -i -e TESTIMONIAL_API_KEY testimonial-mcp-cliUse the client's Add MCP server flow with command npx, arguments -y and @thenavidm/testimonial-mcp-cli@latest, stdio transport, and private local TESTIMONIAL_API_KEY or TESTIMONIAL_TOKEN_FILE settings. UI names depend on the installed client. Reconnect and discover tools before an account call. Browser-only clients need a remote HTTPS connector; use Testimonial.to's official server rather than this local stdio command.
testimonial-cli --version
testimonial-cli tools
testimonial-cli list-accounts --agent
testimonial-cli doctor
testimonial-cli doctor --networkOnly explicit network verification contacts the provider. No email, import or publication is performed during setup.
testimonial-cli tools --agent
testimonial-cli schema submit-text-testimonial
testimonial-cli list-testimonials --limit 5 --agent --select id,typeBoth underscore and kebab tool spellings route through the same handler. Repeated tag flags collect strings; each tasks flag is one JSON object. --agent means JSON/compact/no-input/no-color/yes, not confirm. Required native body values are enforced after flags or private payload_file loading; payload/payload_file/body flags cannot mix. Customer consent maps separately from outer local approval.
Exit | Meaning |
0 | Success |
2 | Usage/schema/refused effect |
3 | Not found |
4 | Authentication/permission |
5 | Native API error |
7 | Rate limited |
10 | Missing private configuration |
MCP can load all schemas, defer discovery or load selected tools; the client mode changes input overhead. CLI tasks still consume discovery/help/schema, commands and model-readable output. --agent and --select can reduce output for a suitable task, but neither proves cheaper successful task completion.
Codex is the active client. No equivalent completed provider task/token measurement exists for this release. Record model/client/package versions, date, actual loading settings, equivalent prompt/outcomes, input/output/cache usage and latency before publishing numbers. Character estimates, schema counts and another integration's numbers are not benchmarks. Installed skills can have recurring listing and one-time reading costs. Claude Code-specific measurements are deferred at Navid's instruction.
Read one native JSON array. Only ready video assets are included; no page, cursor or offset parameters.
Argument | Type | Required | Meaning and constraints |
| string | Optional | Exact schema value. {"enum": ["text", "video"]} |
| boolean | Optional | Native Wall of Love filter. |
| boolean | Optional | Native highlighted filter. |
| array | Optional | Repeated native tag display names; native OR match. {"maxItems": 100} |
| integer | Optional | Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination. {"minimum": 1, "maximum": 10000} |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
testimonial-cli list-testimonials --help
testimonial-cli schema list-testimonials{
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": [
"text",
"video"
]
},
"liked": {
"type": "boolean",
"description": "Native Wall of Love filter."
},
"highlighted": {
"type": "boolean",
"description": "Native highlighted filter."
},
"tag": {
"type": "array",
"maxItems": 100,
"items": {
"type": "string",
"minLength": 1,
"description": ""
},
"description": "Repeated native tag display names; native OR match."
},
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 10000,
"description": "Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination."
},
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
}
},
"required": [],
"additionalProperties": false
}Native request: GET /testimonials. No native JSON body.
{
"name": "list_testimonials",
"method": "GET",
"path": "/testimonials",
"title": "List ready Space testimonials",
"description": "Read one native JSON array. Only ready video assets are included; no page, cursor or offset parameters.",
"group": "testimonials",
"risk": "read",
"params": [
{
"name": "type",
"key": "type",
"schema": {
"type": "string",
"enum": [
"text",
"video"
]
},
"in": "query",
"required": false,
"style": "form",
"explode": true
},
{
"name": "liked",
"key": "liked",
"schema": {
"type": "boolean",
"description": "Native Wall of Love filter."
},
"in": "query",
"required": false,
"style": "form",
"explode": true
},
{
"name": "highlighted",
"key": "highlighted",
"schema": {
"type": "boolean",
"description": "Native highlighted filter."
},
"in": "query",
"required": false,
"style": "form",
"explode": true
},
{
"name": "tag",
"key": "tag",
"schema": {
"type": "array",
"maxItems": 100,
"items": {
"type": "string",
"minLength": 1,
"description": ""
},
"description": "Repeated native tag display names; native OR match."
},
"in": "query",
"required": false,
"style": "form",
"explode": true
},
{
"name": "limit",
"key": "limit",
"schema": {
"type": "integer",
"minimum": 1,
"maximum": 10000,
"description": "Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination."
},
"in": "query",
"required": false,
"style": "form",
"explode": true
}
],
"bodySchema": null,
"bodyRequired": false,
"privateOutput": false,
"source": "https://help.testimonial.to/en/articles/6223143-api-get-all-testimonials"
}Explicit native key verification. Response includes Space id and account email; private metadata, not ownership or all-action proof.
Argument | Type | Required | Meaning and constraints |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
testimonial-cli verify-space --help
testimonial-cli schema verify-space{
"type": "object",
"properties": {
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
}
},
"required": [],
"additionalProperties": false
}Native request: GET /verify. No native JSON body.
{
"name": "verify_space",
"method": "GET",
"path": "/verify",
"title": "Verify the selected Space key",
"description": "Explicit native key verification. Response includes Space id and account email; private metadata, not ownership or all-action proof.",
"group": "space",
"risk": "read",
"params": [],
"bodySchema": null,
"bodyRequired": false,
"privateOutput": false,
"source": "https://help.testimonial.to/en/articles/6223143-api-get-all-testimonials"
}Import a real authorized customer statement. Local confirm approves the API call; customer_consent or payload.confirm represents actual public-use permission.
Argument | Type | Required | Meaning and constraints |
| string | Optional | Actual submitter name. |
| string | Optional | {"format": "email"} |
| string | Optional | Native combined title/company. |
| string | Optional | Native social profile value. |
| boolean | Optional | Native customer permission for public use, false by default. Independent from local command approval. |
| boolean | Optional | Add to Wall of Love, false by default; local public-use consent is required if true. |
| string | Optional | Actual authorized statement. |
| integer | Optional | Exact schema value. {"minimum": 1, "maximum": 5} |
| string | Optional | {"format": "uri"} |
| string | Optional | {"format": "uri"} |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
| boolean | Optional | Must be true for the requested mutation or exclusive private output file. |
| object | Optional | Complete native testimonial JSON object; do not mix with body flags or payload_file. |
| string | Required | Actual submitter name. |
| string | Optional | {"format": "email"} |
| string | Optional | Native combined title/company. |
| string | Optional | Native social profile value. |
| boolean | Optional | Native customer permission for public use, false by default. Independent from local command approval. |
| boolean | Optional | Add to Wall of Love, false by default; local public-use consent is required if true. |
| string | Required | Actual authorized statement. |
| integer | Optional | Exact schema value. {"minimum": 1, "maximum": 5} |
| string | Optional | {"format": "uri"} |
| string | Optional | {"format": "uri"} |
| string | Optional | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
testimonial-cli submit-text-testimonial --help
testimonial-cli schema submit-text-testimonial{
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"customer_consent": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"testimonial": {
"type": "string",
"minLength": 1,
"description": "Actual authorized statement."
},
"rating": {
"type": "integer",
"minimum": 1,
"maximum": 5
},
"avatarURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
},
"attachedImageURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
},
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
},
"confirm": {
"type": "boolean",
"description": "Must be true for the requested mutation or exclusive private output file."
},
"payload": {
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"confirm": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"testimonial": {
"type": "string",
"minLength": 1,
"description": "Actual authorized statement."
},
"rating": {
"type": "integer",
"minimum": 1,
"maximum": 5
},
"avatarURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
},
"attachedImageURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
}
},
"required": [
"testimonial",
"name"
],
"additionalProperties": false,
"description": "Complete native testimonial JSON object; do not mix with body flags or payload_file."
},
"payload_file": {
"type": "string",
"minLength": 1,
"description": "Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags."
}
},
"required": [],
"additionalProperties": false
}Native request: POST /submit/text. Native body requires testimonial, name. Top-level confirm is local approval; body/payload.confirm is native consent.
{
"name": "submit_text_testimonial",
"method": "POST",
"path": "/submit/text",
"title": "Submit an authorized text testimonial",
"description": "Import a real authorized customer statement. Local confirm approves the API call; customer_consent or payload.confirm represents actual public-use permission.",
"group": "testimonials",
"risk": "destructive",
"params": [],
"bodySchema": {
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"confirm": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"testimonial": {
"type": "string",
"minLength": 1,
"description": "Actual authorized statement."
},
"rating": {
"type": "integer",
"minimum": 1,
"maximum": 5
},
"avatarURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
},
"attachedImageURL": {
"type": "string",
"minLength": 1,
"description": "",
"format": "uri"
}
},
"required": [
"testimonial",
"name"
],
"additionalProperties": false
},
"bodyRequired": true,
"privateOutput": false,
"source": "https://help.testimonial.to/en/articles/6451677-api-submit-a-text-testimonial"
}Import a real publicly accessible authorized video. Provider retrieves/processes the URL; this package never downloads it. Success does not mean processing finished.
Argument | Type | Required | Meaning and constraints |
| string | Optional | Actual submitter name. |
| string | Optional | {"format": "email"} |
| string | Optional | Native combined title/company. |
| string | Optional | Native social profile value. |
| boolean | Optional | Native customer permission for public use, false by default. Independent from local command approval. |
| boolean | Optional | Add to Wall of Love, false by default; local public-use consent is required if true. |
| string | Optional | Existing public HTTPS video URL without credentials. {"format": "uri"} |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
| boolean | Optional | Must be true for the requested mutation or exclusive private output file. |
| object | Optional | Complete native testimonial JSON object; do not mix with body flags or payload_file. |
| string | Required | Actual submitter name. |
| string | Optional | {"format": "email"} |
| string | Optional | Native combined title/company. |
| string | Optional | Native social profile value. |
| boolean | Optional | Native customer permission for public use, false by default. Independent from local command approval. |
| boolean | Optional | Add to Wall of Love, false by default; local public-use consent is required if true. |
| string | Required | Existing public HTTPS video URL without credentials. {"format": "uri"} |
| string | Optional | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. |
testimonial-cli submit-video-testimonial --help
testimonial-cli schema submit-video-testimonial{
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"customer_consent": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"videoURL": {
"type": "string",
"minLength": 1,
"description": "Existing public HTTPS video URL without credentials.",
"format": "uri"
},
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
},
"confirm": {
"type": "boolean",
"description": "Must be true for the requested mutation or exclusive private output file."
},
"payload": {
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"confirm": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"videoURL": {
"type": "string",
"minLength": 1,
"description": "Existing public HTTPS video URL without credentials.",
"format": "uri"
}
},
"required": [
"videoURL",
"name"
],
"additionalProperties": false,
"description": "Complete native testimonial JSON object; do not mix with body flags or payload_file."
},
"payload_file": {
"type": "string",
"minLength": 1,
"description": "Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags."
}
},
"required": [],
"additionalProperties": false
}Native request: POST /submit/video. Native body requires videoURL, name. Top-level confirm is local approval; body/payload.confirm is native consent.
{
"name": "submit_video_testimonial",
"method": "POST",
"path": "/submit/video",
"title": "Submit an authorized video testimonial",
"description": "Import a real publicly accessible authorized video. Provider retrieves/processes the URL; this package never downloads it. Success does not mean processing finished.",
"group": "testimonials",
"risk": "destructive",
"params": [],
"bodySchema": {
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual submitter name."
},
"email": {
"type": "string",
"minLength": 1,
"description": "",
"format": "email"
},
"title": {
"type": "string",
"minLength": 1,
"description": "Native combined title/company."
},
"socialLink": {
"type": "string",
"minLength": 1,
"description": "Native social profile value."
},
"confirm": {
"type": "boolean",
"description": "Native customer permission for public use, false by default. Independent from local command approval."
},
"isLiked": {
"type": "boolean",
"description": "Add to Wall of Love, false by default; local public-use consent is required if true."
},
"videoURL": {
"type": "string",
"minLength": 1,
"description": "Existing public HTTPS video URL without credentials.",
"format": "uri"
}
},
"required": [
"videoURL",
"name"
],
"additionalProperties": false
},
"bodyRequired": true,
"privateOutput": false,
"source": "https://help.testimonial.to/en/articles/6236786-api-submit-a-video-testimonial"
}Side-effecting GET sends a real request email. Explicit local confirmation is mandatory. No dry run, retry or delivery guarantee.
Argument | Type | Required | Meaning and constraints |
| string | Required | Actual approved email context. |
| string | Required | Actual approved email context. {"format": "email"} |
| string | Required | Actual approved email context. |
| string | Required | Actual approved email context. |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
| boolean | Optional | Must be true for the requested mutation or exclusive private output file. |
testimonial-cli send-testimonial-request --help
testimonial-cli schema send-testimonial-request{
"type": "object",
"properties": {
"name": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"email": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context.",
"format": "email"
},
"spaceName": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"adminName": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
},
"confirm": {
"type": "boolean",
"description": "Must be true for the requested mutation or exclusive private output file."
}
},
"required": [
"name",
"email",
"spaceName",
"adminName"
],
"additionalProperties": false
}Native request: GET /new/request. No native JSON body. Side-effecting GET email still needs approval.
{
"name": "send_testimonial_request",
"method": "GET",
"path": "/new/request",
"title": "Send a requested testimonial email",
"description": "Side-effecting GET sends a real request email. Explicit local confirmation is mandatory. No dry run, retry or delivery guarantee.",
"group": "testimonials",
"risk": "destructive",
"params": [
{
"name": "name",
"key": "name",
"schema": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"in": "query",
"required": true,
"style": "form",
"explode": true
},
{
"name": "email",
"key": "email",
"schema": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context.",
"format": "email"
},
"in": "query",
"required": true,
"style": "form",
"explode": true
},
{
"name": "spaceName",
"key": "spaceName",
"schema": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"in": "query",
"required": true,
"style": "form",
"explode": true
},
{
"name": "adminName",
"key": "adminName",
"schema": {
"type": "string",
"minLength": 1,
"description": "Actual approved email context."
},
"in": "query",
"required": true,
"style": "form",
"explode": true
}
],
"bodySchema": null,
"bodyRequired": false,
"privateOutput": false,
"source": "https://help.testimonial.to/en/articles/6223146-api-send-request"
}Local profile labels/default/auth method only. No keys, token paths, provider identity or network request.
Argument | Type | Required | Meaning and constraints |
testimonial-cli list-accounts --help
testimonial-cli schema list-accounts{
"type": "object",
"properties": {},
"required": [],
"additionalProperties": false
}Local reviewed method/path/query/body schema and provenance for one native tool. No credentials or provider request.
Argument | Type | Required | Meaning and constraints |
| string | Required | Exact native tool name, e.g. submit_text_testimonial or send_testimonial_request. {"enum": ["list_testimonials", "verify_space", "submit_text_testimonial", "submit_video_testimonial", "send_testimonial_request"]} |
testimonial-cli get-operation-schema --help
testimonial-cli schema get-operation-schema{
"type": "object",
"properties": {
"operation": {
"type": "string",
"enum": [
"list_testimonials",
"verify_space",
"submit_text_testimonial",
"submit_video_testimonial",
"send_testimonial_request"
],
"description": "Exact native tool name, e.g. submit_text_testimonial or send_testimonial_request."
}
},
"required": [
"operation"
],
"additionalProperties": false
}Local validation and SHA-256 of exact ordered text/video import/email work, selected profile label and reviewed schema. No provider reads, key load, identity check, price or rollback guarantee.
Argument | Type | Required | Meaning and constraints |
| array | Required | One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval. {"minItems": 1, "maxItems": 20} |
| string | Required | Exact schema value. {"enum": ["submit_text_testimonial", "submit_video_testimonial", "send_testimonial_request"]} |
| object | Required | Actual native tool arguments without account, confirm, payload_file or output_file. |
| string | Optional | Exact selected private account profile; binds label, not key ownership. |
testimonial-cli preview-testimonial-batch --help
testimonial-cli schema preview-testimonial-batch{
"type": "object",
"properties": {
"tasks": {
"type": "array",
"minItems": 1,
"maxItems": 20,
"description": "One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval.",
"items": {
"type": "object",
"properties": {
"tool": {
"type": "string",
"enum": [
"submit_text_testimonial",
"submit_video_testimonial",
"send_testimonial_request"
]
},
"arguments": {
"type": "object",
"description": "Actual native tool arguments without account, confirm, payload_file or output_file."
}
},
"required": [
"tool",
"arguments"
],
"additionalProperties": false
}
},
"account": {
"type": "string",
"description": "Exact selected private account profile; binds label, not key ownership."
}
},
"required": [
"tasks"
],
"additionalProperties": false
}Confirmed one-to-twenty ordered text/video import/email tasks. Prevalidate all and verify exact hash before first request. Stop on first failure with known results/failed index/unattempted indices; no retries, rollback or implicit continuation.
Argument | Type | Required | Meaning and constraints |
| array | Required | One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval. {"minItems": 1, "maxItems": 20} |
| string | Required | Exact schema value. {"enum": ["submit_text_testimonial", "submit_video_testimonial", "send_testimonial_request"]} |
| object | Required | Actual native tool arguments without account, confirm, payload_file or output_file. |
| string | Optional | Exact selected private account profile; binds label, not key ownership. |
| boolean | Optional | Explicit approval for this exact requested ordered batch. |
| string | Required | Exact preview_testimonial_batch hash for identical requests, profile label, schema and order. {"pattern": "^[a-f0-9]{64}$"} |
testimonial-cli submit-testimonial-batch --help
testimonial-cli schema submit-testimonial-batch{
"type": "object",
"properties": {
"tasks": {
"type": "array",
"minItems": 1,
"maxItems": 20,
"description": "One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval.",
"items": {
"type": "object",
"properties": {
"tool": {
"type": "string",
"enum": [
"submit_text_testimonial",
"submit_video_testimonial",
"send_testimonial_request"
]
},
"arguments": {
"type": "object",
"description": "Actual native tool arguments without account, confirm, payload_file or output_file."
}
},
"required": [
"tool",
"arguments"
],
"additionalProperties": false
}
},
"account": {
"type": "string",
"description": "Exact selected private account profile; binds label, not key ownership."
},
"confirm": {
"type": "boolean",
"description": "Explicit approval for this exact requested ordered batch."
},
"review_sha256": {
"type": "string",
"pattern": "^[a-f0-9]{64}$",
"description": "Exact preview_testimonial_batch hash for identical requests, profile label, schema and order."
}
},
"required": [
"tasks",
"review_sha256"
],
"additionalProperties": false
}Confirmed single native GET saved to a new exclusive mode 0600 JSON file, default limit 100/local maximum 10,000 and 5 MiB response/file cap. No pagination, continuation, media download, overwrite or atomic complete-backup claim.
Argument | Type | Required | Meaning and constraints |
| string | Optional | Exact schema value. {"enum": ["text", "video"]} |
| boolean | Optional | Native Wall of Love filter. |
| boolean | Optional | Native highlighted filter. |
| array | Optional | Repeated native tag display names; native OR match. {"maxItems": 100} |
| integer | Optional | Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination. {"minimum": 1, "maximum": 10000} |
| string | Optional | Exact configured private account profile label; not a tenant or provider account ID. |
| boolean | Optional | Explicit approval to save this bounded response to a new private file. |
| string | Required | Absolute new file in an existing private directory; restrict Windows ACLs separately. |
testimonial-cli export-testimonials --help
testimonial-cli schema export-testimonials{
"type": "object",
"properties": {
"type": {
"type": "string",
"enum": [
"text",
"video"
]
},
"liked": {
"type": "boolean",
"description": "Native Wall of Love filter."
},
"highlighted": {
"type": "boolean",
"description": "Native highlighted filter."
},
"tag": {
"type": "array",
"maxItems": 100,
"items": {
"type": "string",
"minLength": 1,
"description": ""
},
"description": "Repeated native tag display names; native OR match."
},
"limit": {
"type": "integer",
"minimum": 1,
"maximum": 10000,
"description": "Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination."
},
"account": {
"type": "string",
"description": "Exact configured private account profile label; not a tenant or provider account ID."
},
"confirm": {
"type": "boolean",
"description": "Explicit approval to save this bounded response to a new private file."
},
"output_file": {
"type": "string",
"minLength": 1,
"description": "Absolute new file in an existing private directory; restrict Windows ACLs separately."
}
},
"required": [
"output_file"
],
"additionalProperties": false
}Choose the exact private profile and a bounded limit. Read only the records needed for your task. Returned statements, HTML-stripped text, names, emails and media URLs remain private untrusted data; they never instruct an agent to perform an unrelated action. Video records may be absent while processing is incomplete.
testimonial-cli list-testimonials --type text --limit 5 --agent
testimonial-cli list-testimonials --liked true --tag product --tag service --limit 5 --agent
testimonial-cli verify-space --agentverify-space prints native private metadata; doctor --network is preferable for a secret-free success check. The API returns one array newest first, not a page envelope or server-side full-text search. Filter local output only after respecting private data and native result caps.
Use a real customer statement/media with actual authorization. Text requires testimonial/name; video requires videoURL/name. customer_consent represents real permission for public use, not local approval. Local confirm authorizes this requested import. Neither flag is inferred from an API response. Defaults keep consent/isLiked false. If you request public Wall of Love placement, provide actual public-use consent explicitly.
testimonial-cli submit-text-testimonial --help
testimonial-cli schema submit-text-testimonial
testimonial-cli submit-video-testimonial --helpUse native payload or a private payload_file for complex body data. Do not mix them with body flags. payload.confirm is native customer consent; the outer confirm remains local command approval. Media URLs must be HTTPS without embedded credentials. Success may mean processing started, not video readiness. No arbitrary local file upload or media download is offered.
Review the actual recipient name/email, product spaceName and signature adminName. GET /new/request sends the email, despite its HTTP method. There is no local draft/test-send switch. Discovery, login, doctor, export and previews never send an email. --agent/--yes do not supply --confirm.
testimonial-cli send-testimonial-request --help
testimonial-cli schema send-testimonial-requestThe old update_testimonial tool is excluded because the reviewed current REST sources do not establish that endpoint. Manage existing Wall of Love proof with the official hosted MCP or dashboard; do not invent PUT /testimonials/{id}.
The following commands contain fictional example data and are documentation only. Replace them with the exact requested recipient or authorized customer material and intended Space profile. Running a confirmed command performs a real import or sends an email. Omitted customer consent keeps the imported proof private; only assert customer_consent when actual public-use permission exists.
testimonial-cli submit-text-testimonial --name "Example customer" --testimonial "An authorized customer statement" --confirm --agent
testimonial-cli submit-video-testimonial --name "Example customer" --videoURL "https://example.com/authorized-video.mp4" --confirm --agentEmail request example (four native required fields):
testimonial-cli send-testimonial-request --name "Example customer" --email "customer@example.com" --spaceName "Example product" --adminName "Example sender" --confirm --agentA local preview makes no provider request. Record its reviewSha256, inspect the exact work, then use the same task JSON/profile with submit-testimonial-batch --review-sha256 "SHA256_FROM_YOUR_PREVIEW" --confirm only when that work is requested:
testimonial-cli preview-testimonial-batch --tasks '{"tool":"submit_text_testimonial","arguments":{"name":"Example customer","testimonial":"An authorized customer statement"}}' --agentpreview_testimonial_batch locally validates 1–20 ordered native mutations and produces a reviewSha256. Each task has tool/arguments; nested arguments cannot override account, local confirm, payload_file or output_file. Native payload.confirm and customer_consent remain consent fields. No network call or private key load occurs during preview.
submit_testimonial_batch requires outer confirm and the matching review_sha256 with identical requests/order/profile label/schema. Every task is prepared before the first network call. Changing any consent, recipient, statement, account label, order or native schema invalidates the hash. Review hashes do not bind a credential fingerprint, prove Space ownership, lock native state, establish customer consent, expire or become single-use provider approvals.
On first failure execution stops with knownResults, failedIndex and unattemptedIndices. HTTP 200 status failed is an error, not a successful imported record. Failed effects may have unknown outcomes; no retry, rollback or automatic continuation occurs. Do not promise emailed delivery or processed video based on native request acceptance.
testimonial-cli preview-testimonial-batch --help
testimonial-cli schema preview-testimonial-batch
testimonial-cli submit-testimonial-batch --helpexport_testimonials performs one GET /testimonials with default limit 100, local maximum 10,000 and 5 MiB response/file cap. It saves {testimonials,receipt} to an absolute new exclusive mode 0600 file in an existing private directory. Existing files/symlinks are never overwritten. On failure only its newly created partial file is removed. Windows ACLs must be restricted separately.
The receipt includes requests/items/requestedLimit/atNativeLimit/completeBackup:false/paginationSupported:false/atomicSnapshot:false plus the local byte count/hash. At the native limit, additional matching records may exist. Even fewer records do not prove a complete archive because processing, changing state and native filters affect visibility. No cursor/page/offset, continuation, media retrieval, native backup, CSV conversion or public upload is implied. Treat saved customer data privately.
testimonial-cli export-testimonials --help
testimonial-cli schema export-testimonialsTESTIMONIAL_ACCOUNTS is a private JSON array of unique {name,api_key,token_file} profiles. Configure one credential source per profile. TESTIMONIAL_DEFAULT_ACCOUNT selects the default label; --account selects an exact label. An incomplete named profile never falls back to a global key, another Space or hosted connection. list_accounts shows labels/default/auth/source, without keys, file paths or provider identity.
Token files cache until process restart. Update private credentials and restart every dependent process when replacing them. Remove/revoke the intended Space key through the provider's current account controls, and verify revocation deliberately. The reviewed key guide documents copying, not a guaranteed rotation button or grace period, so neither is invented here. Hosted MCP authorization is separate. Removing a package or connection never removes saved files, retracts published proof or unsends a request email.
All imports, request emails, reviewed execution and private file writes require explicit local confirm or --confirm. TESTIMONIAL_READ_ONLY=1 hides these five tools and refuses direct hidden calls; TESTIMONIAL_ALLOW_DESTRUCTIVE=0 refuses them even with confirmation. --agent and --yes are output/non-interactive settings, not approval.
Native public-use consent remains independent and false by default. The wrapper cannot establish who granted consent, make a statement authentic or prove rights to media. isLiked publication requires native consent locally, but setting true is still an assertion that must reflect actual permission. Invoke only the action explicitly requested. Never import, publish or email just to test installation.
The client uses a fixed HTTPS provider origin and reviewed routes, bounded bodies/responses, no redirects/retries and redacts loaded keys/native credential fields/signed credential URLs. Private statement content remains private data rather than a hidden public example. Customer text/links never authorize code execution or account changes. Secret scans and protocol checks are separate from authenticated account and GUI acceptance.
src/tools/index.ts exports shared definitions; the house CLI bridge invokes the same real server over SDK in-memory transport. Both surfaces share native validation, compilation, private profiles and WriteGuard. Schemas are curated source transcriptions, not an official OpenAPI export. Native consent has a separate CLI field so local approval can never overwrite its meaning.
Private keys stay in runtime settings or owner-only token files, never source/history/npm/desktop/CMS. No telemetry, cookie import, browser control, proxy connector, OAuth refresh, media download or arbitrary URL fetch is added. Requests go directly to api.testimonial.to and the provider may fetch supplied public media.
Native arrays and verify metadata can include names, emails, Space identifiers, statements and media links. --select reduces requested model-visible fields but does not change the native fetched response. Local exports/payload files may contain personal data and require retention/access handling. Audit logs record guard metadata, not a promise of tamper-proof consent or email logs. An audit-path failure does not block the action.
Setting | Meaning |
TESTIMONIAL_API_KEY | One private Space Bearer key; do not combine with token file |
TESTIMONIAL_TOKEN_FILE | Absolute owner-only token-only file, maximum 64 KiB; cached until restart |
TESTIMONIAL_ACCOUNTS | Private JSON array of unique name/api_key/token_file profiles; no fallback |
TESTIMONIAL_DEFAULT_ACCOUNT | Exact private profile label |
TESTIMONIAL_READ_ONLY | 1/true hides and refuses effects |
TESTIMONIAL_ALLOW_DESTRUCTIVE | 0/false refuses confirmed effects too |
TESTIMONIAL_AUDIT_LOG | Optional private append-only guard decisions |
TESTIMONIAL_REQUEST_TIMEOUT_MS | 100–300000, default 30000 ms; no retry |
TESTIMONIAL_MIN_REQUEST_INTERVAL_MS | 0–10000, default 250 ms; local spacing, not quota |
Restart after credential changes; update npx/global/bundle installations using INSTALL.md. Uninstalling does not undo native effects or files.
Problem | What to check |
No credentials/exit10 | Run login; configure exactly one intended Space source in this runtime |
401/403 | Actual Space key and current plan/permission; never fall back across profiles |
No video returned | Native list only includes ready assets; check processing in the dashboard |
page/spaceId rejected | Current Space-scoped list is a single array without pagination |
Native status failed | Treat as operation error even with HTTP 200; no automatic repeat |
Email refused | Actual four query fields and explicit local approval; GET is a write |
Consent/publication refused | Local approval does not establish customer public-use permission |
Batch hash mismatch | Review exact unchanged inputs/order/profile/schema again |
Output exists or is too large | Choose a new private path and smaller native limit; no overwrite/resume |
GUI cannot find Node/private file | Check actual runtime/absolute path/ACLs, then reconnect |
429/timeout | Respect native limits and inspect possible outcomes before deliberate repeat |
Testimonial's official MCP at https://mcp.testimonial.to already browses/searches testimonials, manages Wall of Love, mentions and keywords, analyzes trends and NPS, creates/browses case studies, checks usage and configures standing routes. Routes keep running after a chat and already default to confirmation before publishing. Browser sign-in is the default; Notion uses a header token, and Advanced tokens are a fallback for clients without browser authorization.
Use the official connector for that wider native experience. REST Space keys and hosted access tokens are different integration paths. Current provider material specifies REST Ultimate/Ultimate+ per Space; reviewed hosted help snapshots differ in explicit plan wording, so verify eligibility in AI & Agents and Settings > Plan instead of treating the absence of an upgrade label as unrestricted access. This package neither creates standing routes nor exposes undocumented analytics/NPS/keyword endpoints.
A dedicated provider task CLI was not identified in the reviewed sources on October 3, 2026. That does not mean the official MCP cannot be used from a terminal. wong2/mcp-cli, pinned at 7d12b4648b1c3e2a7341113407002c1b0f700d1b, supports remote Streamable HTTP/SSE, OAuth and non-interactive tool calls. The official MCP Inspector also supports CLI calls. They can call the broad official connector using its native authorization and approved tools.
Searches for Testimonial-specific public MCP/task-CLI repositories did not identify an independent source suitable to pin; this is a search finding, not evidence none exist. The private old five-tool repo is separately reviewed, not misrepresented as an independent community implementation.
This owned implementation supplies a focused shared task CLI/local MCP, isolated Space credentials, separate local approval/customer consent, direct read-only refusal even for a side-effecting GET, exact locally reviewed imports/emails and a bounded exclusive private export. These behaviors are exercised through the actual handlers and CLI; provider outcomes, actual desktop GUI and matched Codex costs remain separate evidence.
No universal superiority, more-total-provider-coverage or measured token saving is claimed. The official MCP remains broader. This REST companion cannot update existing Wall of Love items, manage mentions/keywords, create case studies or run standing automation through undocumented endpoints.
Capability | This package | Existing alternatives |
Task interface | 10 shared CLI/local MCP tasks | Official hosted MCP plus generic terminal clients |
Native scope | 5 reviewed REST operations | Hosted tools cover additional product areas |
Consent | Local confirm separated from actual customer public-use permission | Official provider/client controls remain native |
Profiles | Private named Space keys with no fallback | Hosted browser authorization or native token connection |
Reviewed work | Exact ordered imports/emails, prevalidation and stop on failure | No provider-state lock or replacement for customer permission |
Exports | One bounded array to a new private file | No pagination, atomic backup or media download |
Token costs | Actual matched Codex task measurement pending | No blanket MCP-versus-CLI percentage |
Legacy tool | Current 2.0.1 contract |
list_testimonials | Same name, selected Space key, native single-array filters; no spaceId/page/per_page |
submit_text_testimonial | Same name, POST/submit/text with testimonial/name and separate consent |
submit_video_testimonial | Same name, POST/submit/video with videoURL/name and separate consent |
update_testimonial | Excluded: current reviewed REST contract not established; use hosted MCP/dashboard |
send_testimonial_request | Same name, confirmed GET/new/request with four required fields |
Private five-tool 1.0.0 history stays intact and out of public refs. Version 2.0.1 is a major native argument/route correction, not a claim every legacy capability remains valid. AGPL-3.0 is preserved.
Component | Reviewed version |
Package/desktop | 2.0.1 |
Native REST | v1, five operations checked 2026-10-03 |
Generic MCP CLI | 7d12b4648b1c3e2a7341113407002c1b0f700d1b |
Node | >=22 |
Behavior/bridge checks | 54 passing tests |
Actual Codex task/token use | Pending |
CHANGELOG.md records dated changes. Version 2.0.0 introduced the current REST companion; 2.0.1 corrects export approval and payload help. Native routes, approval behavior and ten-tool coverage are unchanged.
Yes. Its hosted connector already covers broader testimonials, Wall of Love, mentions/keywords, analytics, NPS, case studies and standing routes. Browser authorization is the default, with native token fallbacks. This package is a focused REST task companion, not a replacement for all official tools.
The useful addition is a shared task CLI/local MCP with isolated Space keys, separate local approval/customer consent, explicit read-only refusal, exact reviewed ordered imports/emails and private bounded JSON exports. Generic MCP CLIs already call the hosted connector; no universal absence or superiority is claimed.
Current REST docs specify Ultimate/Ultimate+ per Space. Copy the intended Space key from its dashboard card menu. Hosted MCP plan wording varies in reviewed snapshots; verify current eligibility in the account. This wrapper grants no bypass and does not use a browser session as a Space key.
Use one private TESTIMONIAL_API_KEY or absolute owner-only TESTIMONIAL_TOKEN_FILE outside repositories, at most 64 KiB. Windows ACLs need separate restriction. Never publish resolved values, token URLs, keys or customer data in source, bundles, CMS or screenshots.
Yes, with private named TESTIMONIAL_ACCOUNTS profiles. A unique label selects one Space key/file, with no global or cross-Space fallback. A label is not native ownership proof. list_accounts does not make network calls or expose token paths.
login only prints setup instructions; doctor checks local settings. Explicit doctor --network requests GET /verify and prints success metadata without native email/id. It does not create keys, sign in, import cookies, verify every endpoint or send email.
GET testimonials, GET verify, POST submit/text, POST submit/video and side-effecting GET new/request. The five helpers are list_accounts, get_operation_schema, preview_testimonial_batch, submit_testimonial_batch and export_testimonials.
No reviewed REST contract for the legacy update endpoint was established. Use the official MCP/dashboard for existing Wall of Love, mentions, keywords, analytics, case studies and routes. No undocumented route or fake supported tool is exposed.
Outer confirm or --confirm is local approval for this requested operation. customer_consent or native payload.confirm represents actual customer permission for public use, default false. They never imply each other. Do not manufacture consent to satisfy a command.
Native isLiked adds imported proof to the Wall of Love, default false. This package refuses isLiked true without explicit actual public-use consent. It cannot establish authenticity, rights or who granted permission; native published placement remains an effect.
GET /new/request sends a real email using name, email, spaceName and adminName. It requires explicit local approval, is hidden/refused in read-only and is not called during discovery, setup, previews or export. There is no automatic test email or delivery guarantee.
No. The provider retrieves the public HTTPS video and can process it after acceptance. Native list only returns ready video assets. The package never downloads the video or treats success as completion or consent proof.
The current endpoint returns one newest-first array for the selected Space key. type, liked, highlighted, repeated tag display names and limit are native filters; tags use OR matching. page, offset, cursor and spaceId are refused. No native full-text search is invented.
No. One bounded native response is saved to a new private JSON file, default limit 100, local maximum 10,000 and 5 MiB cap. Receipt completeBackup and atomicSnapshot remain false. Filtering, processing and changing native state limit visibility; there is no pagination, resume or media download.
No. Exclusive creation refuses existing paths/symlinks before any request. Failure removes only the new partial file. POSIX files use 0600; restrict Windows ACLs separately. Returned metadata never echoes the private customer array.
Every 1–20 exact ordered operation is validated before the first request; hash binds requests/order/profile label/schema. It is not a key fingerprint, provider-state lock, customer permission record, expiry or single-use approval token. Preview makes no network call or key load.
Stop immediately with knownResults, failedIndex and unattemptedIndices; HTTP 200 status failed is an error. Unknown native outcomes may remain. No retry, rollback or automatic continuation occurs; inspect native state before deliberately repeating.
No. READ_ONLY hides and directly refuses all five effect/file tools. ALLOW_DESTRUCTIVE=0 refuses confirmed effects too. Agent/yes formatting never supplies local confirm or customer consent.
Node 22+ local stdio clients and the CLI work on macOS, Windows and Linux; INSTALL documents Codex first, Claude Code/Desktop, Cursor, VS Code/Copilot, Windsurf, Zed, Gemini CLI, Docker and other stdio clients. Browser-only clients need a supported remote connector, such as the official MCP. Protocol/CI evidence is not actual GUI installation.
Restart npx@latest registrations, update global CLI installs explicitly and install newer desktop bundles manually. Actual equivalent Codex task/token measurement remains pending. Loading modes, schemas/help, output, skills and caching affect cost; no borrowed percentage, character estimate or universal superiority is claimed.
Open a secret-free issue. Read CONTRIBUTING.md and SECURITY.md.
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.
Dependency | Exact lock version | Role |
| 1.32.0 | Runtime |
| 8.20.0 | Runtime |
| 3.0.1 | Runtime |
| 2.1.2 | Development/packaging |
| 22.20.5 | Development/packaging |
| 7.0.2 | Development/packaging |
| 8.3.2 | Development/packaging |
| 5.0.3 | Development/packaging |
These versions are from this release’s package-lock.json. Runtime dependencies ship in npm and the desktop bundle; packaging tools do not enter the desktop runtime.
Preserves AGPL-3.0 and existing private legacy history. Read THIRD_PARTY_NOTICES.md. Testimonial.to service terms and trademarks remain separate.
© 2026 Navid Media. Made with ❤️ by Navid Moazzez.
Confirmed single native GET saved to a new exclusive mode 0600 JSON file, default limit 100/local maximum 10,000 and 5 MiB response/file cap. No pagination, continuation, media download, overwrite or atomic complete-backup claim.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Repeated native tag display names; native OR match. | |
| type | No | ||
| liked | No | Native Wall of Love filter. | |
| limit | No | Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Explicit approval to save this bounded response to a new private file. | |
| highlighted | No | Native highlighted filter. | |
| output_file | Yes | Absolute new file in an existing private directory; restrict Windows ACLs separately. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations only declare the safety profile (readOnlyHint=false, destructiveHint=true, idempotentHint=false, openWorldHint=true); the description adds substantial context beyond them — mode 0600, exclusive creation with no overwrite, a 5 MiB file/response cap, no atomicity guarantee, and no pagination or media download. It does not cover auth/account prerequisites or failure behavior when the target file already exists, so it is not exhaustive.
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 operation plus its hard caps are front-loaded. The telegraphic style ('confirmed single native GET saved to a new exclusive mode 0600 JSON file') packs a lot into few words but is legible.
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 write with no output schema and 8 parameters, the description covers the essential operational facts: file permissions, exclusivity, size cap, and absent pagination. What remains thin is the confirmation/account requirement and the exact failure mode when the output path exists.
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 (88%), which alone justifies a baseline 3, but the description contributes values the schema lacks: the default limit of 100 and the fact that 10,000 is a local rather than provider-imposed maximum. It does not clarify the meaning of confirm, account, or output_file beyond what the schema already documents.
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 action (a confirmed native GET persisted to a new exclusively-created 0600 JSON file) and the resource (a bounded testimonial array per the title), so an agent knows this exports data to disk rather than listing or previewing it. It stops short of naming the sibling it displaces — list_testimonials and preview_testimonial_batch are never mentioned, so differentiation is left to inference.
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 exclusions ('no pagination, continuation, media download, overwrite or atomic complete-backup claim') describe limits rather than when-to-use guidance, and no sibling tool is named as an alternative. An agent must guess whether to call this instead of list_testimonials or preview_testimonial_batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local reviewed method/path/query/body schema and provenance for one native tool. No credentials or provider request.
| Name | Required | Description | Default |
|---|---|---|---|
| operation | Yes | Exact native tool name, e.g. submit_text_testimonial or send_testimonial_request. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, non-destructive and openWorldHint=false, so the safety profile is fully covered by structured data. 'Local' and 'No credentials or provider request' largely restate openWorldHint=false; only the credential point adds genuinely new context. Nothing is said about the shape or volume of what comes back.
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 compact sentences with no filler, and the core purpose is front-loaded. Every clause carries 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?
For a single-parameter, read-only inspection tool with a fully documented enum and no output schema, the description tells the agent what is returned (schema and provenance) and that no network/credentials are involved. Adequate, though it could say more about why an agent would inspect before invoking.
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' parameter has a closed enum with examples ('submit_text_testimonial', 'send_testimonial_request'), so the schema already carries the semantics. The description adds nothing about the parameter 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 resource (method/path/query/body schema plus provenance) for one native operation, with an implied inspect/read verb. It implicitly distinguishes itself from the sibling operations, which perform actions rather than expose their schemas, though it never names that contrast outright.
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 'for one native tool' plus 'No credentials or provider request' implies this is a safe pre-flight inspection step before invoking an operation, but there is no explicit when-to-use or when-not-to-use statement and no named alternative. Usage must be inferred.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local profile labels/default/auth method only. No keys, token paths, provider identity or network request.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so safety is covered. The description adds genuine context beyond that: output is limited to local profile labels/defaults/auth method and deliberately excludes keys, token paths, and provider identity, telling the agent the result is safe to surface.
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 very short (two fragments) and wastes no words, but it is telegraphic and front-loads a qualifier rather than the core action. The terseness borders on under-specification rather than disciplined conciseness.
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 zero-parameter, read-only listing tool with no output schema and strong annotations, the description covers the essential safety and scope facts. However, it never plainly states what the tool does or what the returned list contains beyond field-level exclusions, leaving the purpose inferable only from the title.
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 there is no parameter semantics for the description to carry. Baseline of 4 applies; nothing is missing on this dimension.
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 never states a verb or resource — it only describes the scope of what is returned ("Local profile labels/default/auth method only"). The title supplies the actual purpose, so the agent can infer this lists local accounts, but the description itself is vague about the action.
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 and no named alternative among the numerous list_* siblings (list_customers, list_partners, list_domains, etc.). The agent must infer that this tool is for enumerating locally configured account profiles rather than any remote data.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Read one native JSON array. Only ready video assets are included; no page, cursor or offset parameters.
| Name | Required | Description | Default |
|---|---|---|---|
| tag | No | Repeated native tag display names; native OR match. | |
| type | No | ||
| liked | No | Native Wall of Love filter. | |
| limit | No | Native result cap; 10000 is a local maximum, not a documented provider quota. No pagination. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| highlighted | No | Native highlighted filter. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With readOnlyHint, idempotentHint and destructiveHint already declared, the description adds genuinely new context: it discloses there is no pagination ('no page, cursor or offset parameters') and that only 'ready' assets are returned, plus the native-array (non-enveloped) return shape. It stops short of defining 'ready' or describing rate/limit behavior, but this is solid added detail 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?
Two compact sentences with no filler, and the key constraint (only ready assets, no pagination) is front-loaded. The opening 'Read one native JSON array' is slightly cryptic but is the most load-bearing information given there is no output schema.
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 read tool with no output schema, the description tells the agent the return shape but not what a testimonial record actually contains, how the tag OR-match and boolean filters combine, or what 'ready' means. Combined with high schema coverage and annotations it is minimally viable, but gaps remain.
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 filters like tag, liked, highlighted, limit and account are already documented inline. The description only reinforces the absence of pagination parameters, which the schema's additionalProperties:false and the limit note already convey, so it adds little meaning 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 name and title ('List ready Space testimonials') carry the core purpose, but the description itself leads with 'Read one native JSON array', which describes the return envelope rather than the action, and adds only the scoping phrase 'Only ready video assets are included'. It never plainly states that it lists/filters testimonials, and the 'video assets' phrasing is confusing against a schema whose type enum includes 'text'.
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 and no routing relative to siblings such as export_testimonials or list_accounts. The description does not say when this list endpoint is preferable to the submission or export tools, leaving selection entirely to inference from the name.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Local validation and SHA-256 of exact ordered text/video import/email work, selected profile label and reviewed schema. No provider reads, key load, identity check, price or rollback guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval. | |
| account | No | Exact selected private account profile; binds label, not key ownership. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint=true, openWorldHint=false, idempotentHint=true, and destructiveHint=false. The description adds meaningful behavioral context beyond that: local-only validation, SHA-256 hashing, and explicitly absent behaviors including provider reads, key load, identity check, price, and rollback guarantee.
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 very compact and front-loads the core purpose ('Local validation and SHA-256'). The second sentence efficiently lists excluded behaviors, though the dense phrase 'exact ordered text/video import/email work, selected profile label and reviewed schema' takes some effort to parse.
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 preview-style batch validation tool with a nested ordered task schema and no output schema, the description covers side-effect boundaries well. It does not explain what the preview returns, what validation failures look like, or how the SHA-256 result should be interpreted, leaving an agent to infer the output from the tool name and schema alone.
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 loosely references 'exact ordered text/video import/email work' and 'selected profile label', but it does not add substantive semantics beyond the schema's own descriptions of tasks and account.
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 operation: local validation and SHA-256 of an exact ordered batch of testimonial import/email tasks for a selected profile and reviewed schema. It distinguishes itself from submission-style siblings by stating it performs no provider reads, key load, or identity checks, though it never uses the plain term 'preview' or 'dry run'.
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: this is a local validation step to run before actual provider-facing submission. The description provides negative guidance ('no provider reads, key load, identity check, price or rollback guarantee') but does not explicitly name the alternative sibling tool submit_testimonial_batch or state when to choose this preview over executing the batch.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Side-effecting GET sends a real request email. Explicit local confirmation is mandatory. No dry run, retry or delivery guarantee.
| Name | Required | Description | Default |
|---|---|---|---|
| name | Yes | Actual approved email context. | |
| Yes | Actual approved email context. | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Must be true for the requested mutation or exclusive private output file. | |
| adminName | Yes | Actual approved email context. | |
| spaceName | Yes | Actual approved email context. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, idempotentHint=false, and openWorldHint=true. The description adds meaningful context beyond those flags: 'No dry run, retry or delivery guarantee' tells the agent there is no rollback or safe re-attempt, and 'Side-effecting GET' warns that the HTTP method is misleading. It stops short of describing failure/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?
Three terse sentences with zero waste, front-loading the highest-risk fact (side-effecting send) first. Each sentence earns its place by adding a distinct behavioral 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 destructive, non-idempotent send with no output schema, the description covers the side effect, the mandatory confirmation gate, and the absence of dry run/retry/delivery guarantees. It is nearly complete; only error/failure handling 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 the schema already documents all six parameters including the confirm flag and the account vs. tenant distinction. The description adds no parameter-level syntax or constraints, so this sits at the baseline for fully covered schemas.
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: it sends a real request email (a testimonial request). It distinguishes the side-effecting nature from sibling submission tools like submit_text_testimonial and submit_video_testimonial, though it does not explicitly name any sibling to route between 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?
It states a clear prerequisite rather than a use case: 'Explicit local confirmation is mandatory,' which tells the agent what must happen before calling. However, it offers no guidance on when to choose this tool over the sibling submit_* or batch tools, leaving the selection decision implicit.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Confirmed one-to-twenty ordered text/video import/email tasks. Prevalidate all and verify exact hash before first request. Stop on first failure with known results/failed index/unattempted indices; no retries, rollback or implicit continuation.
| Name | Required | Description | Default |
|---|---|---|---|
| tasks | Yes | One to twenty exact ordered supported text/video import/email operations. Each task is one exact native import or one email request. Customer consent is separate from local approval. | |
| account | No | Exact selected private account profile; binds label, not key ownership. | |
| confirm | No | Explicit approval for this exact requested ordered batch. | |
| review_sha256 | Yes | Exact preview_testimonial_batch hash for identical requests, profile label, schema and order. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations cover safety (destructive, non-idempotent, open-world), but the description adds genuinely new behavioral detail beyond them: prevalidation of all tasks, exact-hash verification before the first request, and precise failure semantics (stop on first failure, no retries, rollback, or implicit continuation). This is high-value disclosure an agent could not get from the annotations alone.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two dense sentences with the confirmed-batch scope front-loaded and failure behavior trailing. Every clause carries information, though the telegraphic abbreviations ('known results/failed index/unattempted indices') are slightly compressed for readability.
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 batch tool with no output schema, the description covers failure return shape (known results, failed index, unattempted indices) and the hash-precondition workflow, complementing the annotations. Prerequisite tooling and success-return shape are the only mild 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 100%, so tasks, account, confirm, and review_sha256 are already documented in the schema. The description reinforces ordering and the 1-20 bound and references the hash, but adds little meaning beyond 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 names a specific verb+resource: executing a confirmed batch of 1-20 ordered text/video/email testimonial tasks. It distinguishes this from the preview step via 'Confirmed' and the hash check, though it does not explicitly name the sibling preview_testimonial_batch. An agent can identify the operation, but sibling differentiation is only implied.
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: 'Confirmed' plus 'verify exact hash before first request' hints at the preview-then-execute workflow, but no sibling is named and there is no explicit when-to-use vs when-not guidance. The reader must infer that preview_testimonial_batch is the prerequisite.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a real authorized customer statement. Local confirm approves the API call; customer_consent or payload.confirm represents actual public-use permission.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Actual submitter name. | |
| No | |||
| title | No | Native combined title/company. | |
| rating | No | ||
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Must be true for the requested mutation or exclusive private output file. | |
| isLiked | No | Add to Wall of Love, false by default; local public-use consent is required if true. | |
| payload | No | Complete native testimonial JSON object; do not mix with body flags or payload_file. | |
| avatarURL | No | ||
| socialLink | No | Native social profile value. | |
| testimonial | No | Actual authorized statement. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. | |
| attachedImageURL | No | ||
| customer_consent | No | Native customer permission for public use, false by default. Independent from local command approval. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare destructiveHint=true, readOnlyHint=false, and openWorldHint=true, so the mutation risk is covered structurally. The description adds non-obvious behavioral context the annotations cannot convey: that local command approval and actual customer public-use consent are separate, independently-required permissions — a meaningful authorization disclosure for a write tool.
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 tight sentences with zero filler; the core action is front-loaded and the consent clarification follows immediately. Nothing is repeated from the title or schema verbatim.
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 14-parameter, nested-payload mutation with no output schema, the description covers the critical consent semantics but omits the mutually-exclusive input modes (payload vs. payload_file vs. flat body flags), the role of the required payload.name/testimonial fields, and any contrast with sibling testimonial submission tools. Adequate but leaves several agent-relevant 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 coverage is 71% and the schema itself already documents the confirm/customer_consent split and the payload vs. payload_file exclusivity. The description reinforces the consent distinction but adds no format, cardinality, or naming detail beyond the schema, 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?
The description states a specific action ('Import a real authorized customer statement'), which maps clearly to creating a text testimonial record. It is distinguishable from submit_video_testimonial by subject matter, but it never explicitly names or contrasts with any sibling tool.
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 real guidance on the two consent concepts (local confirm for the API call vs. customer_consent/payload.confirm for public-use permission), which is implied usage context. However, it never says when to choose this tool over submit_video_testimonial, submit_testimonial_batch, or preview_testimonial_batch, nor does it state prerequisites or exclusions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Import a real publicly accessible authorized video. Provider retrieves/processes the URL; this package never downloads it. Success does not mean processing finished.
| Name | Required | Description | Default |
|---|---|---|---|
| name | No | Actual submitter name. | |
| No | |||
| title | No | Native combined title/company. | |
| account | No | Exact configured private account profile label; not a tenant or provider account ID. | |
| confirm | No | Must be true for the requested mutation or exclusive private output file. | |
| isLiked | No | Add to Wall of Love, false by default; local public-use consent is required if true. | |
| payload | No | Complete native testimonial JSON object; do not mix with body flags or payload_file. | |
| videoURL | No | Existing public HTTPS video URL without credentials. | |
| socialLink | No | Native social profile value. | |
| payload_file | No | Absolute regular non-symlink JSON body file, at most 1 MiB. Cannot mix with payload/body flags. | |
| customer_consent | No | Native customer permission for public use, false by default. Independent from local command approval. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations declare this is a destructive, non-idempotent, open-world write, so the safety profile is covered. The description adds genuinely non-redundant behavior: the provider retrieves/processes the URL rather than the package downloading it, and success does not mean processing has finished (asynchronous). That async caveat is exactly the kind of context an agent cannot get from 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?
Three short sentences, zero filler, with the import action front-loaded and the two behavioral caveats trailing. Nothing is repeated from the schema or annotations.
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 an 11-parameter tool with a nested payload object, three mutually exclusive input modes (payload, body flags, payload_file), zero required params, and no output schema, the description covers the async behavior but gives no guidance on which input mode to use or the confirm/consent requirements. The schema carries most of that, but the complexity leaves clear 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 91%, so the schema already documents the parameters, and the description adds almost no parameter-level meaning beyond the 'authorized/public' qualifier. Baseline 3 applies 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 ('Import a real publicly accessible authorized video'), which lets an agent distinguish this from submit_text_testimonial and the batch sibling without opening a schema. It stops short of explicitly naming itself a 'video testimonial' submission or differentiating further from the siblings.
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 choose this tool over submit_text_testimonial, submit_testimonial_batch, or send_testimonial_request. The 'publicly accessible authorized' qualifier hints at preconditions but gives no routing guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Explicit native key verification. Response includes Space id and account email; private metadata, not ownership or all-action proof.
| Name | Required | Description | Default |
|---|---|---|---|
| account | No | Exact configured private account profile label; not a tenant or provider account ID. |
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 value by disclosing what the response contains (Space id, account email) and bounding what verification proves — private metadata, not ownership. It stops short of describing auth requirements or failure 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 compact sentences that lead with the action and follow with response/scope caveats. It is front-loaded and free of filler, though the second sentence's phrasing is dense and slightly cryptic.
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, and the description partially compensates by naming the returned fields. But for a verification tool it omits the key questions — what result indicates a valid vs invalid key, and whether errors are surfaced — leaving the definition only adequately 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 single optional 'account' parameter is fully documented in the schema itself. The description adds no parameter-level detail, which is the expected baseline when 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 title 'Verify the selected Space key' and the phrase 'Explicit native key verification' convey the resource (a Space API key) and action (verification), and the description notes the response returns Space id and account email. However, the wording is elliptic ('native', 'explicit') and never plainly states it checks whether the configured key is valid, so an agent must infer the core 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?
There is no guidance on when to call this versus alternatives, nor any prerequisite or trigger context. The only scoping is a negative: 'not ownership or all-action proof,' which limits expectations but does not tell the agent when verification is warranted.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
v2.0.1export_testimonialsget_operation_schemalist_accountslist_testimonialspreview_testimonial_batchsend_testimonial_requestsubmit_testimonial_batchsubmit_text_testimonialsubmit_video_testimonialverify_spaceScored across 10 tools
Each tool targets a distinct action (list, verify, submit text, submit video, send request, preview batch, submit batch, export), so overlap is limited. The main potential confusion is between list_testimonials and export_testimonials since both read testimonials, but the descriptions clarify that one reads a JSON array and the other writes to a file.
All ten tools use snake_case with a consistent verb_noun pattern (list_testimonials, submit_text_testimonial, send_testimonial_request, export_testimonials). No stylistic deviations or mixed conventions appear.
Ten tools sit squarely in the well-scoped range, and each maps to a distinct operation (reads, submissions, batch preview/submit, schema/verification helpers). Nothing feels redundant or padding the surface.
The surface covers create (import text/video) and read (list/export) well, but there are no update or delete operations for testimonials and no approval/rejection or management of existing entries. Pagination is also explicitly absent, leaving notable lifecycle gaps an agent cannot work around.
Agent-complete, permission-scoped product operations for Priorify workspaces.
Give your AI agents trusted access to the full Postman platform.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.
Task management for people and AI agents, with scoped OAuth access to issues, projects, and docs.