Skip to main content
Glama
hanshs474

kavel-mcp

by hanshs474
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Kavel MCP

An MCP server for Kavel — bring Kavel's AI photo & video generators into any MCP client (Claude, Cursor, Cline, …). Ask for an effect, get a model-tuned prompt, and open the right tool to generate it on www.kavel.ai.

No account or API key required to use this server — it helps you pick a tool and craft a prompt, then hands off to Kavel's free-tier generators.

What it does

Tool

What it returns

list_kavel_tools

Browse/search Kavel's generators by goal (e.g. "make my dog look royal")

build_kavel_prompt

A model-tuned prompt recipe for a chosen effect, customized with your details

open_in_kavel

The direct generator URL, pre-set to the right mode

list_kavel_models

The image/video models Kavel runs and what each is good at

Related MCP server: Gemini 2.5 Flash Image MCP

Featured generators

Install

Run directly with npx:

npx kavel-mcp

Claude Desktop / Claude Code

Add to your MCP config (claude_desktop_config.json or .mcp.json):

{
  "mcpServers": {
    "kavel": {
      "command": "npx",
      "args": ["-y", "kavel-mcp"]
    }
  }
}

Cursor / Cline

Point the client at the command npx -y kavel-mcp (stdio transport).

Skill (Claude Code / Cursor / Codex)

This repo also ships the kavel-image-studio agent skill (skills/kavel-image-studio/) — it helps pick the right Kavel generator, craft a model-tuned prompt, and hand off the generate link.

Install via the open agent-skills CLI:

npx skills add hanshs474/kavel-mcp

Or as a Claude Code plugin marketplace:

/plugin marketplace add hanshs474/kavel-mcp
/plugin install kavel-image-studio

Develop

npm install
npm run build
npm start

Links

License

MIT © Kavel

Gemini CLI

gemini extensions install https://github.com/hanshs474/kavel-mcp

Available Tools

4 tools
build_kavel_promptBuild a Kavel promptA

Get a model-tuned prompt for a specific Kavel tool. Returns Kavel's proven prompt recipe for that effect (tuned for its model), optionally customized with the user's details. Paste the result into the generator on the tool's page.

ParametersJSON Schema
NameRequiredDescriptionDefault
toolYesThe tool slug from list_kavel_tools, e.g. 'ai-figurine-generator'.
customizationNoOptional extra details to weave in, e.g. 'make the figurine hold a skateboard' or 'red velvet dress'.

TDQS

A3.8/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided. The description implies a read operation (getting a prompt) without disclosing side effects, authentication needs, or rate limits. It is behaviorally neutral but does not contradict any annotation.

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 two sentences long, with the purpose front-loaded. Every sentence serves a clear function: defining the output and providing usage instruction. No redundancy or unnecessary detail.

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?

Given the tool's simplicity (2 params, no output schema, no nested objects), the description adequately covers the behavior: it returns a prompt recipe and tells the user to paste it. It does not detail the return format, but the context makes it implicitly clear.

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%, so baseline is 3. The description adds examples (e.g., 'make the figurine hold a skateboard') which slightly enhances understanding, but largely repeats schema descriptions. No significant additional meaning beyond 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 tool's purpose: 'Get a model-tuned prompt for a specific Kavel tool.' It uses a specific verb ('Get') and resource ('Kavel prompt'), and distinguishes itself from sibling tools which list models, list tools, or open pages.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The description advises pasting the result into the generator, but lacks explicit when-to-use or when-not-to-use guidance compared to siblings. There is no mention of prerequisites or alternatives, making the usage context minimally adequate.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_kavel_modelsList Kavel modelsA

List the AI models Kavel runs (image and video), what each is good at, and whether it has a free tier.

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

A4.3/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations are provided, so the description carries full burden. It clearly states the output includes model capabilities and free tier status. For a read-only list tool with no side effects, this is sufficient transparency.

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 single, efficient sentence that front-loads the action and includes essential details. Every word 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 zero-parameter list tool, the description fully explains the output content (list of models with strengths and free tier). No additional details are necessary for correct 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?

The tool has no parameters, so the baseline score of 4 applies. The description does not need to add parameter info, and it adequately covers what the tool returns.

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 'AI models Kavel runs', specifying that it includes image and video models, their strengths, and free tier status. It is distinct from sibling tools like 'list_kavel_tools' and 'build_kavel_prompt'.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

No explicit guidance on when to use this tool versus alternatives is provided. While the purpose is clear, there is no mention of exclusions or context, which is acceptable for a simple tool but not exemplary.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

list_kavel_toolsList Kavel AI photo/video toolsA

Browse or search Kavel's AI photo & video generators (hairstyle changer, figurine, pet portrait, 90s yearbook, dance video, HD photo converter, and more). Use query to match a goal like 'make my dog look royal' or 'turn my selfie into a figurine'. Each result includes the direct URL on www.kavel.ai to generate it.

