Skip to main content
Glama

List media library

list_media_library
Read-only

List the user's own media library: videos they uploaded in the Prolifik app (including demo recordings saved from Content Studio) and, for keys with studio:read, AI Studio outputs, newest first. Each item's key is what a Video Hook & Demo content job accepts as demoVideoKey or hookVideoKey; only items with usableForHookDemo qualify.

Input Schema

NameRequiredDescriptionDefault
typeNovideo
limitNo
beforeNoPass the previous page's nextCursor to get the next page. A plain ISO-8601 timestamp (items strictly older than it) is still accepted but can skip items created in the same millisecond.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

B3.4/5.0
Behavior4/5

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

With readOnlyHint/destructiveHint already covering safety, the description adds real behavioral context: results are scoped to the caller's own library, AI Studio items require studio:read, ordering is newest-first, and only usableForHookDemo items are valid for job references. It stops short of describing pagination behavior, which matters here.

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?

Two dense sentences with the core content and the key-chaining hint front-loaded; every clause carries real information. Slightly long but no filler.

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 read-only list tool with annotations and no output schema, the description usefully explains the `key` field and its downstream use, but leaves the type/limit parameters and pagination semantics an agent needs to call it correctly unaddressed.

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 33% (only `before` is documented), so the description should compensate, but it says nothing about `type` (video/image) or `limit` (max 100, default 50). The usableForHookDemo filter it mentions is not even a parameter, so it adds no meaning to the two undocumented inputs.

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 (list) and resource (the user's own media library), enumerates the contents (app-uploaded videos, Content Studio demos, and permission-scoped AI Studio outputs). It is clear what the tool returns, though it does not explicitly contrast against the many sibling list_* tools.

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?

Usage is implied rather than stated: the mention of demoVideoKey/hookVideoKey and the usableForHookDemo qualifier signals this feeds the Video Hook & Demo content jobs, but there is no explicit 'use this when…' or exclusion against alternatives like list_content or list_studio_generations.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.