pixmax-mcp

Overview Schema Related Servers Score Discussions

Server Quality Checklist

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

Latest release: v0.2.0
Disambiguation4/5
Most tools have distinct purposes, but generate_image and generate_storyboard are described as nearly identical, differing only in node type. This overlap could cause confusion for an agent.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (e.g., generate_image, list_models, get_task). The only deviation is 'prompting_guide', which uses a gerund instead of a verb, but it is still clear.
Tool Count5/5
With 10 tools covering a broad range of generative model capabilities (image, video, text, 3D, audio) plus management functions, the count is well-scoped and not overwhelming.
Completeness4/5
The tool surface covers generation and monitoring for all advertised media types. Minor gaps include the lack of a cancel task or delete result tool, but core workflows are complete.
Average 4.1/5 across 10 of 10 tools scored. Lowest: 3/5.
See the Tool Scores section below for per-tool breakdowns.
- No community issues in the last 6 months
- 21 commits in the last 12 weeks
- No stable releases found
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI status not available
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

Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations provided, so description carries full burden. Only mentions it returns generated text, but fails to disclose cost, latency, error handling, or model-specific differences. Lacks behavioral context.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness3/5
Is the description appropriately sized, front-loaded, and free of redundancy?
Very concise single sentence, but at the expense of missing important details. Balanced conciseness with clarity, but could be restructured to front-load core action.
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 no output schema and limited annotations, the description lacks details on return format, streaming, or handling large outputs. Does not mention that output might be a string or JSON. Sibling tools like prompting_guide suggest more context exists elsewhere.
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 50%; the model parameter has a description with an example, which is helpful. The prompt parameter lacks description, and the tool description does not compensate. No output schema, so return format is unclear.
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 the tool runs a text/LLM model and lists specific model examples. It distinguishes from sibling tools like generate_image and generate_video by focusing on text generation.
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 on when to use this tool versus alternatives. Does not mention prerequisites, model selection criteria, or scenarios where other tools (e.g., prompting_guide) might be better suited.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior2/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must fully disclose behavioral traits. It only states the core function and limitation. Missing critical details such as async behavior (wait parameter), file saving requirement (save_to parameter), and URL expiration, which are crucial for correct usage.
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, no filler. All information is front-loaded and directly relevant. Every word serves a purpose.
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?
With 8 parameters and no output schema, the description is insufficient. It does not explain async behavior, parameter interactions, or output characteristics beyond the file format. The high schema coverage does not compensate for the lack of overarching guidance.
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 description coverage is 88%, meaning the schema provides adequate context for most parameters. The description does not add further parameter-level meaning beyond restating the format. Baseline score of 3 is appropriate given high coverage.
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 a 3D model (.glb) from a text prompt' with a specific verb, resource, and format. It explicitly distinguishes from image-to-3D, differentiating it from potential sibling tools such as generate_image.
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?
Description provides clear usage context: text-to-3D only, and explicitly rules out image-to-3D. However, it does not mention when to use this tool versus siblings like generate_image or generate_video, though the stated limitation provides implicit guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Without annotations, the description provides basic behavioral info (returns status, result URLs, cost upon completion) but lacks details on intermediate states, error handling, or rate limits. It does not contradict annotations since none exist.
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, concise sentence that front-loads the core purpose. No superfluous information is present.
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 polling tool with only two parameters and no output schema, the description is minimally adequate but omits details like possible status values, the role of save_to, and whether the tool blocks or returns immediately for incomplete tasks.
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 coverage is 50% with only save_to having a description. The tool description does not explain the purpose of either parameter (task_id or save_to) beyond what the schema already provides, failing to compensate for the missing 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?
The description clearly states it checks the status of a task started with wait=false and returns status, result URLs, and cost when complete. It distinguishes itself from sibling tools like generate_image and list_tasks by specifying the context of asynchronous task polling.
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 specifies when to use this tool (for tasks started with wait=false), but does not mention when not to use it or suggest alternatives like list_tasks for listing tasks.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior3/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. It discloses cost scaling with duration and mentions async via the `wait` parameter. However, it does not detail mutability, idempotency, failure behavior, or output format, leaving gaps for a tool with no annotations.
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 efficiently convey purpose, model support, a key parameter hint, and cost note. No wasted words, front-loaded, and easy to parse. Every sentence earns its place.
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?
With 7 parameters, no output schema, and no annotations, the description covers the main purpose, key constraints (duration snapping, lyrics for MiniMax Music), cost, and async behavior. It adequately prepares an agent to use the tool, though output format is implied but not explicit.
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 coverage is 100%, so baseline is 3. The description adds meaningful context: 'For MiniMax Music pass `lyrics`' and 'ElevenLabs Music requires this and only accepts 30 or 60 — auto-snapped to the nearer value.' It also explains the `wait` parameter behavior. This extra info improves parameter understanding.
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 speech or music' with specific models (ElevenLabs V2/V3/Music, MiniMax Speech/Music). This distinguishes it from sibling tools like generate_image or generate_video, providing a specific verb+resource pairing. It also notes cost scaling with duration, adding clarity.
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 gives a specific usage hint: 'For MiniMax Music pass `lyrics`' and mentions cost behavior. However, it lacks explicit guidance on when to use this tool versus siblings or scenarios to avoid. The context is clear but without alternatives or exclusions.
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 are provided, so the description carries full burden. It discloses ordering (newest first), fields returned, and implies read-only safety through use cases. Could mention it is read-only, but overall adequate.
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: first states what it does and returns, second provides use cases. Extremely concise, no filler, front-loaded with key information.
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?
Given no output schema, the description explains return fields (status, model, prompt, result URLs). With two parameters fully documented in the schema, and clear ordering, the description is 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.
Parameters3/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. The tool description does not add new meaning for parameters beyond the schema, though it provides context about what fields are returned.
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 uses a specific verb 'list' and resource 'Pixmax generation tasks', and distinguishes from siblings like 'get_task' (single task) and generation tools. Title 'List recent tasks' reinforces the purpose.
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 provides three clear use cases (recovering results, checking wait=false jobs, auditing activity), giving the agent context on when to invoke. However, it does not explicitly contrast with alternatives like 'get_task' for specific tasks.
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 and covers retry-on-failure, blocking behavior, reference image limits and cost, and style consistency. It omits some details like rate limits or auth requirements, but the provided info is substantial and honest.
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 six sentences, each providing distinct and valuable information. It front-loads the core action, then efficiently covers reference images, style, retry, and blocking. There is 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 complexity (11 parameters) and lack of output schema, the description covers the main functional aspects: models, reference images, style, retry, and return behavior. It does not detail output format beyond URLs or list all models, but the essential context for selection and invocation is present.
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 coverage is 100%, so baseline is 3. The description adds significant context beyond individual parameter descriptions, such as how reference_images are used (up to 14, free, guidance woven into prompt) and the role of style for visual coherence. This enhances understanding of parameter interactions.
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 explicitly states 'Generate an image' with a specific set of models, clearly distinguishing it from sibling generation tools for video, 3D, audio, etc. It also mentions use cases like image-to-image and character consistency, making the purpose unambiguous.
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 explains when to use the tool (image generation with Pixmax models) and describes key behaviors like blocking or returning a task ID. However, it does not explicitly exclude alternatives or compare with other image generators, but the sibling tools are different modalities, so the context is 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 the description carries the full burden. It discloses pricing, single-image output, reference_images for consistency, and the node type classification. However, the claim of 'single-image output' conflicts with the 'count' parameter (max 4), creating ambiguity about panel behavior.
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 concise sentences that front-load the purpose and key distinction. Every sentence provides essential information without redundancy.
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?
Despite no output schema, the description fails to clarify the inconsistency between 'single-image output' and the 'count' parameter allowing up to 4 panels. This creates confusion about what the tool actually returns when count > 1, making it incomplete for agent reasoning.
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 coverage is 100%, providing baseline 3. The description adds meaning beyond the schema: explains 'wait' default and task-ID behavior, 'count' billing, 'model' examples, and 'reference_images' structure with fields like role/strength. This adds value over the schema alone.
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 generates an image via a specific node type (GENERATE_STORYBOARD) and explains it is identical to generate_image, distinguishing it by classification. This provides a specific verb+resource and differentiates from a sibling tool.
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 advises to use generate_image unless downstream requires the GENERATE_STORYBOARD classification. This gives clear when-to-use and when-not-to-use guidance, with an alternative specified.
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 the tool returns a list with cost and capacity, and when model is specified, returns prompting guidance. However, it does not mention pagination, rate limits, or authentication requirements. For a read-only list tool, this is adequate but not exhaustive.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Conciseness5/5
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, each with a clear purpose: main function, usage guidance, and alternate mode. It is front-loaded with the primary action, and no extraneous information is present.
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 no output schema, the description does a good job explaining the content of the list (type, cost, capacity) and the alternative output for model parameter. It could be slightly more complete by noting the output format (e.g., list of objects), but the core information is present.
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 description coverage is 100% and the description essentially restates what the schema says for both parameters. For model, it repeats 'returns that one model's full prompting + reference guide instead of the list' which is already in the schema. No new semantic information is added beyond the structured definitions.
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 lists models with type, credit cost, and reference capacity. It also explains the dual behavior when model parameter is given, returning full prompting guidance. This distinguishes it from sibling generation tools by positioning it as the first call to discover model codes.
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?
The description explicitly says 'Call this first to discover exact model codes' and later 'Pass `model` to get one model's full prompting + reference guidance ... before generating.' This provides clear when-to-use guidance and implies it should precede generation tools.
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?
Despite no annotations, the description clearly indicates it's a retrieval tool (get rules) and reveals behavioral traits like inferring category from model and appending model-specific tips. Could explicitly state it's read-only.
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, each purposeful. First defines tool contents, second gives usage and a cautionary example. No wasted words, front-loaded with key info.
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?
Given no output schema, the description adequately conveys return value (rules, tips, failure modes). Both parameters detailed, usage guidance provided, and complexity is low. Sufficient for agent to select and invoke.
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 covers both parameters completely. Description adds value by explaining model infers category and appends specific tips, and category is the medium's playbook, beyond 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?
The description clearly states it retrieves prompting craft rules for a medium, including structure, vocabulary, references, and failure modes. It distinguishes itself from sibling generation tools by focusing on guidance before creation.
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?
Explicitly advises calling before writing prompts for unfamiliar mediums or models, with a concrete example of video pitfalls. Lacks explicit when-not-to-use but provides strong contextual guidance.
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 full burden. It discloses async behavior (wait=false returns task id), duration constraints (8s, 6s/10s), and model-specific features. Missing details on rate limits, error responses, or cost implications, but key behaviors are well covered.
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 lengthy but front-loaded with main purpose and model list. Every sentence adds value: model scope, image-to-video, multimodal options, duration, async. Could be slightly more concise, but structure is logical and information-dense.
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?
Given 16 parameters, no output schema, and no annotations, the description covers all crucial aspects: model support, image-to-video, keyframe control, multimodal references, async behavior, model-specific durations. Missing error handling or output format, but overall highly complete for a complex tool.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters5/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 88%, but description adds significant meaning beyond schema: explains image+last_frame as start+end keyframe interpolation, Seedance 2 multimodal references, wait parameter async behavior, and resolution constraints. This substantially aids correct parameter usage.
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?
Clearly states it generates a video with a Pixmax model, lists multiple supported models, and distinguishes from sibling tools like generate_image and generate_audio. The verb 'generate' plus resource 'video' with specific model context makes the purpose unmistakable.
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 guidance on when to use image, last_frame, reference_videos, reference_audio, and wait parameters. Differentiates between Seedance 2 multimodal capabilities and other models. Includes duration notes for Veo and Hailuo. No explicit 'when not to use', but the level of detail compensates.
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:

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

Score Badge

Copy to your README.md:

[![pixmax-mcp MCP server](https://glama.ai/mcp/servers/huikku/pixmax-mcp/badges/score.svg)](https://glama.ai/mcp/servers/huikku/pixmax-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/huikku/pixmax-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server