This server wraps Svmmon's API to generate and manage TikTok slideshows from Claude (or any MCP client). It requires a paid Svmmon subscription.
Check usage (get_usage): View your subscription tier, monthly slideshow limits, reset date, and available TikTok inbox draft slots.
List profiles (list_profiles): See all your Svmmon personas with their ID, name, niche, readiness status, missing requirements, and TikTok link status — only ready: true profiles can generate slideshows.
List presets (list_presets): Discover available slide-structure presets (e.g. listicle) to use during slideshow generation.
Generate hooks (generate_hooks): Produce AI-scored TikTok hook candidates (ranked 0–100 for virality) for a profile, optionally guided by a topic or tone; results are saved to the profile's hook library.
Generate a slideshow (generate_slideshow): Create a complete, rendered TikTok slideshow from a profile and hook; optionally deliver it directly to TikTok as a draft or via Telegram; returns a 24-hour download link.
List recent slideshows (list_slideshows): Browse up to 100 recently generated slideshows with hook text, profile, and creation date.
Fetch a specific slideshow (get_slideshow): Retrieve a slideshow by ID with a fresh 1-hour signed download URL — useful when the original link has expired.
Click on "Install 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., "@svmmon-mcp Create a slideshow for my cooking profile"
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.
Generate TikTok slideshows from Claude (and any MCP client) using your Svmmon account.
This is a thin, local stdio MCP server that wraps Svmmon's public /api/v1 REST API. Install it, paste your key, and ask Claude to make slideshows in plain language. It adds no business logic — every tool maps 1:1 onto a real Svmmon endpoint.
Requires an active subscription. The API works on any active paid plan (per-tier volume caps still apply). Install always works; the tools return a clean "requires an active subscription" message until you paste a valid paid key.
app.svmmonapp.com → Settings → API Keys → Svmmon API → Generate key (any paid plan). It looks like svm_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx.
Treat this key like a password. If it's ever exposed, revoke it instantly in Settings → API Keys — the MCP can't revoke it for you.
Claude Desktop — edit claude_desktop_config.json:
{
"mcpServers": {
"svmmon": {
"command": "npx",
"args": ["-y", "svmmon-mcp"],
"env": { "SVMMON_API_KEY": "svm_your_key_here" }
}
}
}Claude Code:
claude mcp add svmmon -e SVMMON_API_KEY=svm_your_key_here -- npx -y svmmon-mcpGenerate 5 hooks for my Marcus profile and make a slideshow from the best one.
Related MCP server: AITuber MCP Server
Tool | What it does |
| Full usage: tier + plan, slideshows used/cap, AI credits, rerolls, shorts/face-swap caps, account caps, per-account TikTok inbox slots. |
| Your profiles with |
| Valid |
| Scored hook candidates for a profile. Spends AI credits, so it is confirm-gated (see below). May return fewer than requested if your AI-credit cap is hit. |
| Generates ONE slideshow (consumes one from your monthly cap — not idempotent, confirm-gated). Returns a 24h download link; optionally delivers to TikTok/Telegram. |
| Studio image generation on your own provider key (BYOK — not idempotent, confirm-gated). |
| Studio video generation on your own provider key (BYOK — not idempotent, confirm-gated). |
| Remake a public TikTok slideshow in one of your profile voices. Costs 2 slideshows + 2 AI credits (confirm-gated). Async: returns a |
| Poll a recreation by |
| Abandon an in-flight recreation (confirm-gated). Not a refund — see below. |
| Your recent slideshows. |
| Fetch a slideshow + a fresh 1h download link by id. |
| Your image collections with per-collection image-fatigue health tiers. |
| One collection's images, with optional 10-min signed URLs so a vision agent can inspect them. |
| Your personal brain for a profile — patterns, voice DNA, next-hook directions (Growth+). |
| The anonymized community brain — what's working across accounts. |
| Post performance — views/likes/shares/comments, day-1 + final. |
| Live TikTok profile + recent-video stats (Growth+). |
| Studio model catalog + which of your provider keys unlock what. |
| Recent studio generations (metadata; provider source URLs may be expired). |
| Your saved studio generations. |
| Your connected TikTok accounts + live connection health (needs_reconnect, connection_error). |
| Your automations — active state, schedule, delivery mode, hook source, hook count, last run status. |
| One automation's full detail by id. |
| Your posting schedule — every slot's time, days, timezone, and which automation fires it. |
| One profile's full detail — bio, audience, tone, CTA, hashtags, readiness, linked accounts/automations. |
| A profile's hook library — text, status, source, used_count, virality_score. |
| Globally trending TikTok posts (not account-specific) — optional hashtag/days filter. |
Every write tool is two-step confirm-gated: the first call returns a preview of the exact consequence and cost and does nothing; you must call again with confirm: true to execute. Surface the preview to the user before confirming.
The four generate_* tools above are confirm-gated the same way, because they spend money — a slideshow slot, AI credits, or your own provider credits. They also need a write-scoped API key, exactly like the tools in this table.
recreate_slideshow is the one tool that does not finish in a single call. It costs 2 slideshows + 2 AI credits (double a normal generate, because it scrapes the source post and runs a vision read on top of writing the deck) and takes 1-4 minutes, so it returns a job_id immediately rather than polling inline — a client-side tool timeout mid-poll would otherwise lose the only handle on a run that may already have spent quota.
Poll get_recreate_status with that job_id every ~10 seconds. Never call recreate_slideshow again to check on a running job; that starts a second paid recreation.
Only one recreation runs at a time per account, shared with the dashboard. A second start returns 429 and spends nothing.
A failure with error.status 422 means the URL was not a slideshow, and that case never billed. Other failures are refunded automatically.
cancel_recreate is not a refund. It only stops the run if the worker has not reached its charge checkpoint. Land it later and the credits are already spent.
Tool | What it does |
| Upload base64 images (max 20) into an owned collection. Counts against your image-storage cap. |
| Add manual hooks (max 50) to a profile's hook library. |
| Permanently delete one hook from a profile's library (irreversible). |
| Edit a profile's safe voice/CTA/hashtag/product fields. Preview shows a current → new diff. |
| Re-post an already-generated slideshow to TikTok/Telegram — no AI call and no monthly quota spent. Uses a TikTok inbox slot. |
| Run an automation now — spends 1 slideshow + AI credits and posts LIVE. Cannot be undone. |
Env var | Required | Default | Notes |
| Yes | — | Your |
| No |
| Override only for self-host/staging. |
"key is missing, invalid, or revoked" (401) — Set SVMMON_API_KEY to a current key from Settings → API Keys.
"requires an active subscription" (403) — Subscribe at app.svmmonapp.com/subscribe. Any active paid plan works.
"a usage cap was reached" (402) — You hit your monthly slideshow or AI-credit cap. Run get_usage.
"Rate limited" (429) — Wait the suggested time if one is shown; otherwise it's a daily AI limit that resets at midnight UTC. The message tells you which.
1.x targets the Svmmon /api/v1 contract. A breaking API change (/api/v2) would ship as 2.x.
This package handles a live, cost-bearing credential. It reads the key from the environment only, never logs it, never puts it in process arguments, and never echoes it in errors. It performs no auto-retries on cost-burning calls. Report security issues to support@svmmonapp.com.
MIT
Generate scored TikTok hook candidates for one of the user's Svmmon profiles. Use when the user asks for hooks, openers, or angles for a profile (e.g. "give me 5 hooks for my Marcus profile about staying consistent"). Returns hooks ranked by a 0-100 virality score and persists them to the profile's hook library. COST: each batch of 3 candidates spends one AI credit (count=5 → 2 credits). May return FEWER hooks than requested if the AI-credit cap is hit mid-request — that is expected, not an error. Requires a valid profile_id: call list_profiles first and never invent one.
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The id of the Svmmon profile to generate hooks for. Must belong to the key owner. Get it from list_profiles. | |
| direction | No | Optional steer for the angle/topic (e.g. "about quitting gambling, skeptic tone"). Max 1500 chars; only the first 500 are used by the generator. Omit to let Svmmon pick the strongest angles. | |
| count | No | How many hooks to return (1-10). Defaults to 5. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses persistence to hook library, cost model ('each batch of 3 candidates spends one AI credit'), potential for fewer results due to credit cap, and the necessity of a valid profile_id. All key behavioral aspects are covered.
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?
Every sentence contributes essential information: purpose, usage, scoring, persistence, cost, error behavior, prerequisite. No redundancy or fluff. Front-loaded with main purpose.
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 tool with 3 parameters and no output schema, the description fully explains what is returned (hooks ranked by virality score), cost implications, and possible outcomes. No gaps remain for selection or invocation.
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%, but description adds extra meaning: cost per count, truncation of direction field to 500 chars, and reinforcement of profile_id source. This adds value beyond the schema descriptions.
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?
Description clearly states 'Generate scored TikTok hook candidates for one of the user's Svmmon profiles.' The verb 'generate' and resource 'hooks' are specific. It distinguishes from siblings like generate_slideshow, list_profiles, etc., which are clearly different tasks.
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?
Explicitly says 'Use when the user asks for hooks, openers, or angles for a profile' with an example. Provides prerequisite: 'Requires a valid profile_id: call list_profiles first and never invent one.' This gives clear context on when to use and necessary preconditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Generate ONE complete TikTok slideshow from a Svmmon profile and a hook, render it, and optionally deliver it to TikTok or Telegram. The profile is the source of truth for tone, preset, images, slide counts, and CTA. Use when the user asks to make/create/build a slideshow or post from a hook. CONSUMES ONE SLIDESHOW from the monthly cap and is NOT idempotent — never call it twice for the same request; if it times out, check list_slideshows before retrying (the slideshow may already exist). Takes 30-120 seconds. Check get_usage first if you may be near the monthly cap. Returns a slideshow_id and a signed ZIP download_url valid for 24 hours. Delivery failures never fail generation — a failed TikTok/Telegram send comes back as a reason, not an error. Requires a ready profile_id (call list_profiles; only ready:true profiles can generate).
| Name | Required | Description | Default |
|---|---|---|---|
| profile_id | Yes | The id of a READY Svmmon profile (ready:true in list_profiles). The profile must have hook/body image collections configured. Must belong to the key owner. | |
| hook | Yes | The hook line — becomes slide 1 and the TikTok post title. Max 1000 chars. Often the top result from generate_hooks. | |
| preset_id | No | Optional slide-structure preset id (from list_presets). Defaults to the profile's preset, then 'listicle'. An unknown id is rejected by the API. | |
| deliver | No | Where to send the rendered slideshow. 'tiktok' pushes to the profile's linked TikTok inbox draft; 'telegram' sends the photo album; 'none' (default) just returns the download link. | none |
| tiktok_account_id | No | Optional, only with deliver:'tiktok'. A confirmation that must match the profile's linked TikTok account, or delivery fails with a mismatch reason. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Discloses: consumes one slideshow from monthly cap, not idempotent, takes 30-120 seconds, returns slideshow_id and download_url valid 24h, delivery failures don't fail generation, requires ready profile. Lacks explicit mention of errors beyond 'rejected' for unknown preset_id. Still very comprehensive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a well-structured paragraph with no wasted words. Core function is front-loaded, followed by usage rules, timing, return info, and error handling. Every sentence adds value.
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?
Despite no output schema and 5 parameters, the description covers the return values (slideshow_id, download_url), side effects (consumes cap, not idempotent), prerequisites (ready profile), error handling (delivery failure reason, unknown preset_id rejected), and timing. Complete for 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?
Schema description coverage is 100%, so baseline is 3. Description adds value beyond schema: explains profile as source of truth, hook becomes slide 1 and post title, preset defaults, deliver options and their effects, tiktok_account_id as confirmation. Adds context like 'often the top result from generate_hooks'.
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 clearly states 'Generate ONE complete TikTok slideshow from a Svmmon profile and a hook, render it, and optionally deliver it to TikTok or Telegram.' The verb (generate) and resource (slideshow) are specific. It distinguishes from siblings like generate_hooks (hooks) and get_slideshow (retrieval).
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?
Explicitly says when to use: 'Use when the user asks to make/create/build a slideshow or post from a hook.' Provides when-not: 'never call it twice for the same request', 'if it times out, check list_slideshows before retrying'. References siblings: list_profiles for ready profiles, get_usage for cap checking.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Fetch one slideshow by its id, including fresh 1-hour signed download URLs for its export ZIP. Use this when the user asks to "get the download link for slideshow X", "re-download a slideshow", or "get the link again" (the link from generate_slideshow expires after 24h; this mints fresh 1h links). Get the id from list_slideshows first. Read-only — consumes no quota. Download links may be empty if the slideshow has no export file (e.g. a Telegram-only export).
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | The slideshow id (uuid). Get it from list_slideshows. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description must carry full burden. It states 'Read-only — consumes no quota' and explains that download links may be empty if no export file exists (e.g., Telegram-only export). This clearly discloses mutation behavior, quota impact, and edge cases.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Description is concise with three front-loaded sentences. First sentence states core functionality, second gives usage guidance, third adds caveat. No filler; every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Tool has one parameter, no output schema, and low complexity. Description covers purpose, usage, behavior, parameter meaning, and edge cases (empty download links). Complete for the context.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% with id parameter described as 'The slideshow id (uuid). Get it from list_slideshows.' Description adds extra context by reiterating where to get the id, adding value beyond the schema, justifying a score above baseline 3.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
Description clearly states 'Fetch one slideshow by its id, including fresh 1-hour signed download URLs for its export ZIP.' This specifies the verb, resource, and distinct value (fresh 1-hour links), distinguishing it from siblings like generate_slideshow and list_slideshows.
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?
Provides explicit usage scenarios: 'when the user asks to get the download link for slideshow X, re-download a slideshow, or get the link again.' Also mentions prerequisite ('Get the id from list_slideshows first') and clarifies that links from generate_slideshow expire after 24h, while this mints fresh 1h links.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Check the Svmmon account's current usage and limits: subscription tier, monthly slideshows used vs. cap, when the counter resets, and per-TikTok-account inbox draft slots (used/cap/available). Use this to answer "how many slideshows do I have left", "check my Svmmon usage", or "how many TikTok slots are free" — and call it before a batch of generations to confirm there is quota and TikTok slot headroom. Consumes no quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. It discloses that the tool consumes no quota, implying no side effects or destructive behavior. Could be improved with an explicit 'read-only' statement, but current disclosure is sufficient for a safe status check.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with key information. First sentence defines scope, second sentence provides usage context and a safety note. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a no-parameter tool, the description comprehensively details returned data (usage, limits, slots) and usage guidelines. It is complete enough without an output schema, and sibling tools are sufficiently differentiated.
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?
Input schema has zero parameters (baseline 4). Description adds meaning by explaining the tool's output, but there is no parameter-related information needed. The description fully covers what the tool does without parameters.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose: checking Svmmon account usage and limits, including subscription tier, monthly slideshows used vs cap, reset time, and per-TikTok-account draft slots. It distinguishes from siblings (e.g., generate_slideshow, list_slideshows) by focusing on usage/status rather than content creation or retrieval.
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?
Explicitly provides when to use: answering specific questions ('how many slideshows do I have left', 'check my usage') and before batch generations to confirm quota and slot headroom. Also states it consumes no quota, guiding appropriate invocation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the slide presets you can pass as preset_id to generate_slideshow. Use this for "what slide presets can I use" or before generating a slideshow when the user wants a specific structure. Every id returned is a valid preset_id. Consumes no quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that the tool 'consumes no quota', which is a valuable behavioral trait for agent cost management. It doesn't mention authentication or caching, but for a simple list tool this is sufficient.
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 extremely concise with no wasted words. Two sentences front-load the purpose and usage guidance.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with no parameters or output schema. The description covers the purpose, usage, and quota behavior. It could hint at the return format (e.g., list of strings), but the completeness is adequate.
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?
There are no parameters, so the schema coverage is 100%. The description adds value by explaining that the returned values are valid preset_ids for use with generate_slideshow, going 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 description clearly states the verb 'list' and the resource 'slide presets', with explicit purpose to provide valid preset_id values for generate_slideshow. It distinguishes from siblings like list_slideshows and generate_slideshow.
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 explicitly tells when to use the tool ('what slide presets can I use' or before generating a slideshow) and that every returned id is valid. It does not explicitly mention when not to use it, but the sibling tools are distinct enough that confusion is unlikely.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the Svmmon account's profiles (personas) with their id, name, niche, generation readiness, and whether a TikTok account is linked. Use this for "what profiles do I have" or "list my Svmmon personas". IMPORTANT: only profiles where ready is true can generate a slideshow — if a profile is not ready, the missing list says which image collection it still needs. Never invent a profile id; call this first to get a real one. Consumes no quota.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden. It discloses that profiles with 'ready: true' can generate a slideshow, explains the 'missing' list, and states 'Consumes no quota.' These details provide useful behavioral transparency beyond a simple list operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise (4 sentences) and well-structured. It front-loads the purpose and output fields, then adds important usage notes. Every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with no output schema, the description is complete: it lists returned fields, explains how to interpret readiness, and notes quota impact. No gaps or missing information.
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?
There are zero parameters, so per guidelines the baseline is 4. The description does not need to add parameter meaning, and it correctly focuses on the tool's behavior and output.
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 clearly states it lists Svmmon account profiles with specific fields (id, name, niche, generation readiness, TikTok account linkage). It also provides example queries like 'what profiles do I have' or 'list my Svmmon personas', making the purpose unmistakable and distinguishing it from sibling tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly tells when to use the tool ('for what profiles do I have' or 'list my Svmmon personas') and provides important guidance: 'Never invent a profile id; call this first to get a real one.' It lacks explicit when-not-to-use instructions, but the context is clear and sufficient.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List the most recent slideshows on this Svmmon account, newest first. Use this when the user asks to "show my recent slideshows", "what have I generated", or wants a slideshow id to fetch its download link with get_slideshow. Returns id, hook text, profile_id, and created_at for each. Read-only — consumes no quota. Optional limit (1–100, default 20).
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | How many slideshows to return, newest first. 1–100, default 20. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
States 'Read-only — consumes no quota,' which is crucial behavioral info since no annotations are provided. Also lists return fields.
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 concise sentences that front-load purpose, then usage, then details. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with one optional parameter and no output schema, the description covers purpose, usage, return fields, and behavioral traits completely.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100%, and the description repeats the same info (optional limit 1-100, default 20) without adding new meaning.
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?
Description clearly states 'List the most recent slideshows on this Svmmon account, newest first,' which is a specific verb and resource. It distinguishes from siblings like get_slideshow by noting the use case for obtaining a slideshow id.
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?
Provides explicit examples of when to use: 'show my recent slideshows', 'what have I generated', or to get an id for get_slideshow. Indirectly tells when not to use by mentioning the alternative sibling.
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. Dates show when Glama detected each change.
v1.0.0generate_hooksgenerate_slideshowget_slideshowget_usagelist_presetslist_profileslist_slideshowsEach tool targets a distinct action: generating hooks, generating slideshows, fetching a single slideshow, checking usage, listing presets, listing profiles, and listing slideshows. No two tools have overlapping purposes.
All tool names follow a consistent verb_noun pattern (e.g., generate_hooks, list_profiles, get_usage), making it easy for an agent to predict behavior from the name alone.
Seven tools cover the full lifecycle of generating TikTok slideshows without bloat. Each tool serves a clear, necessary function and the count is appropriate for the domain.
The tool set covers all core operations: hook generation, slideshow creation, download retrieval, usage monitoring, and listing of presets, profiles, and slideshows. No obvious gaps for the stated purpose.
Unclaimed servers have limited discoverability.
If you are the server author, to access and configure the admin panel.
Use AI models for chat, image, and video generation from Claude Code and other MCP hosts.
Generate AI images and videos from any compatible MCP client.
AI voice generation: text-to-speech and voice cloning from any MCP client.
MCP server for Hailuo (MiniMax) AI video generation
We provide all the information about MCP servers via our MCP API.
curl -X GET 'https://glama.ai/api/mcp/v1/servers/coreywessel/svmmon-mcp'
If you have feedback or need assistance with the MCP directory API, please join our Discord server
