Read Testimonial.to Space testimonials, import authorized text/video proof, send request emails, and export bounded private JSON — 10 shared CLI/MCP tools (5 read, 5 confirm-gated effects).
Read testimonials (list_testimonials): one newest-first array, filtered by type, liked, highlighted, repeated tag (OR match), and limit; no pagination.
Verify the Space key (verify_space): explicit GET /verify returning Space id and account email metadata.
List local accounts (list_accounts): configured profile labels/default/auth method only — no keys, paths, or network calls.
Inspect operation schemas (get_operation_schema): reviewed method/path/query/body and provenance for the 5 native operations, locally.
Preview a batch (preview_testimonial_batch): locally validate 1–20 ordered import/email tasks and return a SHA-256 review hash; no network or key load.
Import a text testimonial (submit_text_testimonial): POST /submit/text with required testimonial/name; needs local confirm plus separate real customer_consent for public use.
Import a video testimonial (submit_video_testimonial): POST /submit/video with required videoURL/name; provider fetches/processes the public HTTPS URL asynchronously.
Send a testimonial request email (send_testimonial_request): side-effecting GET /new/request requiring name, email, spaceName, adminName, and explicit local approval.
Execute a reviewed batch (submit_testimonial_batch): run 1–20 confirmed tasks only if review_sha256 matches exactly; stops on first failure, no retries or rollback.
Export testimonials (export_testimonials): save one bounded native GET to a new exclusive 0600 JSON file (default limit 100, max 10,000, 5 MiB cap); no overwrite or pagination.
Safety guardrails: read-only mode (TESTIMONIAL_READ_ONLY) hides/refuses all effect tools; TESTIMONIAL_ALLOW_DESTRUCTIVE=0 refuses them even with confirmation; local confirm never substitutes for native customer consent; the legacy update_testimonial endpoint is excluded.
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. Built on Slipway, which turns one definition of each tool into the MCP server and the CLI. 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-3.0.0.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 compact JSON with no prompts and never confirms. testimonial-cli which <words> finds the command for a task. 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 |
1 | Unexpected error |
2 | Usage/schema/refused effect, an unknown command or a hidden write |
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.
Measured on 2026-10-05 against 2.0.2, with Claude Code 2.1.286 on Claude Opus 5.5 (one short prompt with and without the server connected, the difference read from the API's own usage figures) and Codex 0.159.3 on gpt-6.1-sol:
Cost | 2.0.2 | 3.0.0 |
Claude Code, every tool loaded, every message | 4,922 | 4,902 |
Claude Code's default, tool search, every message | 529 | 528 |
| 2,318 | 2,400 |
Codex over the CLI, one task, median of five | 82,582 | 71,761 |
Codex over MCP, the same task, median of five | 43,592 | 43,577 |
The task was "find the command that sends a testimonial request, and the flags it requires". Every tool loaded costs slightly less, while the list a client receives grows by an approval marker on the five confirmed tools, which Claude Code does not pass to the model. Over the CLI, every 3.0.0 run asked which, whose answer carries the command's help, and three answered from it, where 2.0.2's runs read the command list or the general help a second time before the command's help. Over MCP, the two cost about the same. SKILL.md costs 82 more because it says how approval works over MCP and how which finds a command, and what exit codes 1 and 2 cover.
Tool-list bytes or characters divided by four are not API usage, and no other offering was measured.
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 | Set true only when the user asked for exactly this action. |
| 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 | Set true only when the user asked for exactly this action. |
| 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 | Set true only when the user asked for exactly this action. |
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 | Set true only when the user asked for exactly this action. |
| 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 | Set true only when the user asked for exactly this action. |
| 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.
Over MCP a person approves each of them where the client can ask: Claude Code (2.1.246 and later) shows its own prompt, and a client that can show forms asks with an approval form whose one box starts unticked. Each approval is signed, bound to that exact call and works once. Where a client can do neither, the model's confirm:true counts. TESTIMONIAL_CONFIRM=model makes confirm:true enough everywhere, for an agent with no person to ask.
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; Slipway builds the MCP server, over stdio or --http, and the CLI from them. Both surfaces share native validation, compilation, private profiles and the write guard. 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 |
TESTIMONIAL_CONFIRM | human by default; model lets confirm:true alone approve over MCP, for an agent with no person to ask |
TESTIMONIAL_SURFACE | full by default; search lists three tools that find, describe and run the rest |
TESTIMONIAL_TOOL_TIMEOUT_MS | Give up on any tool after this long |
TESTIMONIAL_HTTP_PORT, TESTIMONIAL_HTTP_HOST, TESTIMONIAL_HTTP_TOKEN | For --http: port 8787 and host 127.0.0.1 by default; any other host needs the bearer token |
TESTIMONIAL_HTTP_ALLOWED_ORIGINS | Comma-separated browser origins allowed to call --http; a page from any other site is refused |
TESTIMONIAL_DEBUG | 1 prints debug lines on stderr |
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 | Measured against 2.0.2 in README section 7 | No comparison with another offering |
Legacy tool | Contract since 2.0.1 |
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 | 3.0.0 |
Slipway | 0.1.20 |
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 | Measured against 2.0.2 in README section 7 |
CHANGELOG.md records dated changes. Version 2.0.0 introduced the current REST companion; 2.0.1 corrects export approval and payload help. 3.0.0 moves both surfaces onto Slipway and keeps every tool's name and arguments. 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. In Claude Code the CLI costs nothing until it is used, plus about 2,400 tokens for SKILL.md once, where the server costs about 530 tokens a message with tool search and 4,900 with every tool loaded. In Codex, finding the command that sends a testimonial request and its flags took a median of 71,761 input tokens over the CLI and 43,577 over MCP. Section 7 has how each was measured.
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 | Set true only when the user asked for exactly this action. | |
| 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 declare destructiveHint=true, idempotentHint=false and openWorldHint=true, and the description adds real substance beyond them: exclusive mode 0600 file creation, default limit 100, local maximum 10,000, a 5 MiB response/file cap, and explicit negatives (no pagination, no overwrite, not an atomic backup). It still omits auth/permission requirements and rate-limit behavior, so it is strong but 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 sentences with no filler; every clause (file mode, limits, cap, exclusions) carries information. The telegraphic, article-dropping style ('Confirmed single native GET saved to a new exclusive mode 0600 JSON file') costs some readability, which keeps it from a 5.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With 8 parameters, no output schema and mutation semantics, the description covers the important behavioral envelope: what file is produced, its permissions, size and count bounds, and what it deliberately does not do. It does not state failure behavior or permission prerequisites, but for this tool the core calling contract is present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (88%), so the schema already documents account, confirm, tag, output_file and the filter flags. The description only adds the default limit of 100 and the 5 MiB cap on top of the schema's stated maximum of 10,000, which is a marginal but genuine increment — baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names a concrete verb+resource (a native GET exported to a JSON file) and the title pins it to 'one bounded private testimonial array', so an agent can tell it is an export rather than a submit/preview sibling. It stops short of naming an explicit alternative (e.g. list_testimonials vs this export), so it is clear but not fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The 'Confirmed' framing and the confirm parameter imply the user must have explicitly requested this exact action, and the closing 'No pagination, continuation, media download, overwrite or atomic complete-backup claim' usefully rules out adjacent expectations. However, there is no explicit when-to-use versus list_testimonials or preview_testimonial_batch, so guidance is implied rather than stated.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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 | Set true only when the user asked for exactly this action. | |
| 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 mark this destructive, non-idempotent and open-world, but the description adds genuinely new operational facts: it sends a real email, it requires explicit local confirmation, and there is no dry run, retry or delivery guarantee. This is exactly the extra context an agent needs before triggering an irreversible send.
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, with the side effect and the confirmation requirement front-loaded. Nothing is padded and 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 six-parameter, non-idempotent mutation with no output schema, the description covers impact, prerequisite and failure expectations well. It could still say what the recipient receives or that content comes from approved email context, but the essentials for safe invocation are present.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so the parameters are already well documented (including 'confirm' and the non-tenant 'account' label). The description's confirmation sentence loosely maps to the confirm parameter but adds no syntax or format detail beyond the schema, so the baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: sends a real testimonial request email. It also flags the unusual transport ('side-effecting GET'), which distinguishes it from read-style siblings like list_testimonials. It does not name any sibling explicitly, so it stops short of a 5.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Gives a clear precondition ('explicit local confirmation is mandatory') and a clear exclusion ('no dry run'), which is real when-to-use guidance. It still never names an alternative sibling (e.g. preview_testimonial_batch) for users who want to inspect without sending.
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 | Set true only when the user asked for exactly this action. | |
| 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 already declare destructiveHint=true, idempotentHint=false and openWorldHint=true, but the description adds failure semantics the agent could not otherwise know: stop on first failure, return known results plus failed index and unattempted indices, and explicitly no retries, no rollback, no implicit continuation. That is precisely the operational context needed before firing a destructive batch.
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 tight sentences with no filler; the scope, the pre-request validation and the failure contract are front-loaded in that order. It is telegraphic to the point that the opening clause is a noun fragment rather than a sentence, which slightly hurts readability but wastes nothing.
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 batch tool with no output schema, the description supplies the crucial failure/return-shape contract (known results, failed index, unattempted indices) and rules out rollback. It does not spell out the side effect on the target system (published testimonials vs. dispatched emails) or the meaning of the account binding, which the schema covers only partially.
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 the ordering and 1-20 bound of tasks and the hash-verification requirement for review_sha256, but adds no syntax or format detail beyond what the schema states, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description names the exact resource (testimonial tasks) and its scope (one-to-twenty ordered text/video import/email operations), which separates it from the single-task siblings submit_text_testimonial, submit_video_testimonial and send_testimonial_request. The verb is implicit (the fragment 'Confirmed ... tasks' never says 'executes'), but the title and the batching scope make the intent unambiguous.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It implies the correct workflow (prevalidate everything, verify the exact hash before the first request), which only makes sense after a preview, and 'Confirmed' implies prior review. However, it never names preview_testimonial_batch as the required predecessor or states when to use this batch tool versus the individual submit tools, leaving the routing to inference.
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 | Set true only when the user asked for exactly this action. | |
| 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 non-read-only, destructive, non-idempotent, open-world behavior, so the bar is lower. The description adds genuinely useful context beyond them: it separates local command approval ('confirm') from actual public-use permission ('customer_consent'/'payload.confirm'), a non-obvious dual-consent model. It does not describe reversibility or side effects of the destructive write, keeping it short of a 5.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two tight sentences with no filler, and the core purpose is front-loaded before the consent clarification. Minor jargon ('Local confirm approves the API call') slightly reduces immediate clarity but wastes no space.
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-object, no-output-schema write tool, the description covers the most confusing aspect (dual consent) but omits the mutual-exclusivity constraints between payload, payload_file, and top-level fields, and says nothing about the result of a successful submission. Adequate but with clear gaps given the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
With 14 parameters and 71% schema description coverage, the schema carries most of the load, so baseline 3 applies. The description clarifies the confirm/customer_consent distinction, but this is largely restated from the schema's own parameter descriptions (e.g., 'Independent from local command approval'), and it says nothing about the payload vs. payload_file vs. top-level field paths.
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 verb and resource ('Import a real authorized customer statement'), which clearly maps to submitting a text testimonial. However, it never distinguishes this tool from close siblings like submit_video_testimonial, submit_testimonial_batch, or send_testimonial_request, so an agent must infer the boundary from the name alone.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explains consent semantics but never says when to choose this tool over its siblings (video, batch, request). There is no explicit when-to-use or when-not-to-use guidance; the only routing cue is the word 'text' implicit in the tool name.
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 | Set true only when the user asked for exactly this action. | |
| 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 a destructive, non-idempotent, open-world write, but do not explain the mechanics. The description adds real value the annotations cannot: the provider retrieves and processes the URL, this package does not download it, and a successful call does not imply processing is complete (async). It still omits why the operation is destructive and what authorization/consent is needed.
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 tight sentences, front-loaded with what the tool does, then two behavioral caveats. Nothing is padding and the async caveat is placed where it will be read.
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, zero-required, destructive, open-world write with no output schema, the description covers async processing but says nothing about the confirmation flag, the consent semantics (customer_consent vs. payload.confirm vs. isLiked), or the payload/flag/payload_file exclusivity. Adequate but leaving meaningful gaps that the schema only partly closes.
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% and the parameters are well documented in the schema itself (confirm, isLiked, payload vs. payload_file exclusivity, videoURL format). The description adds no parameter-level meaning beyond the schema, so the baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
States a specific verb and resource: import an authorized, publicly accessible video for a testimonial. The 'video' scope implicitly separates it from submit_text_testimonial, but the description never names that sibling or explicitly contrasts the two, so it stops short of full differentiation.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It imposes a precondition (video must be real, public, and authorized) but gives no when-to-use or when-not-to-use guidance and never points to alternatives such as preview_testimonial_batch or submit_testimonial_batch. The agent must infer routing from the tool name alone.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
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.
v3.0.0export_testimonials1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Explicit approval to save this bounded response to a new private file."New value: +"Set true only when the user asked for exactly this action."send_testimonial_request1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Must be true for the requested mutation or exclusive private output file."New value: +"Set true only when the user asked for exactly this action."submit_testimonial_batch1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Explicit approval for this exact requested ordered batch."New value: +"Set true only when the user asked for exactly this action."submit_text_testimonial1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Must be true for the requested mutation or exclusive private output file."New value: +"Set true only when the user asked for exactly this action."submit_video_testimonial1 field changedInput schema / properties / confirm / descriptionPrevious value: -"Must be true for the requested mutation or exclusive private output file."New value: +"Set true only when the user asked for exactly this action."v2.0.1export_testimonialsget_operation_schemalist_accountslist_testimonialspreview_testimonial_batchsend_testimonial_requestsubmit_testimonial_batchsubmit_text_testimonialsubmit_video_testimonialverify_spaceScored across 10 tools
Most tools have clearly distinct purposes (schema lookup, account listing, verification, listing, exporting, requesting, single vs batch import). The main risk is overlap between submit_text_testimonial/submit_video_testimonial/submit_testimonial_batch and between list_testimonials/export_testimonials, but the detailed descriptions clarify the boundaries.
All tools follow a consistent snake_case verb_noun convention (get_operation_schema, list_accounts, submit_text_testimonial, export_testimonials, verify_space). No mixing of camelCase or inconsistent verb styles.
Ten tools is well-scoped for a testimonial platform integration, covering auth, discovery, listing, exporting, and several import/request paths. Each tool appears to earn its place.
Core read and import workflows (list, export, submit text/video/batch, request) are covered, but there are notable gaps: no update or delete for testimonials and no get-single-testimonial operation. This leaves lifecycle management incomplete for a CRUD-style domain.
Read-only tools for agency testimonial walls: list clients, testimonials, and embed widgets.
Import, approve, tag and feature customer testimonials in your testimonials.ltd workspace.
Agent-complete, permission-scoped product operations for Priorify workspaces.
Create, manage, schedule, and publish short-form user-generated content through AI agents.
