x402-video MCP serverofficial
A
license-
qualityB
maintenanceEnables AI agents to generate videos by paying per call with USDC on Base via the x402 protocol, with no accounts or API keys required.
70
MIT
ffpipe — video conversion
by dev.ffpipe
Server Details
Convert any video to web-ready MP4, paid per job with x402 (USDC on Base) — no account or API key.
- Status
- Healthy
- Last Tested
- Transport
- Streamable HTTP
- URL
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
MCP client
Glama
MCP server
Full call logging
Every tool call is logged with complete inputs and outputs, so you can debug issues and audit what your agents are doing.
Tool access control
Enable or disable individual tools per connector, so you decide what your agents can and cannot do.
Managed credentials
Glama handles OAuth flows, token storage, and automatic rotation, so credentials never expire on your clients.
Usage analytics
See which tools your agents call, how often, and when, so you can understand usage patterns and catch anomalies.
100% free. Your data is private.
Tool Definition Quality
A4.6/5.0
Tool DescriptionsA
Average 4.5/5 across 3 of 3 tools scored.
Server CoherenceA
Disambiguation5/5
Each tool serves a distinct purpose: creating a conversion job, checking its status, and leaving feedback. There is no overlap or ambiguity between the three tools.
Naming Consistency5/5
All tool names follow a consistent verb_noun pattern (convert_video, get_job_status, leave_feedback), making the API predictable and easy to navigate.
Tool Count5/5
With 3 tools, the server is well-scoped for its purpose: conversion, status polling, and feedback. No unnecessary tools, and each one earns its place.
Completeness5/5
The core workflow (submit conversion, poll status, retrieve result via URL) is fully covered. Feedback covers peripheral needs, and there are no obvious missing operations for the stated scope.
Available Tools
3 toolsconvert_videoAInspect
Queue an asynchronous video conversion: fetches sourceUrl (or, with upload: true, waits for you to PUT the bytes to the returned uploadUrl), converts to MP4 scaled to fit maxWidth x maxHeight (defaults 1920x1080, cap 4096). Returns { jobId, status: "queued" | "awaiting_upload", statusUrl, uploadUrl?, uploadExpiresAt? } - poll with get_job_status (jobId + the t token from statusUrl) until finished/error. Download results within 24 hours. Paid: $0.05 USDC via x402 (base mainnet), or a convert-kind retryVoucher.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| upload | No | Set true to upload the bytes yourself instead of giving a sourceUrl (exactly one of the two). The paid result then returns status awaiting_upload plus uploadUrl and uploadExpiresAt: HTTP PUT the raw bytes to uploadUrl before the deadline (201 -> queued). You are charged at acceptance; an abandoned upload window errors with no refund, while a pipeline failure after your upload earns a retryVoucher. | |
| maxWidth | No | Max output width, default 1920 | |
| maxHeight | No | Max output height, default 1080 | |
| sourceUrl | No | https URL of the input media (<= 100 MiB). Fetched from datacenter IP ranges - prefer a presigned URL from storage you control; no IP literals, no localhost/.internal/.local. Provide EXACTLY ONE of sourceUrl or upload. | |
| retryVoucher | No | Retry-voucher credential (`uuid.hmac`) from a failed paid job's status - pays for this call instead of x402. Single use, kind-matched. |
Tool Definition Quality
A4.2/5.0
Behavior4/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no readOnly/destructive annotations, the description discloses key behaviors: async processing, sourceUrl fetch vs. manual upload, return payload, polling requirement, 24-hour download window, and payment via x402 or retryVoucher. It stops short of detailing error/refund edge cases, but those are covered in schema parameter descriptions.
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 dense, well-structured sentences that front-load the purpose and cover the essential details: input mode, conversion specs, return payload, polling, download window, and payment. Every sentence earns its place with no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Completeness4/5
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the tool's complexity (async, upload, payment, retryVoucher), the description covers the full workflow well: input selection, conversion parameters, return fields, polling, download timeout, and cost. It does not document failure responses, but the schema provides per-parameter error context, so this is a minor gap.
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 the baseline is 3. The description adds helpful context like defaults (1920x1080) and cap 4096 and clarifies the sourceUrl/upload exclusivity, but these details are already present in the schema, so the incremental value is limited.
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 'Queue an asynchronous video conversion' and specifies the conversion to MP4 scaled to fit maxWidth x maxHeight. It also distinguishes itself from siblings get_job_status (polling) and leave_feedback by focusing on the conversion action.
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 the asynchronous workflow and explicitly references get_job_status for polling, which helps the agent understand the follow-up step. However, it does not explicitly state when to use this tool versus alternatives or list exclusions beyond the sourceUrl/upload mutually-exclusive requirement.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_job_statusGet job status (free)AInspect
Free status lookup for a job accepted by convert_video. Requires the job's ownership token - the t query parameter of the statusUrl returned at acceptance (store the whole statusUrl; it cannot be regenerated). Status goes [awaiting_upload ->] queued -> finished | error; awaiting_upload jobs report uploadExpiresAt but NEVER the uploadUrl (that credential is handed out exactly once, in the acceptance result); finished jobs carry resultUrl/thumbnailUrl/durationMs (served by this gateway, free to re-download within 24 hours of completion; GET them following redirects); a failed charged job carries retryVoucher. A bad token and an unknown jobId both answer not_found, deliberately.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| jobId | Yes | Job id from the acceptance | |
| token | Yes | Ownership token - the `t` query parameter of statusUrl |
Tool Definition Quality
A4.6/5.0
Behavior5/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 richly discloses behaviors: token cannot be regenerated, status lifecycle, uploadUrl is only returned once, re-download window is 24 hours, failed jobs carry retryVoucher, and deliberately identical not_found responses for bad tokens and unknown jobIds. This goes far beyond basic expectations.
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 dense and front-loaded with the primary purpose. Every sentence conveys essential operational or security information, though the length is substantial. It is not bloated, but it requires careful reading; a 5 would be reserved for a more compact wording with equal completeness.
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?
With no output schema, the description fully explains return behavior: state transitions, which fields appear per state, credential handling for uploadUrl, re-download limits, and error semantics. This is comprehensive for a status-lookup tool and leaves no obvious gaps for an agent to misjudge the tool's outputs or side effects.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, providing basic definitions for jobId and token. The description adds significant meaning beyond schema, especially for token: it clarifies the token is the `t` parameter from statusUrl, must be stored, and cannot be regenerated. This contextual layer is valuable for correct parameter handling.
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: 'Free status lookup for a job accepted by convert_video.' This clearly distinguishes the tool from siblings convert_video and leave_feedback, stating exactly what the tool does—checking job status—and its scope.
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 implies when to use the tool (to check status of a convert_video job) and provides critical usage prerequisites (own the token, keep the statusUrl). While it doesn't explicitly say 'use X instead', the sibling tools are unrelated operations, making the usage context clear. It stops short of explicit when-not-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
leave_feedbackRequest a capability / report a problem (free)AInspect
Tell us what you needed. If ffpipe does not offer the operation you came for - another output format, extracting a frame, a different transformation entirely - say so here: these requests are aggregated and they drive directly what gets built next, so a one-line "I wanted X" is genuinely useful to us. Also the place for bug reports and any other feedback. Free, unauthenticated, and one-way: nothing is returned but an acknowledgement, and no job is created. Include jobId if a specific job prompted this (context only - it is not checked and is not required), and contact if you want a reply. Message limit 2000 characters.
ParametersJSON Schema
| Name | Required | Description | Default |
|---|---|---|---|
| type | No | What this is: "feature_request" for a capability ffpipe does not offer yet, "bug" for something broken, "feedback" for anything else. Defaults to "feedback". | |
| jobId | No | Optional job id this relates to. Context only - ownership is NOT checked and no token is needed. | |
| contact | No | Optional. An email or handle to reply at, up to 200 characters. Omit it and the submission stays anonymous. | |
| message | Yes | What you wanted, what went wrong, or what you think. Plain text, 1 to 2000 characters. Be concrete: "needed a single frame as a jpeg at a given timestamp" is worth more to us than "more features". |
Tool Definition Quality
A4.6/5.0
Behavior5/5
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries full burden and excels: it discloses 'Free, unauthenticated, and one-way: nothing is returned but an acknowledgement, and no job is created,' and adds that jobId is 'not checked and is not required.' It also mentions the 2000-character message limit, fully revealing what to expect.
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 longer than average but every sentence earns its place, covering purpose, why one-liners matter, bug reports, cost/auth behavior, jobId, contact, and message limit. It is front-loaded with 'Tell us what you needed' and remains focused rather than rambling, though a slight trim could make it tighter.
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?
Since there is no output schema, the description explains the return behavior explicitly ('nothing is returned but an acknowledgement'). It also covers all parameters, use cases, and constraints, making the tool fully understandable for an AI agent without needing additional information.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Parameters4/5
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100%, so baseline is 3. The description adds value beyond the schema by explaining that feature requests are 'aggregated and they drive directly what gets built next' and by reinforcing the context-only nature of jobId and the optionality of contact. This contextual framing justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Purpose5/5
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's purpose with a specific verb and resource: 'Tell us what you needed' and 'the place for bug reports and any other feedback.' It explicitly distinguishes from sibling tools like convert_video and get_job_status by framing this as the outlet for missing capabilities and problems, not a processing operation.
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 explicit when-to-use guidance: 'If ffpipe does not offer the operation you came for... say so here' and 'Also the place for bug reports and any other feedback.' It implies when not to use it (for actual operations) but does not name alternative tools explicitly, so slightly less than a perfect score.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Claim this connector by publishing a /.well-known/glama.json file on your server's domain with the following structure:
{
"$schema": "https://glama.ai/mcp/schemas/connector.json",
"maintainers": [{ "email": "your-email@example.com" }]
}The email address must match the email associated with your Glama account. Once published, Glama will automatically detect and verify the file within a few minutes.
Control your server's listing on Glama, including description and metadata
Access analytics and receive server usage reports
Get monitoring and health status updates for your server
Feature your server to boost visibility and reach more users
For users:
Full audit trail – every tool call is logged with inputs and outputs for compliance and debugging
Granular tool control – enable or disable individual tools per connector to limit what your AI agents can do
Centralized credential management – store and rotate API keys and OAuth tokens in one place
Change alerts – get notified when a connector changes its schema, adds or removes tools, or updates tool definitions, so nothing breaks silently
For server owners:
Proven adoption – public usage metrics on your listing show real-world traction and build trust with prospective users
Tool-level analytics – see which tools are being used most, helping you prioritize development and documentation
Direct user feedback – users can report issues and suggest improvements through the listing, giving you a channel you would not have otherwise
The connector status is unhealthy when Glama is unable to successfully connect to the server. This can happen for several reasons:
The server is experiencing an outage
The URL of the server is wrong
Credentials required to access the server are missing or invalid
If you are the owner of this MCP connector and would like to make modifications to the listing, including providing test credentials for accessing the server, please contact support@glama.ai.
Discussions
No comments yet. Be the first to start the discussion!
Related MCP Servers
- Alicense-qualityBmaintenanceAgent-first video-data API + MCP across 6 platforms (YouTube/Shorts, TikTok, Reddit, Instagram, Pinterest): metadata, insights, Whisper transcript, and parametric frames. Pay-per-call via x402 (USDC) or Stripe.44MIT
- AlicenseAqualityCmaintenanceConverts PDF, Word, Excel, and PowerPoint documents to Markdown using a pay-per-conversion model with USDC on Base via the x402 protocol.2MIT
- AlicenseCqualityCmaintenancex402 Micropaid MCP Server — 120+ paid API endpoints for AI Agents. Pay per call with USDC on Base network. No signup, no API key needed.551MIT