svmmon-mcp

by coreywessel

Overview Schema Related Servers Score Discussions

TypeScript

Local

Server Quality Checklist

Profile completionA complete profile improves this server's visibility in search results.

Latest release: v1.0.0
Disambiguation5/5
Each 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.
Naming Consistency5/5
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.
Tool Count5/5
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.
Completeness5/5
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.
Average 4.7/5 across 7 of 7 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 17 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

Servers are automatically synced at least once per day, but you can also sync manually at any time to instantly update the server profile.

To manually sync the server, click the "Sync Server" button in the MCP server admin interface.

How is the quality score calculated?

The overall quality score combines two components: Tool Definition Quality (70%) and Server Coherence (30%).

Tool Definition Quality measures how well each tool describes itself to AI agents. Every tool is scored 1–5 across six dimensions: Purpose Clarity (25%), Usage Guidelines (20%), Behavioral Transparency (20%), Parameter Semantics (15%), Conciseness & Structure (10%), and Contextual Completeness (10%). The server-level definition quality score is calculated as 60% mean TDQS + 40% minimum TDQS, so a single poorly described tool pulls the score down.

Server Coherence evaluates how well the tools work together as a set, scoring four dimensions equally: Disambiguation (can agents tell tools apart?), Naming Consistency, Tool Count Appropriateness, and Completeness (are there gaps in the tool surface?).

Tiers are derived from the overall score: A (≥3.5), B (≥3.0), C (≥2.0), D (≥1.0), F (<1.0). B and above is considered passing.

Tool Scores

Behavior4/5
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.
Conciseness5/5
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.
Completeness4/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines4/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior4/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters3/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.
Behavior5/5
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.
Conciseness5/5
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.
Completeness5/5
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.
Parameters4/5
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.
Purpose5/5
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.
Usage Guidelines5/5
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.

GitHub Badge

Glama performs regular codebase and documentation scans to:

Confirm that the MCP server is working as expected.
Confirm that there are no obvious security issues.
Evaluate tool definition quality.

Our badge communicates server capabilities, safety, and installation instructions.

Card Badge

Copy to your README.md:

[![svmmon-mcp MCP server](https://glama.ai/mcp/servers/coreywessel/svmmon-mcp/badges/card.svg)](https://glama.ai/mcp/servers/coreywessel/svmmon-mcp)

Score Badge

Copy to your README.md:

[![svmmon-mcp MCP server](https://glama.ai/mcp/servers/coreywessel/svmmon-mcp/badges/score.svg)](https://glama.ai/mcp/servers/coreywessel/svmmon-mcp)

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

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