Skip to main content
Glama
Sign In

cliphou.se release videos

by se.cliphou
OverviewDiscussionsAdmin

Server Details

Turns every release into a social video. Finds the selling points, picks the angle, writes the copy.

If you are the author of this connector, you can claim ownership by verifying the domain or GitHub account it belongs to. Claimed connector authors can inspect health checks, view analytics, and manage their listing.
Status
Healthy
Uptime
99.9% over 21 days
Last Tested
Transport
Streamable HTTP · MCP 2025-11-25
URL
Repository
sunmer/cliphouse
GitHub Stars
0
ChatGPT
–
Claude
–

TDQS

A4.1/5.0

Scored across 6 tools

Disambiguation3/5

render_preview and render_previews differ only by a plural and both render posters/loops with editor links, making them easy to misselect, especially since both support the loop parameter. The long descriptions do clarify that one is single-template-with-props and the other is batch-by-brand-description, and the remaining tools (search_templates, get_template_spec, build_edit_link, upload_logo) are distinct. Overlap exists but is largely recoverable by reading descriptions.

Naming Consistency4/5

All six tools follow a consistent snake_case verb_noun pattern (search_templates, get_template_spec, render_preview, render_previews, build_edit_link, upload_logo). The one weakness is that render_preview vs render_previews rely on a trailing 's' to signal a fundamentally different batch mode, which is a weak distinguisher rather than a convention break.

Tool Count5/5

Six tools map cleanly onto the video-creation workflow: search, inspect spec, preview (single or batch), build edit link, and upload logo. Each tool has a distinct step in the lifecycle (preview, customize, brand assets) rather than being redundant, so the surface is well-scoped for the purpose.

Completeness4/5

The surface covers the discover -> inspect -> preview -> edit/export -> brand-logo lifecycle, including error feedback and batch selection, so an agent can complete the core task. Minor gaps like no template enumeration beyond search and no direct render/export tool exist, but the edit link exports the MP4 and the spec exposes local rendering as a workaround.

Available Tools

6 tools
get_template_specGet template specA
Read-only
Inspect

Get the editable fields of one template: current props, text roles with maxLength, theme colors, scenes, format, JSON Schema, and the source package for local rendering. Call before build_edit_link and start from the returned props.

NameRequiredDescriptionDefault
searchIdNoThe searchId returned by search_templates. Pass it through so picks can be measured.
variantIdYesTemplate id from search_templates.

TDQS

A4.2/5.0
Behavior4/5

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

Annotations declare readOnlyHint=true and openWorldHint=false, so the safety profile is already covered. The description adds behavior the annotations do not: the exact shape of the returned payload and the fact that it includes a source package for local rendering, which tells the agent what it can do with the result.

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, zero filler. The payload enumeration is front-loaded and the sequencing instruction is placed last where it acts as a call-to-action rather than preamble.

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?

There is no output schema, so the description correctly compensates by naming the returned fields, and the pre-call sequencing with build_edit_link is supplied. Minor gaps remain (no mention of error cases or whether the spec is variant-specific vs. shared), but an agent has enough to call it correctly.

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 both parameters (searchId, variantId) are documented in the schema with patterns and provenance ('from search_templates', 'returned by search_templates'). The description adds no further parameter meaning, so the baseline 3 applies.

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?

States a specific verb (get) and resource (editable fields of one template), then enumerates exactly what the spec contains: props, text roles with maxLength, theme colors, scenes, format, JSON Schema, and source package. An agent can tell this apart from render_preview and build_edit_link without opening the schema.

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 sequences the call: 'Call before build_edit_link and start from the returned props,' naming the alternative it precedes. It gives clear context but does not say when this tool is the wrong choice (e.g., when render_preview or search_templates alone would suffice), so no exclusion guidance.

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

render_previewRender personalized previewA
Idempotent
Inspect

Render a poster image of a template filled with the user's props, in a few seconds, and return it with the editor link. Call after get_template_spec once the props are filled, and show the image to the user. Invalid props return an error that names the field to fix. If rendering is unavailable, poster is null and the editor link still works. With loop: true it also waits for a 4-second animated WebP loop of these props and returns it as video. A loop still rendering has video: null and videoPending: true; call again with the same props to get it. loop: "start" returns the poster now and starts the loop in the background. Show the loop as an image (Markdown title) where the host renders images.

NameRequiredDescriptionDefault
loopNotrue waits for a 4-second animated loop of these props and returns it as video. "start" only starts it.
propsYesThe full props object from get_template_spec with edited texts, theme, and media.
searchIdNoThe searchId returned by search_templates. Pass it through so picks can be measured.
variantIdYesTemplate id.
templateVersionNoOnly for older template versions. Usually omit.

TDQS

A4.7/5.0
Behavior5/5

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

Annotations only declare safety/idempotency; the description adds latency ('a few seconds'), error semantics ('invalid props return an error that names the field to fix'), graceful degradation ('poster is null and the editor link still works'), and the async polling contract (video: null + videoPending: true, call again with same props). This is unusually rich behavioral disclosure beyond the structured fields.

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?

Leading sentence front-loads the purpose, and each subsequent sentence carries a distinct actionable fact (error handling, unavailability fallback, loop modes, polling, display format). Dense but zero filler.

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 present, the description fully compensates by describing return fields (poster, editor link, video, videoPending) and their null-state meanings. An agent has everything needed to call it correctly and interpret the response.

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, but the description adds workflow meaning the schema lacks — the retry-until-not-pending pattern for loop and the distinction that 'start' returns the poster immediately while true blocks. That elevates it above baseline without fully re-documenting every 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?

States a specific verb (render), resource (poster image of a template filled with the user's props), and deliverables (image plus editor link). An agent can immediately tell this apart from get_template_spec and build_edit_link, which only supply the spec and link respectively.

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?

Explicit sequencing: 'Call after get_template_spec once the props are filled, and show the image to the user,' with clear conditions for the loop modes. It doesn't name the sibling render_previews (plural) as an alternative or state a when-not-to-use condition, so it falls just short of 5.

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

render_previewsRender tailored previewsA
Idempotent
Inspect

Render posters of up to 4 templates at once, each filled with one brand description, so the user picks from options that already show their product. The server maps the brand onto each template's text fields and shortens text to fit. Returns, per template: id, title, poster URL (null if it was not ready in time), editor link, the tailored props to start from after the pick, and keptSample: text fields that still hold the template's sample text (fill them with real facts after the pick). Inline images follow the text, in the same order as the results. shortened lists brand texts that were cut to fit a field ({role, from, to, max}); rewrite them for that field after the pick. Animated loops (4-second animated WebP of each tailored template) take two calls. First call with loop: "start": it returns the posters as fast as without loops and starts the loops in the background. Show the posters. Then call again with the same arguments and loop: true: it waits for the loops and returns video (the loop URL) per template. A loop still rendering has video: null and videoPending: true; call once more to get it. Show each loop as an image (Markdown title) where the host renders images, so the options animate.

NameRequiredDescriptionDefault
loopNo"start" returns the posters now and starts 4-second animated loops in the background. true waits for the loops and returns them as video.
brandYesThe product facts from the user's project. Never invent numbers.
searchIdNoThe searchId returned by search_templates. Pass it through so picks can be measured.
variantIdsYesTemplate ids from search_templates.

TDQS

A4.6/5.0
Behavior5/5

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

Annotations cover safety (readOnly=false, idempotent=true, destructive=false), and the description adds substantial behavior beyond that: which fields are returned per template, that poster URL is null when not ready, the keptSample and shortened-list semantics, inline image ordering, and the multi-call loop protocol with videoPending handling.

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?

Front-loaded with the core action, then structured by concern (returns, shortened lists, loops). The loop paragraph is dense and slightly long, but each sentence carries operational information an agent needs, so little is wasted.

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 carries the return-value burden and does so thoroughly: result fields, null/pending cases, and the special handling needed for loops and sample-text fields. An agent has everything required to call and interpret results.

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 the baseline is 3. The description still adds meaning by explaining the loop:'start' vs loop:true return behavior and the post-pick fill workflow, which goes beyond the per-field schema text.

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?

States a specific verb and resource with scope: 'Render posters of up to 4 templates at once, each filled with one brand description.' The 'up to 4 templates at once' batching scope distinguishes it from the singular sibling render_preview without needing the schema.

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?

Context is clear ('so the user picks from options that already show their product') and it spells out the two-call workflow for animated loops. It stops short of explicitly naming render_preview as the single-template alternative or stating when to prefer one over the other, so routing to the sibling remains inferential.

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

search_templatesSearch video templatesA
Read-only
Inspect

Find marketing video templates for a product, project, or announcement. Prefer a marketing goal and, when project facts support it, a release moment; then add a short product or style query. Returns a searchId, the selected moment, detectedMoments hints, and results with id, title, goals, moments, aspect, length, preview MP4, poster image, and editor URL. Engine details appear only when the engine filter is used.

NameRequiredDescriptionDefault
goalNoMarketing goal. One of: launch-product (Launch a product), announce-feature (Announce a feature), share-update (Share an update), grow-waitlist (Grow a waitlist), announce-integration (Announce an integration), announce-pricing (Announce pricing), celebrate-milestone (Celebrate a milestone), share-social-proof (Share social proof), promote-event (Promote an event), introduce-brand (Introduce a brand), run-promotion (Run a promotion), hire-team (Hire for the team).
limitNoMaximum results, default 6.
musicNotrue for beat-synced templates with a generated soundtrack, false for silent ones.
queryNoShort product or style description, for example "developer tool" or "minimal logo".
aspectNoOnly when the destination implies it: 9:16 vertical (Reels, TikTok, Shorts), 16:9 (YouTube, web), 1:1 or 4:5 (feeds).
engineNoAdvanced source-package filter. Omit unless the user explicitly asks for an engine.
momentNoRelease moment backed by project facts. Filters and ranks templates for it. One of: most-requested-feature (Most-requested feature shipped), generally-available (Available to everyone), limit-raised (A limit was raised or removed), faster (Something got faster), manual-step-removed (A manual step disappeared), integration-live (An integration went live), pricing-changed (Pricing changed), reliability-fix (A reliability fix landed), new-language-or-region (New language or region), new-platform (New platform), free-resource (Free tool or resource released), milestone (A real milestone was reached).
purposeNoExact catalog purpose, for example "Product launch".
maxSecondsNoMaximum video length in seconds.

TDQS

A3.8/5.0
Behavior4/5

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

Annotations already declare readOnlyHint=true and openWorldHint=false, covering the safety profile. The description adds value beyond that by enumerating what is returned (searchId, selected moment, detectedMoments hints, result fields) and noting that "Engine details appear only when the engine filter is used" — a genuine behavioral detail. No output schema exists, so this return disclosure is meaningful.

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?

Three sentences, front-loaded with the core purpose. The middle sentence packs the recommended invocation order and the third lists return fields. Efficient overall, though the returns sentence is long and slightly dense.

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 no output schema, the description carries the return-value burden and does so adequately. Annotations cover safety, and the description covers purpose, query construction, and outputs. A 9-parameter optional tool could say a bit more about edge cases or empty-result behavior, but nothing essential is missing.

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 the baseline is 3. The description goes further by prescribing a priority order (goal first, moment when supported by facts, then query), which adds invocation guidance beyond the per-field schema text. It does not document field formats the schema lacks, so it earns a modest bump.

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?

States a specific verb and resource: "Find marketing video templates" for a product/project/announcement. Clear enough that an agent knows this is a template search operation. It does not explicitly distinguish itself from siblings like get_template_spec, so it stops just short of a 5.

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

Usage Guidelines3/5

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

"Prefer a marketing goal and, when project facts support it, a release moment; then add a short product or style query" gives sequencing guidance for building a query. However, it never states when to use this tool versus siblings such as get_template_spec or render_preview, so usage context is only implied.

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. 1 tool update
    • Changedsearch_templates1 field changed
      • addedInput schema / properties / moment
        Added value: +{
+  "description": "Release moment backed by project facts. Filters and ranks templates for it. One of: most-requested-feature (Most-requested feature shipped), generally-available (Available to everyone), limit-raised (A limit was raised or removed), faster (Something got faster), manual-step-removed (A manual step disappeared), integration-live (An integration went live), pricing-changed (Pricing changed), reliability-fix (A reliability fix landed), new-language-or-region (New language or region), new-platform (New platform), free-resource (Free tool or resource released), milestone (A real milestone was reached).",
+  "enum": [
+    "most-requested-feature",
+    "generally-available",
+    "limit-raised",
+    "faster",
+    "manual-step-removed",
+    "integration-live",
+    "pricing-changed",
+    "reliability-fix",
+    "new-language-or-region",
+    "new-platform",
+    "free-resource",
+    "milestone"
+  ],
+  "type": "string"
+}
  2. 1 tool update
    • Changedrender_preview1 field changed
      • addedInput schema / properties / loop
        Added value: +{
+  "anyOf": [
+    {
+      "const": "start",
+      "type": "string"
+    },
+    {
+      "type": "boolean"
+    }
+  ],
+  "description": "true waits for a 4-second animated loop of these props and returns it as video. \"start\" only starts it."
+}
  3. 2 tool updates
    • Changedrender_previews1 field changed
      • addedInput schema / properties / brand / properties / logo
        Added value: +{
+  "description": "The logo object from upload_logo. Templates with a logo slot show it in place of the brand name.",
+  "properties": {
+    "id": {
+      "pattern": "^[a-f0-9]{64}$",
+      "type": "string"
+    },
+    "mono": {
+      "type": "boolean"
+    },
+    "ratio": {
+      "maximum": 8,
+      "minimum": 0.2,
+      "type": "number"
+    }
+  },
+  "required": [
+    "id",
+    "ratio",
+    "mono"
+  ],
+  "type": "object"
+}
    • Addedupload_logo
  4. 2 tool updates
    • Changedrender_previews6 fields changed
      • changedInput schema / properties / brand / properties / headline / description
        Previous value: -"Main message, as short as possible."New value: +"The hook: a pain, question, number, or benefit, as short as possible."
      • changedInput schema / properties / brand / properties / points / description
        Previous value: -"2-3 real features or facts, short phrases."New value: +"2-3 benefits backed by real features or facts, short phrases."
      • changedInput schema / properties / brand / properties / subhead / description
        Previous value: -"One supporting sentence."New value: +"One sentence: who it is for and what it solves."
      • addedInput schema / properties / loop / anyOf
        Added value: +[
+  {
+    "const": "start",
+    "type": "string"
+  },
+  {
+    "type": "boolean"
+  }
+]
      • changedInput schema / properties / loop / description
        Previous value: -"true to also render a 4-second animated WebP loop of each template. Slower; posters still come back if a loop is not ready."New value: +"\"start\" returns the posters now and starts 4-second animated loops in the background. true waits for the loops and returns them as video."
      • removedInput schema / properties / loop / type
        Removed value: -"boolean"
    • Changedsearch_templates3 fields changed
      • changedInput schema / properties / engine / description
        Previous value: -"Rendering engine of the source package. Usually omit."New value: +"Advanced source-package filter. Omit unless the user explicitly asks for an engine."
      • addedInput schema / properties / goal
        Added value: +{
+  "description": "Marketing goal. One of: launch-product (Launch a product), announce-feature (Announce a feature), share-update (Share an update), grow-waitlist (Grow a waitlist), announce-integration (Announce an integration), announce-pricing (Announce pricing), celebrate-milestone (Celebrate a milestone), share-social-proof (Share social proof), promote-event (Promote an event), introduce-brand (Introduce a brand), run-promotion (Run a promotion), hire-team (Hire for the team).",
+  "enum": [
+    "launch-product",
+    "announce-feature",
+    "share-update",
+    "grow-waitlist",
+    "announce-integration",
+    "announce-pricing",
+    "celebrate-milestone",
+    "share-social-proof",
+    "promote-event",
+    "introduce-brand",
+    "run-promotion",
+    "hire-team"
+  ],
+  "type": "string"
+}
      • changedInput schema / properties / query / description
        Previous value: -"Short description of the video, for example \"saas product launch\" or \"logo intro\"."New value: +"Short product or style description, for example \"developer tool\" or \"minimal logo\"."
  5. 1 tool update
    • Changedrender_previews1 field changed
      • addedInput schema / properties / loop
        Added value: +{
+  "description": "true to also render a 4-second animated WebP loop of each template. Slower; posters still come back if a loop is not ready.",
+  "type": "boolean"
+}
  6. 1 tool update
    • Addedrender_previews
  7. 3 tool updates
    • Changedbuild_edit_link1 field changed
      • addedInput schema / properties / searchId
        Added value: +{
+  "description": "The searchId returned by search_templates. Pass it through so picks can be measured.",
+  "pattern": "^[A-Za-z0-9_-]{8,40}$",
+  "type": "string"
+}
    • Changedget_template_spec1 field changed
      • addedInput schema / properties / searchId
        Added value: +{
+  "description": "The searchId returned by search_templates. Pass it through so picks can be measured.",
+  "pattern": "^[A-Za-z0-9_-]{8,40}$",
+  "type": "string"
+}
    • Addedrender_preview
  8. 3 tool updates
    • Changedbuild_edit_link3 fields changed
      • addedInput schema / properties / props / description
        Added value: +"The full props object from get_template_spec with edited texts, theme, and media."
      • addedInput schema / properties / templateVersion / description
        Added value: +"Only for older template versions. Usually omit."
      • addedInput schema / properties / variantId / description
        Added value: +"Template id."
    • Changedget_template_spec1 field changed
      • addedInput schema / properties / variantId / description
        Added value: +"Template id from search_templates."
    • Changedsearch_templates7 fields changed
      • addedInput schema / properties / aspect
        Added value: +{
+  "description": "Only when the destination implies it: 9:16 vertical (Reels, TikTok, Shorts), 16:9 (YouTube, web), 1:1 or 4:5 (feeds).",
+  "enum": [
+    "16:9",
+    "9:16",
+    "4:5",
+    "1:1"
+  ],
+  "type": "string"
+}
      • addedInput schema / properties / engine / description
        Added value: +"Rendering engine of the source package. Usually omit."
      • addedInput schema / properties / limit / description
        Added value: +"Maximum results, default 6."
      • addedInput schema / properties / maxSeconds
        Added value: +{
+  "description": "Maximum video length in seconds.",
+  "maximum": 600,
+  "minimum": 1,
+  "type": "integer"
+}
      • addedInput schema / properties / music
        Added value: +{
+  "description": "true for beat-synced templates with a generated soundtrack, false for silent ones.",
+  "type": "boolean"
+}
      • addedInput schema / properties / purpose / description
        Added value: +"Exact catalog purpose, for example \"Product launch\"."
      • addedInput schema / properties / query / description
        Added value: +"Short description of the video, for example \"saas product launch\" or \"logo intro\"."
  9. 3 tool updates
    • First observedbuild_edit_link
    • First observedget_template_spec
    • First observedsearch_templates

Related MCP Connectors

Related MCP Servers

Try in Browser
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

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources