Skip to main content
Glama
enesjakozh
bobtista

mcp-luma-dream-machine

by bobtista
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

Servidor MCP de Luma AI 🎥

Un servidor de protocolo de contexto de modelo para la API Dream Machine de Luma AI.

Descripción general

Este servidor MCP se integra con la API Dream Machine (v1) de Luma AI para proporcionar herramientas que permiten generar, gestionar y manipular vídeos e imágenes generados por IA mediante Modelos de Lenguaje Grandes. Implementa el Protocolo de Contexto de Modelo (MCP) para facilitar la interacción fluida entre los asistentes de IA y las herramientas creativas de Luma.

Related MCP server: mcp-media-engine

Características ✨

  • Generación de texto a vídeo

  • Generación avanzada de vídeo con fotogramas clave

  • Conversión de imagen a vídeo

  • Extensión e interpolación de vídeo

  • Generación de imágenes con imágenes de referencia

  • Adición de audio a los vídeos

  • Escalado de vídeo

  • Gestión de crédito

  • Seguimiento de generación y verificación de estado

Herramientas 🛠️

  1. ping

    • Comprueba si la API de Luma se está ejecutando

    • No se requieren parámetros

  2. create_generation

    • Crea una nueva generación de vídeo.

    • Aporte:

      • prompt (cadena, obligatorio): Descripción de texto del video a generar

      • model (cadena, opcional): Modelo a utilizar (predeterminado: "ray-2")

        • Modelos disponibles: "ray-1-6", "ray-2", "ray-flash-2"

      • resolution (cadena, opcional): Resolución de vídeo (opciones: "540p", "720p", "1080p", "4k")

      • duration (cadena, opcional): duración del vídeo (actualmente solo se admiten "5 s" y "9 s")

      • aspect_ratio (cadena, opcional): Relación de aspecto del vídeo (p. ej., "16:9", "1:1", "9:16", "4:3", "3:4", "21:9", "9:21")

      • loop (booleano, opcional): si se debe hacer un bucle del video

      • keyframes (objeto, opcional): fotogramas de inicio y fin para la generación avanzada de vídeo:

        • frame0 y/o frame1 con:

          • {"type": "image", "url": "image_url"} para fotogramas clave de imagen

          • {"type": "generation", "id": "generation_id"} para fotogramas clave de vídeo

  3. get_generation

    • Obtiene el estado de una generación.

    • Aporte:

      • generation_id (cadena, obligatoria): ID de la generación a comprobar

    • La salida incluye:

      • ID de generación

      • Estado (en cola, soñando, completado, fallido)

      • Motivo del fallo (si falló)

      • URL del vídeo (si se completó)

  4. list_generations

    • Enumera todas las generaciones

    • Aporte:

      • limit (número, opcional): número máximo de generaciones a devolver (predeterminado: 10)

      • offset (número, opcional): Número de generaciones a omitir

  5. delete_generation

    • Elimina una generación

    • Aporte:

      • generation_id (cadena, obligatoria): ID de la generación a eliminar

  6. upscale_generation

    • Aumenta la resolución de una generación de vídeo

    • Aporte:

      • generation_id (cadena, obligatoria): ID de la generación a escalar

      • resolution (cadena, obligatoria): Resolución de destino para el video ampliado (una de "540p", "720p", "1080p" o "4k")

    • Nota:

      • La generación debe estar en un estado completo para poder ser ampliada.

      • La resolución de destino debe ser mayor que la resolución de la generación original.

      • Cada generación solo se puede ampliar una vez

  7. add_audio

    • Agrega audio generado por IA a una generación de video.

    • Aporte:

      • generation_id (obligatorio): El ID de la generación a la que se agregará audio

      • prompt (obligatorio): El mensaje para la generación de audio

      • negative_prompt (opcional): el mensaje negativo para la generación de audio

      • callback_url (opcional): URL para notificar cuando se completa el procesamiento del audio

  8. generate_image

    • Genera una imagen a partir de un mensaje de texto con imágenes de referencia opcionales.

    • Aporte:

      • prompt (cadena, obligatorio): Descripción de texto de la imagen a generar

      • model (cadena, opcional): Modelo a utilizar para la generación de imágenes (predeterminado: "photon-1")

        • Modelos disponibles: "photon-1", "photon-flash-1"

      • aspect_ratio (cadena, opcional): relación de aspecto de la imagen (las mismas opciones que el vídeo)

      • image_ref (matriz, opcional): Imágenes de referencia para guiar la generación

        • Cada referencia: {"url": "image_url", "weight": optional_float}

      • style_ref (matriz, opcional): imágenes de referencia de estilo

        • Cada referencia: {"url": "image_url", "weight": optional_float}

      • character_ref (objeto, opcional): Imágenes de referencia de personajes

        • Formato: {"identity_name": {"images": ["url1", "url2", ...]}}

      • modify_image_ref (objeto, opcional): Imagen a modificar

        • Formato: {"url": "image_url", "weight": optional_float}

  9. get_credits

    • Obtiene información de crédito del usuario actual

    • No se requieren parámetros

    • Devuelve el saldo de crédito disponible en centavos de USD

  10. get_camera_motions

  • Obtiene todos los movimientos de cámara admitidos

  • No se requieren parámetros

  • Devuelve: Lista de cadenas de movimiento de cámara disponibles

Configuración para Claude Desktop 🖥️

  1. Obtén tu clave API de Luma de Luma AI (regístrate o inicia sesión para obtener tu clave API)

  2. Agregue esto a su archivo de configuración de Claude Desktop:

    • En macOS: ~/Library/Application Support/Claude/claude_desktop_config.json

    • En Windows: %APPDATA%\Claude\claude_desktop_config.json

    {
  "mcpServers": {
    "luma": {
      "command": "uv",
      "args": [
        "run",
        "--project",
        "/path/to/your/luma-ai-mcp-server",
        "-m",
        "luma_ai_mcp_server"
      ],
      "env": {
        "LUMA_API_KEY": "your-luma-api-key-here"
      }
    }
  }
}

    Reemplazar:

    • /path/to/your/luma-ai-mcp-server con la ruta real al directorio de su servidor

    • your-luma-api-key-here con su clave API de Luma real

  3. Reiniciar Claude Desktop

  4. ¡Listo! Ya puedes usar las herramientas de IA de Luma directamente en las conversaciones de Claude Desktop.

Solución rápida de problemas 🛠️

Si tienes problemas:

  1. Comprueba que tu clave API sea correcta

  2. Asegúrese de que la ruta al servidor sea correcta

  3. Ver registros con: tail -n 20 -f ~/Library/Logs/Claude/mcp*.log

Tipos avanzados de generación de vídeo 🎬

La API de Luma admite varios tipos de generación de vídeo avanzada a través de fotogramas clave:

  1. A partir de una imagen : proporcione frame0 con type: "image" y una URL de imagen

  2. Terminar con una imagen : proporcione frame1 con type: "image" y una URL de imagen

  3. Ampliación de un vídeo : proporcione frame0 con type: "generation" y un ID de generación

  4. Extensión inversa de un video : proporcione frame1 con type: "generation" y un ID de generación

  5. Interpolación entre vídeos : proporcione tanto frame0 como frame1 con type: "generation" e ID de generación

Limitaciones y notas de la API 📝

  • Duración : Actualmente, la API solo admite duraciones de "5 s" o "9 s".

  • Resolución : Los valores válidos son "540p", "720p", "1080p" y "4k".

  • Modelos :

    • Generación de vídeo:

      • "ray-2" (predeterminado): mejor calidad, más lento

      • "ray-flash-2": Generación más rápida

      • "ray-1-6" - Modelo heredado

    • Generación de imágenes:

      • "photon-1" (predeterminado): mejor calidad, más lento

      • "photon-flash-1": Generación más rápida

  • Tipos de generación : Vídeo, imagen y avanzado (con fotogramas clave)

  • Relaciones de aspecto : "1:1" (cuadrado), "16:9" (horizontal), "9:16" (vertical), "4:3" (estándar), "3:4" (vertical estándar), "21:9" (ultraancho), "9:21" (ultraancho vertical)

  • Estados : "en cola", "soñando", "completado", "fallido"

  • Ampliación de escala :

    • Las generaciones de video solo se pueden ampliar cuando están en un estado "completo"

    • La resolución del objetivo debe ser mayor que la resolución de la generación original

    • Cada generación solo se puede ampliar una vez

  • Clave API : requerida en las variables de entorno

  • Versión de API : utiliza Dream Machine API v1

Licencia 📄

Instituto Tecnológico de Massachusetts (MIT)

Available Tools

10 tools
add_audioC

Adds audio to a video generation

ParametersJSON Schema
NameRequiredDescriptionDefault
generation_idYes
promptYes
negative_promptNo
callback_urlNo

TDQS

C2.4/5.0
Behavior2/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It states the action ('adds audio') but doesn't describe key traits: whether this is a mutation (likely, given 'adds'), what permissions or credits might be required, if it's asynchronous (hinted by 'callback_url' but not explained), or what happens on failure. This leaves significant gaps for a tool with 4 parameters and no output schema.

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?

The description is a single, efficient sentence that gets straight to the point without fluff. It's appropriately sized for a simple action, though it could be more front-loaded with key details. No wasted words, but it risks under-specification due to brevity.

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

Completeness2/5

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

Given the complexity (a mutation tool with 4 parameters, 0% schema coverage, no annotations, and no output schema), the description is incomplete. It doesn't explain the tool's behavior, parameter roles, or expected outcomes, making it inadequate for an AI agent to use correctly without guesswork. More context is needed to compensate for the lack of structured data.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate for undocumented parameters. It mentions 'audio' and 'video generation' but doesn't explain any parameters: e.g., what 'generation_id' refers to, how 'prompt' relates to audio generation, the purpose of 'negative_prompt' or 'callback_url'. This adds minimal meaning beyond the schema's basic titles, failing to address the coverage gap.

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

Purpose3/5

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

The description 'Adds audio to a video generation' states the basic action (add audio) and resource (video generation), but it's vague about what this entails—does it generate audio from a prompt, upload existing audio, or something else? It distinguishes from siblings like 'create_generation' or 'upscale_generation' by focusing on audio addition, but lacks specificity on the verb's mechanism.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. For example, it doesn't clarify if this is for adding audio to an existing video generation (implied by 'generation_id') or how it relates to other tools like 'create_generation'. There's no mention of prerequisites, exclusions, or typical workflows, leaving usage context unclear.

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

create_generationC

Creates a new video generation from text, image, or existing video

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes
modelNoray-2
resolutionNo
durationNo
aspect_ratioNo
loopNo
keyframesNo
callback_urlNo

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden but only states the basic action without disclosing behavioral traits. It lacks information on permissions, rate limits, whether it's asynchronous (suggested by 'callback_url' parameter), or what happens upon creation, leaving significant gaps.

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 directly states the tool's purpose without unnecessary words. It's appropriately sized and front-loaded, with every word contributing to clarity, making it highly concise.

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

Completeness2/5

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

Given the complexity (8 parameters, no annotations, no output schema), the description is insufficient. It doesn't explain the creation process, output format, error handling, or how parameters interact, leaving the agent with inadequate context for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions input types (text, image, video) but doesn't explain how they map to parameters like 'prompt' or 'keyframes', failing to provide meaningful semantics beyond the schema.

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 clearly states the action ('creates') and resource ('new video generation'), specifying it can be created from text, image, or existing video. However, it doesn't differentiate from sibling tools like 'generate_image' or 'upscale_generation' which also create visual content, missing explicit distinction.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives like 'generate_image' for images or 'upscale_generation' for enhancements. The description implies creation but offers no context on prerequisites, timing, or exclusions, leaving usage ambiguous.

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

delete_generationC

Deletes a generation

ParametersJSON Schema
NameRequiredDescriptionDefault
generation_idYes

TDQS

C2/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states the action ('Deletes') but fails to describe critical traits such as whether deletion is permanent, requires specific permissions, has side effects (e.g., affecting credits), or provides confirmation feedback. This is inadequate for a mutation tool with zero annotation coverage.

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 a single sentence, 'Deletes a generation', which is front-loaded and wastes no words. However, this conciseness comes at the cost of under-specification, but structurally it is efficient.

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

Completeness1/5

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

Given the complexity of a deletion operation, lack of annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It does not address behavioral risks, parameter details, or expected outcomes, making it insufficient for safe and effective tool invocation.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, and the description does not add any meaning beyond the schema. It does not explain what 'generation_id' represents, its format, or how to obtain it, leaving the single required parameter undocumented. This fails to compensate for the low schema coverage.

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

Purpose2/5

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

The description 'Deletes a generation' restates the tool name 'delete_generation' with minimal elaboration, making it tautological. While it specifies the resource ('generation'), it lacks detail about what a 'generation' represents in this context or how this deletion differs from other operations on generations.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives. It does not mention prerequisites (e.g., needing an existing generation), exclusions, or comparisons to sibling tools like 'create_generation', 'get_generation', or 'upscale_generation', leaving the agent without context for selection.

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

generate_imageC

Generates an image from a text prompt

ParametersJSON Schema
NameRequiredDescriptionDefault
promptYes
modelNophoton-1
aspect_ratioNo
callback_urlNo
image_refNo
style_refNo
character_refNo
modify_image_refNo

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. It only states the basic function without mentioning any behavioral traits: no information about rate limits, authentication requirements, whether it's a synchronous or asynchronous operation, what happens on failure, or what the output format looks like. For a complex tool with 8 parameters, this is a significant gap.

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 at just 6 words: 'Generates an image from a text prompt'. It's front-loaded with the core purpose and contains no unnecessary words. However, this conciseness comes at the cost of completeness for such a complex tool.

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

Completeness1/5

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

Given the complexity (8 parameters, 0% schema coverage, no annotations, no output schema), the description is completely inadequate. It doesn't explain what the tool returns, how to interpret results, error conditions, or the purpose of most parameters. For an image generation tool with multiple advanced features like style references and character references, this minimal description fails to provide necessary context.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, meaning none of the 8 parameters have descriptions in the schema. The tool description provides no information about any parameters beyond the required 'prompt' field. It doesn't explain what 'model', 'aspect_ratio', 'callback_url', 'image_ref', 'style_ref', 'character_ref', or 'modify_image_ref' do or when to use them. This leaves most parameters completely undocumented.

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 clearly states the tool's purpose: 'Generates an image from a text prompt'. It specifies the verb ('generates'), resource ('image'), and input source ('text prompt'). However, it doesn't differentiate from sibling tools like 'create_generation' or 'upscale_generation', which might have overlapping functionality in image generation workflows.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention sibling tools like 'create_generation' (which might be for video) or 'upscale_generation' (which might enhance existing images). There's no context about prerequisites, limitations, or typical use cases for this specific image generation tool.

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

get_camera_motionsB

Gets all supported camera motions

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'Gets' data, implying a read operation, but doesn't specify if it's safe, requires authentication, has rate limits, or what the return format might be. This leaves significant behavioral gaps for a tool with zero annotation coverage.

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 with no wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly.

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

Completeness2/5

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

Given the complexity (a read operation with no parameters) and lack of annotations or output schema, the description is incomplete. It doesn't explain what 'camera motions' are in this context, what the return data looks like, or any behavioral traits, leaving the agent with insufficient context for effective use.

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 0 parameters, and the schema description coverage is 100% (though empty). The description adds no parameter information, which is appropriate here. A baseline of 4 is given for zero-parameter tools, as there's nothing to compensate for.

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 clearly states the verb ('Gets') and resource ('all supported camera motions'), making the purpose immediately understandable. It doesn't distinguish from siblings (like 'get_generation' or 'list_generations'), but it's specific enough to understand what it retrieves.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context for camera motions, or how it differs from other 'get' or 'list' tools in the sibling set, leaving the agent with no usage direction.

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

get_creditsB

Gets credit information for the current user

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states it 'gets' information, implying a read-only operation, but doesn't clarify aspects like authentication needs, rate limits, error conditions, or what 'credit information' entails (e.g., balance, history). This leaves significant gaps for a tool with no structured safety hints.

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, clear sentence that directly states the tool's function without any wasted words. It's appropriately sized and front-loaded, making it easy to parse quickly.

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

Completeness2/5

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

Given the tool's simplicity (0 parameters, no output schema) and lack of annotations, the description is minimal. It doesn't explain what 'credit information' includes (e.g., format, units) or behavioral traits like response structure, which could be helpful for an agent to interpret results effectively.

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 0 parameters, and schema description coverage is 100%, so there's no need for parameter details in the description. The description correctly avoids redundant parameter information, earning a high baseline score for this dimension.

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 clearly states the action ('gets') and resource ('credit information for the current user'), making the tool's purpose understandable. However, it doesn't differentiate from sibling tools like 'get_generation' or 'list_generations' in terms of what specific data it retrieves, preventing a perfect score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, context (e.g., after certain actions), or exclusions, leaving the agent with minimal usage cues beyond the tool name.

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

get_generationC

Gets the status of a generation

ParametersJSON Schema
NameRequiredDescriptionDefault
generation_idYes

TDQS

C2.6/5.0
Behavior2/5

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

With no annotations provided, the description carries the full burden of behavioral disclosure. It states this is a read operation ('Gets'), implying it's non-destructive, but doesn't cover other traits like authentication needs, rate limits, error handling, or what 'status' includes (e.g., progress, completion, errors). This leaves significant gaps for a tool that likely interacts with asynchronous processes.

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 with zero wasted words. It's front-loaded with the core action and resource, making it easy to parse quickly. Every word earns its place, though this conciseness comes at the cost of detail.

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

Completeness2/5

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

Given the complexity (likely checking status of an asynchronous generation process), no annotations, no output schema, and low parameter coverage, the description is incomplete. It doesn't explain what 'status' means, what the return values are, or how this fits into workflows with siblings like 'create_generation'. More context is needed for effective use.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema has 1 parameter with 0% description coverage, and the tool description adds no information about the 'generation_id' parameter. It doesn't explain what a generation_id is, how to obtain it, its format, or its relationship to other tools (e.g., from 'create_generation'). This fails to compensate for the schema's lack of documentation.

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

Purpose3/5

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

The description 'Gets the status of a generation' clearly states the verb ('Gets') and resource ('a generation'), but it's vague about what 'status' entails and doesn't differentiate from sibling tools like 'list_generations' or 'create_generation'. It's adequate but lacks specificity about the scope of information retrieved.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing a generation_id from a prior operation), exclusions, or comparisons to siblings like 'list_generations' for bulk retrieval or 'create_generation' for initiating processes.

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

list_generationsD

Lists all generations

ParametersJSON Schema
NameRequiredDescriptionDefault
limitNo
offsetNo

TDQS

D1.3/5.0
Behavior1/5

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

No annotations are provided, so the description carries the full burden of behavioral disclosure. It fails to mention that this is a read-only operation, how pagination works with 'limit' and 'offset', potential rate limits, or what the output format looks like. This leaves critical behavioral traits undisclosed.

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

Conciseness2/5

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

The description is overly concise to the point of under-specification. While it uses only two words, it does not front-load essential information or structure it effectively, as it omits key details needed for tool selection and usage, making it inefficient rather than appropriately concise.

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

Completeness1/5

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

Given the complexity of listing operations, lack of annotations, no output schema, and 0% schema description coverage, the description is completely inadequate. It does not address what 'generations' are, how results are returned, or any contextual details, leaving the agent with insufficient information.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters1/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema description coverage is 0%, and the description does not mention or explain the parameters 'limit' and 'offset'. It adds no meaning beyond the schema, failing to compensate for the lack of coverage, which is inadequate for a tool with 2 parameters.

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

Purpose2/5

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

The description 'Lists all generations' restates the tool name 'list_generations' with minimal elaboration, making it tautological. It specifies the verb 'lists' and resource 'generations' but lacks detail on what 'generations' refers to or how it differs from sibling tools like 'get_generation' or 'create_generation', leaving the purpose vague.

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

Usage Guidelines1/5

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

The description provides no guidance on when to use this tool versus alternatives such as 'get_generation' for a specific generation or 'create_generation' for creating new ones. There is no mention of context, prerequisites, or exclusions, making it misleading for an agent to select the correct tool.

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

pingB

Check if the Luma API is running

ParametersJSON Schema
NameRequiredDescriptionDefault

No parameters

TDQS

B3.1/5.0
Behavior2/5

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

With no annotations provided, the description carries full burden for behavioral disclosure. While 'Check' implies a read-only operation, it doesn't specify what 'running' means (e.g., returns status code, latency, version), whether it requires authentication, or what happens on failure. This leaves significant behavioral gaps for a tool with zero annotation coverage.

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, clear sentence with zero wasted words. It's perfectly front-loaded and communicates the essential purpose without unnecessary elaboration.

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

Completeness2/5

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

For a simple health-check tool with no parameters and no output schema, the description is minimally adequate but incomplete. It doesn't explain what the check returns (e.g., success/failure, status details) or how to interpret results, leaving the agent guessing about the tool's output behavior.

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 zero parameters with 100% schema description coverage, so the baseline is 4. The description appropriately doesn't waste space discussing parameters that don't exist, which is efficient and correct.

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 clearly states the tool's purpose as 'Check if the Luma API is running' with a specific verb ('Check') and target ('Luma API'), making it immediately understandable. However, it doesn't differentiate from sibling tools (which are unrelated to API status checks), so it doesn't reach the highest score.

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

Usage Guidelines2/5

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

The description provides no guidance on when to use this tool versus alternatives. It doesn't mention prerequisites, timing considerations, or how it relates to other tools in the server (like checking API status before attempting generation operations).

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

upscale_generationC

Upscales a video generation to higher resolution

ParametersJSON Schema
NameRequiredDescriptionDefault
generation_idYes
resolutionYes

TDQS

C2.8/5.0
Behavior2/5

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

With no annotations, the description carries full burden but only states the basic action. It doesn't disclose behavioral traits such as whether this is a mutation (likely), permissions required, rate limits, side effects, or what the output looks like (e.g., returns a new generation ID).

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 with zero waste. It's appropriately sized for a simple tool and front-loaded with the core action, making it easy to parse quickly.

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

Completeness2/5

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

For a mutation tool with 2 parameters, 0% schema coverage, no annotations, and no output schema, the description is incomplete. It lacks crucial context like output format, error conditions, or behavioral details, leaving significant gaps for an agent to use it correctly.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must compensate but adds no parameter details. It mentions 'higher resolution' but doesn't explain the 'resolution' enum values or what 'generation_id' refers to, leaving both parameters semantically unclear beyond the schema.

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 clearly states the action ('upscales') and resource ('a video generation'), specifying the purpose as increasing resolution. It doesn't differentiate from siblings like 'create_generation' or 'get_generation', but the verb+resource combination is unambiguous.

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

Usage Guidelines2/5

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

No guidance is provided on when to use this tool versus alternatives. It doesn't mention prerequisites (e.g., needing an existing generation), exclusions, or how it relates to siblings like 'create_generation' or 'get_generation'.

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. 10 tool updates
    • First observedadd_audio
    • First observedcreate_generation
    • First observeddelete_generation
    • First observedgenerate_image
    • First observedget_camera_motions
    • First observedget_credits
    • First observedget_generation
    • First observedlist_generations
    • First observedping
    • First observedupscale_generation
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

C2.8/5.0

Scored across 10 tools

Disambiguation4/5

Most tools have distinct purposes, but there is some potential overlap between 'create_generation' (for video from text/image/video) and 'generate_image' (for image from text), which could cause confusion about when to use each. Otherwise, tools like 'add_audio', 'upscale_generation', and 'get_camera_motions' are clearly differentiated.

Naming Consistency5/5

All tools follow a consistent verb_noun pattern with snake_case, such as 'create_generation', 'delete_generation', 'get_camera_motions', and 'upscale_generation'. The naming is predictable and uniform across the set.

Tool Count5/5

With 10 tools, the count is well-scoped for a video/image generation API. It covers core operations like creation, retrieval, listing, deletion, and enhancement, without being overwhelming or too sparse.

Completeness4/5

The toolset provides good coverage for video and image generation workflows, including CRUD operations for generations and additional features like audio addition and upscaling. A minor gap is the lack of tools for modifying existing generations (e.g., update or edit), but agents can work around this by recreating or upscaling.

Maintenance

ActivityInactive
ResponsivenessNo issues

Resources

Related MCP Connectors

Related MCP Servers

Appeared in Searches