ParametersJSON Schema
NameRequiredDescriptionDefault
hubNoOptional filter: only image tools or only video tools.
queryNoOptional goal or keyword to match, e.g. 'new hairstyle', 'dancing video'.

TDQS

A3.6/5.0
Behavior3/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 each result includes a direct URL on www.kavel.ai, which is useful return information, but omits whether the operation is read-only, requires authentication, or has pagination limits.

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 three tight sentences, front-loading the core purpose and followed by query usage and return details. Every sentence earns its place with no redundancy.

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?

Given the simple two-parameter list tool with no output schema, the description adequately covers purpose, query usage, and the key return value (direct URL). It could be more complete by noting read-only nature or result limits, but it is sufficient for correct invocation.

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%, so the schema already documents both parameters. The description adds an example goal for `query` ('make my dog look royal'), but does not elaborate on the `hub` filter or explain matching semantics beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description names a specific verb+resource ('Browse or search Kavel's AI photo & video generators') and provides concrete examples. It does not, however, distinguish this tool from its siblings like list_kavel_models or build_kavel_prompt.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It implies usage by suggesting how to use the `query` parameter, but offers no explicit guidance on when to choose this tool over alternatives such as open_in_kavel or build_kavel_prompt. No exclusions or prerequisites are stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

open_in_kavelOpen a Kavel generatorB

Get the direct URL to a Kavel tool's generator page (on www.kavel.ai), pre-set to the right mode with a tuned prompt, so the user can generate the result. Free-tier models let users generate without paying.

ParametersJSON Schema
NameRequiredDescriptionDefault
toolYesThe tool slug from list_kavel_tools, e.g. 'ai-hairstyle-changer'.

TDQS

B3.4/5.0
Behavior3/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

No annotations, so the description must carry the load. It usefully discloses that the tool returns a URL on www.kavel.ai rather than generating anything itself, and that the page is pre-set to a mode plus a tuned prompt. It says nothing about auth, rate limits, or how the mode/prompt are chosen given only a slug is accepted.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

A single sentence with the action front-loaded and no filler. Slightly compressed into one long clause chain, but nothing is wasted or repeated.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a simple one-parameter tool with no output schema, it covers the essential return value (a URL) and outcome. It leaves a gap around the name/behavior mismatch ('open_in_kavel' vs. merely returning a URL) and how the claimed pre-set mode and tuned prompt are controlled from a single slug.

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 schema itself explains the 'tool' slug and its source (list_kavel_tools), so the baseline is 3. The description adds no format or source detail beyond what the schema already provides.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

Uses a specific verb+resource: 'Get the direct URL to a Kavel tool's generator page'. It is distinguishable from list_kavel_tools and list_kavel_models, though it does not explicitly name build_kavel_prompt even though the 'tuned prompt' clause is the closest sibling overlap.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The intent is implied ('so the user can generate the result') and the free-tier note hints at a use case, but there is no explicit when-to-use/when-not-to-use and no stated ordering relative to build_kavel_prompt or list_kavel_tools.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections.

  1. 2 tool updatesv0.1.1
    • Changedlist_kavel_tools1 field changed
      • changedInput schema / properties / query / description
        Previous value: -"Optional goal or keyword to match, e.g. 'wedding photo', 'dancing video'."New value: +"Optional goal or keyword to match, e.g. 'new hairstyle', 'dancing video'."
    • Changedopen_in_kavel1 field changed
      • changedInput schema / properties / tool / description
        Previous value: -"The tool slug from list_kavel_tools, e.g. 'ai-wedding-photo-generator'."New value: +"The tool slug from list_kavel_tools, e.g. 'ai-hairstyle-changer'."
  2. 4 tool updatesv0.1.0
    • First observedbuild_kavel_prompt
    • First observedlist_kavel_models
    • First observedlist_kavel_tools
    • First observedopen_in_kavel
Deploy Server
One endpoint for every MCP toolRayrun runs every MCP server behind one URL and holds the credentials. Each call is decided per client, tool, and argument, then recorded.ray.runAd

TDQS

A3.7/5.0

Scored across 4 tools

Disambiguation4/5

Each tool targets a distinct step: discovering tools (list_kavel_tools), listing underlying AI models (list_kavel_models), generating a tuned prompt (build_kavel_prompt), and getting a generator URL (open_in_kavel). The tools-vs-models pair could momentarily confuse, but descriptions clearly separate effects/generators from models.

Naming Consistency4/5

Names follow a verb_kavel_noun snake_case pattern (list_kavel_tools, build_kavel_prompt, list_kavel_models) with only open_in_kavel deviating slightly with a preposition. Conventions are consistent and readable.

Tool Count4/5

Four tools is on the lean side but well-matched to a focused discovery-and-prompt-helper server. Each tool earns its place with no redundancy.

Completeness4/5

The surface covers the full workflow: discover a tool, inspect available models, build a tuned prompt, and open the generator page. Minor gaps exist (no way to save/track generations), but core flows have no dead ends.

Maintenance

ActivityMaintained
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches