sanzaru

by TJC-LP

Overview Schema Related Servers Score Discussions

Python

Hybrid

Server Quality Checklist

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

Latest release: v0.10.0
Disambiguation5/5
Each tool has a clearly distinct purpose: create/remix/status/download/delete/list remote/list local/view. The internal _get_media_data tool is explicitly marked as 'do not call directly,' and its relationship to view_media is clearly explained, eliminating potential confusion.
Naming Consistency4/5
Tool names follow a consistent verb_noun pattern (create_video, delete_video, download_video, list_videos, view_media). Minor deviations include get_video_status (three-part), list_local_videos (adjective), and the underscore-prefixed _get_media_data, but these are readable and the pattern is predictable overall.
Tool Count5/5
With 9 tools, the server is well-scoped for video generation and management. Each tool addresses a distinct step in the workflow (create, remix, status, download, delete, list remote/local, view), and the count feels appropriate without redundancy or bloat.
Completeness3/5
Core video lifecycle is covered (create, remix, status, download, delete, list). However, create_video and view_media reference list_reference_images and list_audio_files, but these tools are not provided, creating dead ends for workflows involving reference images or audio media. This is a notable gap in the tool surface.
Average 4.6/5 across 9 of 9 tools scored.
See the Tool Scores section below for per-tool breakdowns.
- 16 of 17 community issues answered or closed in the last 6 months
- 45 commits in the last 12 weeks
- Last stable release on August 14, 2026
- No critical vulnerability alerts
- No high-severity vulnerability alerts
- No code scanning findings
- CI is passing
This repository is licensed under MIT License.
This repository includes a README.md file.
No tool usage detected in the last 30 days. Usage tracking helps demonstrate server value.
Tip: use the "Try in Browser" feature on the server page to seed initial usage.
Add a glama.json file to provide metadata about your server.
If you are the author, simply .
If the server belongs to an organization, first add glama.json to the root of your repository:
```
{
  "$schema": "https://glama.ai/mcp/schemas/server.json",
  "maintainers": [
    "your-github-username"
  ]
}
```
Then . Browse examples.
Add related servers to improve discoverability.

How to sync the server with GitHub?

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

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

How is the quality score calculated?

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

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

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

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

Tool Scores

Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description adds significant behavioral context beyond the annotations: it warns 'WARNING: This is permanent and cannot be undone!', clarifies it does not delete local files, and specifies the return value ('confirmation with the deleted video_id and deleted=true'). The annotations (destructiveHint=true, readOnlyHint=false) are consistent and the description enriches them.
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 well-structured with a strong opening statement, a warning, bulleted use cases, parameter info, and return info. It is slightly longer than necessary but each section earns its place, and the structure improves scannability.
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?
For a simple delete tool with one parameter, the description covers the core purpose, usage guidelines, a critical warning, parameter explanation, and return value. It could mention idempotency (calling delete twice) or how to source the video_id, but the annotations and return statement cover much of the necessary context.
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 has only one parameter (video_id) with no description, so coverage is 0%. The description simply repeats the parameter name ('The ID of the video to delete') without adding details on how to obtain the ID, its format, or relationship to other tools like list_videos. Thus it adds minimal value beyond the schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the action: 'Permanently delete a video from OpenAI's cloud storage.' It uses a specific verb (delete) and resource (video), and distinguishes itself from local-file operations by mentioning download_video and clarifying it does not delete local files.
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 explicit use cases ('Clean up test videos', 'Remove unwanted content', 'Free up storage quota') and a when-not ('This does NOT delete any local files you may have downloaded with download_video'). It does not explicitly name an alternative tool for local deletion, but provides clear context.
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?
Annotations already declare readOnlyHint=true, establishing the safety profile. The description adds valuable behavioral context by specifying that data is fetched in base64-encoded chunks, which goes beyond the annotation. It does not detail chunking mechanics or offset semantics, but this is acceptable for an internal tool explicitly not meant for direct use.
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, front-loaded with the core purpose, and every word earns its place. It is highly concise without sacrificing necessary guidance on usage.
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?
Given that this is an internal tool with a clear directive to use view_media instead, the description conveys enough to prevent misuse. However, it lacks parameter documentation and any return structure information, making it incomplete for scenarios where an agent might need to understand the tool in detail (e.g., debugging). The strong guidance to avoid direct use mitigates this, justifying a mid-range score.
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?
With schema description coverage at 0%, the description was expected to compensate by explaining parameters. It mentions 'chunks' and 'base64-encoded', weakly implying chunk_size and offset, but does not explicitly define any of the four parameters (offset, filename, chunk_size, media_type). This leaves the agent without sufficient understanding of required inputs.
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 function: 'fetch base64-encoded chunks of media data'. It identifies the specific resource (media data) and the output format (base64 chunks), and explicitly distinguishes itself as an internal tool from the sibling tool 'view_media' which serves as the public interface.
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 provides explicit usage guidance: 'Do not call directly — use view_media instead.' This tells the agent when not to use the tool and directs them to the correct alternative, fully satisfying the dimension.
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?
Annotations already mark this as read-only, and the description adds behavioral detail: it scans VIDEO_PATH, applies defaults (sort_by=modified, order=desc, limit=50), and returns specific VideoFile fields. No contradiction with annotations.
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 well-structured with a summary line, use-case paragraph, parameter list, return type, and example workflow. Minor redundancy exists between the first and second sentences, but overall every section earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, the description specifies return fields (filename, size_bytes, modified_timestamp, file_type), defaults, and an end-to-end workflow. This is sufficient for an agent to invoke the tool correctly and interpret results.
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 0%, but the description provides a full parameter section explaining all 5 params: pattern with glob examples, file_type enum values, sort_by options, order semantics, and limit default. This fully compensates for the schema's lack of 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 opens with a specific verb+resource: 'List locally downloaded video files' and further scopes to the VIDEO_PATH directory. It clearly distinguishes from sibling list_videos by emphasizing 'locally downloaded' and referencing download_video.
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?
It states when to use: to discover files previously downloaded with download_video, and gives an example workflow chaining to view_media. It doesn't explicitly name list_videos as the alternative for non-local videos, but the local vs. remote distinction is implied.
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?
Annotations already declare readOnlyHint=true, and the description adds behavior details such as 'renders it with native playback controls' and 'Returns metadata: filename, media_type, size_bytes, mime_type.' This provides useful context beyond the annotation without contradicting it.
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 well-structured with a clear opening summary, parameter details, discovery guidance, and return metadata. Each sentence contributes useful information, and the format is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers tool purpose, parameter semantics, discovery steps, and return metadata. For a simple read-only media viewer with no output schema, this is nearly complete. It doesn't mention error handling or absolute paths, but those are minor gaps given the straightforward nature.
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?
With 0% schema description coverage, the description fully compensates by explaining both parameters. It clarifies media_type enum values and gives directory guidance for filename ('video files are in the videos directory', etc.), adding meaning the schema completely lacks.
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 'Open a media file in the interactive media viewer' and specifies that it handles video, audio, and image playback. This distinguishes it from sibling tools like delete_video, create_video, and remix_video, which are obviously different operations.
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 tells users to use list_videos, list_reference_images, or list_audio_files to discover available files, which implies this tool is for viewing existing media. While it doesn't explicitly contrast with alternatives like download_video, the intended use case is clear and well-contextualized.
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?
Annotations already declare readOnlyHint=true and openWorldHint=true, lowering the bar. The description adds meaningful context: polling cadence, the status enum values, a progress field, and the contents of the returned Video object. It doesn't cover rate limits or error/failure details beyond status='failed', but provides solid additional behavioral transparency.
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 slightly longer than the absolute minimum, but it is well-structured with a clear first sentence, a usage note, a return object breakdown, and a workflow. Every sentence adds value, and the bullet-like list in the workflow makes it easy to scan. A 5 would require even tighter wording while preserving all this useful content.
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 that there is no output schema, the description fully explains the return values (status, progress, id, other metadata), the status enum, and the polling workflow. It also covers the tool's role in the broader lifecycle, making it complete enough for an agent to use correctly without external docs.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 0%, so the description must compensate. It explains that video_id comes from create_video/remix_video and is used in the polling workflow, and also mentions it appears in the returned Video object as 'id'. This gives enough meaning beyond the schema's 'Video Id' label, though it doesn't explicitly format or validate the parameter.
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 the tool checks 'status and progress of a video generation job', which is a specific verb+resource combination. It clearly distinguishes this from sibling tools like create_video, remix_video, and download_video by focusing on the polling/status aspect.
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 to use this after calling create_video or remix_video, provides polling frequency ('every 5-10 seconds'), and outlines a typical workflow with steps. This gives clear when-to-use context and differentiates from alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Adds valuable behavioral context beyond the annotations: the side effect of saving to VIDEO_PATH, the failure condition if the video isn't completed, and the return format (filename, variant). This goes beyond the readOnly/idempotent 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 well-structured with a clear opening, warnings, parameter explanations, and a numbered workflow. Every section earns its place, and the information is easy to scan.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Despite no output schema, it explains the return value (DownloadResult with filename, variant) and provides a full workflow. It also covers the key precondition and file destination. The description is complete for this tool's complexity.
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 description coverage is 0%, but the description compensates by explaining every parameter in detail: video_id's source, filename's default behavior, and all variant enum values with their meanings. This adds significant meaning beyond the bare 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 opens with a specific verb and resource: 'Download a completed video to disk.' It clearly distinguishes this tool from siblings like view_media (preview) and list_videos (listing) by specifying the action and output (file on disk).
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?
It provides explicit when-to-use conditions ('Only call this AFTER get_video_status shows status=completed') and a typical workflow. However, it does not explicitly name alternative tools for related tasks (e.g., view_media for preview), so it lacks explicit alternatives.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description goes well beyond the readOnlyHint annotation by disclosing the pagination mechanism (passing 'after' from 'last'), the exact response fields (id, status, progress, etc.), and the iteration pattern with 'has_more' and 'last'. This richly describes the tool's behavior without contradicting the 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?
The description is well-structured with a clear opening line, a 'Returns' section, parameter explanations, and a pagination example. Every sentence contributes useful information, and the format makes it easy to scan. It is appropriately sized for the tool's complexity.
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 there is no output schema, the description thoroughly covers what the tool returns (data, has_more, last) and how to paginate through results. It also mentions the included statuses and model fields, making it complete for an agent to understand and invoke the tool correctly.
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?
Despite 0% schema description coverage, the description fully compensates by explaining each parameter: 'limit' with default/max, 'after' as the pagination cursor from the previous response, and 'order' with its enum values. It also provides a concrete pagination example that demonstrates how to use these parameters together.
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 opens with 'List all video jobs in your OpenAI account,' which uses a specific verb ('List') and resource ('video jobs in your OpenAI account'), clearly distinguishing it from the sibling tool 'list_local_videos' by explicitly referencing the account scope. It also mentions pagination support, which is a key functional differentiator.
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 clearly states its purpose and provides detailed usage context for pagination, but it does not explicitly mention when to avoid this tool or which sibling tool to use instead (e.g., 'for local videos, use list_local_videos'). The phrase 'in your OpenAI account' implies the scope, but lacks an explicit contrast or alternative recommendation.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The description fully discloses the async nature, immediate return, status progression, and the fact that seconds must be a string not integer. It adds substantial behavioral context beyond the minimal annotations (readOnlyHint=false, destructiveHint=false), making the tool's behavior transparent.
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 well-organized with sections for async behavior, status flow, and parameter details. It is front-loaded with the most critical info (async, immediate return) and every sentence adds value without redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness5/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
All five parameters are explained, return fields are listed, and the async lifecycle is fully described. The absence of an output schema is compensated by explicitly stating the returned Video object fields. The description is complete for a tool of this complexity.
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?
With 0% schema_description_coverage, the description compensates fully by detailing each parameter: prompt, model choices, seconds as string with exact values, size options, and input_reference_filename usage. It also explains defaults and the requirement to match image size and format.
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 creates a new Sora video generation job and returns a video_id. It distinguishes from siblings by mentioning async behavior and direct the user to get_video_status and download_video for follow-up actions.
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?
It explicitly instructs when to use related tools: poll with get_video_status, download with download_video, and find reference images with list_reference_images. This provides clear context and alternative tool usage, exceeding a simple 'when to use this tool'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations indicate this is not read-only (readOnlyHint=false) and not destructive (destructiveHint=false), the description adds substantial behavioral detail: it returns immediately with a new queued job, is not instantaneous, and returns a new Video object with status='queued' and progress=0. This goes far beyond what annotations convey.
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 well-structured and front-loaded: a clear one-sentence summary, then a brief explanation of behavior, a Parameters bullet list, a return-value note, and a numbered workflow. Each sentence adds value, and the format makes it easier for an agent to parse the 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?
The description is complete for a 2-parameter tool with no output schema. It covers the purpose, the lifecycle (polling, new ID), prerequisites (completed original), return status, and a step-by-step workflow. No critical information is missing for an AI agent to correctly invoke and integrate this 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?
The input schema offers no descriptions, and schema description coverage is 0%. The description compensates fully with a Parameters section that explicitly explains each parameter: previous_video_id is the ID of the completed video to use as a base (required), and prompt is the new text prompt to guide the remix (required).
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 first sentence states the exact purpose: 'Create a NEW video by remixing an existing completed video with a different prompt.' It clearly distinguishes this from siblings like create_video (new from scratch) and get_video_status (polling), and highlights the key aspect of generating a new video_id.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Usage Guidelines5/5
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides explicit usage context, including the prerequisite that the original video must be completed, the need to poll the new video_id via get_video_status, and a detailed 5-step workflow with example calls. It explains when to use remix_video in relation to other tools in the pipeline.
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:

[![sanzaru MCP server](https://glama.ai/mcp/servers/TJC-LP/sanzaru/badges/card.svg)](https://glama.ai/mcp/servers/TJC-LP/sanzaru)

Score Badge

Copy to your README.md:

[![sanzaru MCP server](https://glama.ai/mcp/servers/TJC-LP/sanzaru/badges/score.svg)](https://glama.ai/mcp/servers/TJC-LP/sanzaru)

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/TJC-LP/sanzaru'

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