Search the curated directory of MCP servers for AI filmmaking and plan a full production stack.
Glama MCP Gateway
Connect through Glama MCP Gateway for full control over tool access and complete visibility into every call.
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.
Average 4.1/5 across 15 of 15 tools scored. Lowest: 3.1/5.
Most tools target distinct entities (capabilities, playbooks, recommendations, servers, install configs). The only potential confusion is between plan_film_stack and recommend_film_mcps, but their descriptions clarify different scopes: full pipeline vs intent-routed brief.
All tools follow a consistent verb-first snake_case pattern: get_ for singular resources, list_ for plural, plus search_, plan_, recommend_, and submit_. No mixed conventions or vague verbs.
15 tools is at the upper end of the ideal range but each earns its place: search, retrieval, listing, planning, recommendation, install config, and submission. No redundant tools.
Covers the full directory lifecycle: discovery, retrieval, contextual listings, planning, recommendations, install config generation, and submission. Minor gap: there's no explicit list-all-servers endpoint, but search_film_mcps can fulfill that role.
get_catalog_pulseAInspectGet the mcp.film operating pulse: catalog freshness, demand signals, curator agenda, Martini growth checks, and machine-readable surfaces. Use this before deciding what to update next.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional top-level pulse section. Default all. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden. It indicates a read operation ('Get') and lists the returned content, but does not disclose potential side effects, authentication needs, rate limits, or data freshness. Given the read-only implication, it provides moderate transparency.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences, front-loaded with the verb and resource, and includes a usage hint. Every word earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one optional parameter and no output schema. The description covers what the tool does and when to use it, though it doesn't elaborate on return format. This is adequate for the tool's complexity.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single 'section' parameter is fully described in the schema with enum values and default behavior. The description adds no additional parameter semantics, so the baseline score of 3 applies due to 100% schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly specifies the tool retrieves the mcp.film operating pulse and enumerates its key components (catalog freshness, demand signals, curator agenda, Martini growth checks, machine-readable surfaces). This distinguishes it from sibling tools that focus on specific capabilities, MCPs, or playbooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description explicitly instructs 'Use this before deciding what to update next', providing a clear use case. It does not explicitly state when not to use or name alternative tools, but the guidance is sufficient for a get-style tool.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_film_capabilityAInspectGet the ranked server cluster for one capability tag such as text-to-video, image-to-video, tts, timeline-editing, voice-cloning, or upscaling.
| Name | Required | Description | Default |
|---|---|---|---|
| capability | Yes | Exact capability tag. | |
| remote_only | No | Only hosted remote MCPs. | |
| official_only | No | Only vendor-maintained servers. |
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 that the output is a 'ranked server cluster' and that it takes a single capability tag, but it does not explain what 'ranked' means, the structure of the cluster, or any potential side effects or prerequisites. This is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence with no filler. It immediately states the verb and resource, then provides useful examples, earning a perfect score for conciseness.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple getter with full schema coverage, the description is reasonably complete. It gives enough context to invoke the tool correctly, but the lack of an output schema means the response format is not explained. This is a minor gap given the tool's straightforward purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
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 adds value by enumerating example capability tags, which clarifies the 'capability' parameter, but it does not elaborate on 'remote_only' or 'official_only' beyond their schema descriptions. Overall, it meets but does not exceed the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb and resource ('Get the ranked server cluster') and scopes it to a single capability tag with concrete examples. This clearly distinguishes it from sibling tools like list_film_capabilities or search_film_mcps, which have broader or different purposes.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use the tool (when you need a ranked cluster for one specific tag) and provides examples of valid tags. However, it does not explicitly name alternative tools or provide 'when not to use' guidance, making it clear but not exhaustive.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_film_mcpAInspectGet the full mcp.film entry for one server by slug: description, install commands, auth requirements, sample tools, links, and field notes (caveats).
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | Server slug, e.g. 'martini' or 'elevenlabs' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description carries the burden of behavioral disclosure. It honestly describes what the tool returns but does not disclose potential errors, rate limits, or the fact that it likely performs a live fetch from mcp.film. For a read-only retrieval tool, this is acceptable but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that leads with the action and resource, then lists the key contents with commas. Every phrase adds value, and there is no redundant or filler text.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
With no output schema, the description compensates by enumerating the major fields returned (description, install commands, auth requirements, sample tools, links, field notes). It does not mention error behaviors or response format, but for a simple single-parameter get tool, this is sufficiently complete for an agent to understand what to expect.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema already fully documents the slug parameter with 100% coverage including an example. The description merely repeats 'by slug' without adding formatting or constraints beyond what the schema shows, so it provides no additional semantic value beyond the baseline.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'Get' with the exact resource 'full mcp.film entry for one server by slug', and explicitly enumerates the contents (description, install commands, auth requirements, sample tools, links, field notes). This clearly differentiates it from sibling tools like get_install_config or get_film_capability, which target narrower aspects.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly indicates that this tool is for retrieving the complete entry for a single server, implying it should be used when full details are needed. However, it does not explicitly state when not to use it or mention alternatives, though the 'full entry' phrasing provides clear context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_film_playbookAInspectGet one production playbook by id, including primary servers, setup order, auth gates, workflow steps, failure modes, fallback servers, constraints, and links to each server's mcp.film page.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Playbook id, e.g. 'commercial-sprint' or 'local-edit-bay' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the full burden of disclosing behavior. It explicitly lists the returned contents including servers, auth gates, steps, failure modes, constraints, and links, making the tool's scope clear. It omits error handling details but is adequate for a read-like get operation.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The single sentence is front-loaded with the verb and resource, then lists relevant content components without redundancy. Every phrase earns its place, making it appropriately concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple get-by-id tool with one parameter, the description fully specifies the expected output components, compensating for the lack of output schema. The sibling context clarifies its role in the toolset.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema coverage is 100% with an example for 'id'. The description adds no additional parameter semantics beyond restating 'by id', so it does not enhance what the schema already provides.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it retrieves one production playbook by id and enumerates the included content. It distinguishes from sibling list_film_playbooks by specifying 'one', indicating a single-item fetch.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies use when a specific playbook id is known, contrasting with list_film_playbooks which likely lists all. However, it does not explicitly name alternatives or exclusion conditions.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_film_recommendationAInspectGet one intent-routed recommendation by id, including primary server roles, reasons, fallbacks, matching playbook, and Martini handoff guidance.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Recommendation id, e.g. 'fast-commercial' or 'hosted-only-stack' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description takes on the full burden. It discloses the key behavioral aspect—what the response contains—by listing the included fields. It does not mention auth, rate limits, or error behavior, but for a read-only get-by-id the coverage is strong.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, front-loaded sentence that names the action and resource first, then efficiently lists the included output fields. No wasted words.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool is simple with one parameter and no output schema, so the description's enumeration of return contents is appropriately complete. It lacks explicit alternative guidance, but that is covered under usage guidelines.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already fully describes the id parameter with examples. The description adds the context 'intent-routed' but does not enrich parameter meaning beyond the schema, so baseline 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool gets one recommendation by id and enumerates the response contents (roles, reasons, fallbacks, playbook, Martini handoff). This distinguishes it from list_film_recommendations by specifying single-item retrieval.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage for retrieving a single recommendation by id but gives no explicit comparison to sibling tools like list_film_recommendations or recommend_film_mcps. There are no when-to-use or when-not-to-use guidelines.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
get_install_configAInspectGet a copy-paste install command, JSON config, or hosted remote URL for a server and MCP client profile. Includes required env vars and auth type.
| Name | Required | Description | Default |
|---|---|---|---|
| slug | Yes | ||
| client | Yes |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries full responsibility for behavioral disclosure. It adds useful forward-looking context by revealing that the output includes required env vars and auth type, and mentions the three possible return forms. However, it does not address error handling, prerequisites, or unexpected behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, direct sentence that front-loads the key purpose and avoids unnecessary words. Every phrase contributes information, making it highly concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the simple 2-parameter tool with no output schema, the description provides a solid overview of return types and content. It mentions the three output forms and the inclusion of env vars and auth type, which is sufficient for most use cases. However, it omits details such as how to interpret the response for different clients or potential error conditions, leaving minor gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema has 0% description coverage, so the description must compensate. It maps 'slug' to a server and 'client' to an MCP client profile, which gives some meaning beyond the raw parameter names. The client enum is self-explanatory, but the exact semantics and expected format of 'slug' remain vaguely defined.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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 ('Get') and resource ('a copy-paste install command, JSON config, or hosted remote URL'). It also references a server and MCP client profile, which distinguishes it from the sibling film-related tools.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies the tool is used for retrieving install configuration for a given server and client profile, but does not explicitly state when to use it over alternatives or any exclusions. No alternative tool names are mentioned.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_client_profilesAInspectList the MCP client setup profiles mcp.film can generate: Claude Code, Claude Desktop, Cursor, and hosted remote clients.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
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 states the tool 'Lists' profiles, indicating a non-destructive, read-only operation. It also specifies the types of profiles returned, providing adequate behavioral transparency for a parameterless list tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that front-loads the action ('List') and resource ('MCP client setup profiles'). Every word adds value, listing specific examples without superfluous detail.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple tool with no parameters, no output schema, and a straightforward purpose, the description is complete. It tells the user exactly what will be listed and gives the categories, leaving no significant gaps.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
There are zero parameters, so the baseline is 4. The description does not need to explain parameter meanings. It focuses on the tool's purpose, which adds value beyond the empty schema.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses a specific verb 'List' and identifies the resource as 'MCP client setup profiles mcp.film can generate'. It further lists the exact profiles (Claude Code, Claude Desktop, Cursor, hosted remote clients), which clearly distinguishes it from sibling list tools such as list_film_capabilities or list_film_categories.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description clearly implies when to use this tool: when you need to know the available client setup profiles. It does not explicitly state exclusions or alternatives, but for a simple list operation the context is clear enough.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_film_capabilitiesAInspectList capability tags in the mcp.film registry, ranked by number of matching servers. Use get_film_capability for the server cluster behind one tag.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional substring filter, e.g. 'video', 'voice', or 'timeline'. | |
| min_count | No | Only include capability tags with at least this many servers. Default 1. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden of behavioral disclosure. The verb 'List' implies a read-only operation, and the ranking by matching server count adds useful behavioral context. It omits pagination/return details, but for a simple list tool these are minor gaps.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences with the primary action and ranking behavior front-loaded. The second sentence provides purposeful alternative guidance, so every sentence earns its place.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with only two optional parameters and no output schema, the description is complete: what is listed, how results are ranked, and which sibling tool to use for details. It is sufficient for correct selection and invocation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The input schema already documents both parameters with 100% coverage, so the description adds little parameter-level meaning. The mention of 'matching servers' loosely relates to min_count but does not go beyond schema descriptions.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists capability tags in the mcp.film registry and ranks them by server count. This is specific and distinguishes it from the sibling get_film_capability.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It explicitly recommends get_film_capability for the server cluster behind one tag, providing a clear alternative for different granularity. This gives direct when-to-use guidance.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_film_categoriesAInspectList all mcp.film categories with ids, pipeline stage, and per-category agent hints.
| Name | Required | Description | Default |
|---|---|---|---|
No parameters | |||
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations, the description carries the burden. It discloses the content of the output (ids, pipeline stage, agent hints) but does not explicitly state that it is a read-only operation or describe any behavioral nuances. It is adequate but not rich.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is a single, well-structured sentence that gets straight to the point. Every word adds value: verb, resource, and output fields. Perfectly concise.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a zero-parameter list tool with no output schema, the description is complete. It specifies exactly what will be returned (ids, pipeline stage, per-category agent hints) and leaves no ambiguity about the tool's purpose.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The tool has zero parameters, so the baseline is 4. The description does not need to explain parameters, and the schema fully covers everything.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description uses the specific verb 'List' and names the resource 'mcp.film categories', clearly stating it returns ids, pipeline stage, and per-category agent hints. This distinguishes it from sibling list tools like list_film_capabilities or list_film_playbooks.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies usage whenever category information is needed, but it does not explicitly state when to use this tool over alternatives or any exclusions. The resource name is clear enough, but no explicit guidance is provided.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_film_playbooksAInspectList mcp.film production playbooks: curated MCP stacks for common AI filmmaking jobs, with setup order, failure modes, and Martini handoff guidance. Use get_film_playbook for full steps and auth gates.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional free-text search over title, summary, best_for, constraints, and server names. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
No annotations are provided, so the description must carry the burden. It discloses that playbooks include setup order, failure modes, and handoff guidance, giving useful content context. However, it does not describe return format, pagination, or any side effects, though as a list operation the risk is low. The mention of auth gates in the alternative hints at a limitation but is not explicit.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
Two sentences, front-loaded with purpose, followed by content detail and sibling pointer. Every clause earns its place, no redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a simple list tool with one optional parameter and no output schema, the description provides sufficient context: what the list contains, and where to go for deeper details. The explicit sibling reference covers the main need. A minor gap is absence of return shape, but it is not critical for a list operation.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The single optional 'query' parameter is fully described in the schema with 100% coverage. The description does not add parameter-specific meaning, which is acceptable since the schema already explains the behavior. Baseline of 3 applies.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool lists production playbooks, specifies what they contain (setup order, failure modes, Martini handoff guidance), and explicitly distinguishes it from get_film_playbook. The verb 'List' combined with the resource 'playbooks' makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
Provides explicit guidance: use get_film_playbook for full steps and auth gates, implying this tool is for overview/listing. This directly tells the agent when to choose this tool versus the alternative, exceeding mere context.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
list_film_recommendationsAInspectList mcp.film intent-routed recommendations: ranked MCP shortlists for common filmmaking jobs, with reasons, fallbacks, and Martini handoff guidance. Use get_film_recommendation for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Optional free-text search over titles, summaries, best_for text, tags, server names, and Martini handoff guidance. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description must carry the transparency burden. It explains the behavior of returning 'ranked MCP shortlists' and 'reasons, fallbacks, and Martini handoff guidance', but it does not explicitly state that it is a read-only operation or describe any side effects, pagination, or ordering details beyond what is implicit in 'ranked'.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is concise and front-loaded: the first sentence states the tool's purpose and content, and the second sentence provides a clean pointer to the alternative tool. Every clause earns its place with no filler or redundancy.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The description covers the purpose, result contents (ranked shortlists, reasons, fallbacks, handoff guidance), and directs users to get_film_recommendation for more detail. Since there is no output schema, it adequately describes what to expect, though it does not mention pagination or the exact format of results, which would improve completeness.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The only parameter 'query' is fully described in the schema with a coverage of 100%, so the baseline is 3. The tool description does not add any additional parameter-specific information, but the schema already provides comprehensive meaning for the optional free-text search.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's function with a specific verb 'List' and resource 'mcp.film intent-routed recommendations', adding details about ranked shortlists, reasons, fallbacks, and Martini handoff guidance. It also differentiates from the sibling get_film_recommendation by indicating that tool provides full detail.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives clear context: it lists recommendations for common filmmaking jobs. It provides an explicit alternative with 'Use get_film_recommendation for full detail', but does not fully enumerate exclusions or when not to use this tool versus other siblings like search_film_mcps or recommend_film_mcps.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
plan_film_stackAInspectGet a recommended set of MCP servers covering the whole film pipeline (develop → visualize → shoot → sound → cut → finish → ship). Returns 1-3 picks per stage, ranked by official status and hosting. Pass a brief to bias picks (matched against capabilities and taglines).
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional: what you're making, e.g. 'a 60s commercial with a consistent character and licensed music' |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the burden of disclosing behavior. It explicitly states the output format (1-3 picks per stage) and ranking criteria (official status and hosting), and explains how an optional brief can bias picks by matching capabilities and taglines. This provides solid behavioral expectations beyond a simple 'recommends servers' statement.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is three sentences, front-loaded with the main purpose, then output specifics, then input usage. Every sentence contributes meaning without redundancy or fluff. This is appropriately concise and well-structured.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
Given the low complexity (one optional param, no output schema, no annotations), the description is complete. It covers what the tool does, the pipeline stages, the output shape, ranking criteria, and how the input affects behavior. Nothing critical appears missing for an agent to invoke the tool correctly.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema provides a thorough description of the 'brief' parameter with an example, achieving 100% coverage. The tool description adds context on how the brief is used ('matched against capabilities and taglines'), enhancing the schema's meaning. Baseline is 3, and the added value justifies a 4.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool provides a recommended set of MCP servers for the entire film pipeline, listing the specific stages. It distinguishes itself from sibling tools by emphasizing the whole-pipeline planning aspect and the output structure. The verb 'Get' plus the resource 'recommended set of MCP servers' makes 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description implies when to use this tool (when needing a full film pipeline plan) and explains how to influence results with a brief. It does not explicitly mention alternative tools or exclusion criteria, but the contextual scope is clear. This fits 'clear context, no exclusions'.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
recommend_film_mcpsBInspectGiven a filmmaking brief, return the closest intent-routed MCP recommendations and the first servers to connect. Use hosted_only=true when the agent cannot spawn local tools.
| Name | Required | Description | Default |
|---|---|---|---|
| brief | Yes | What you're trying to make, e.g. 'avatar UGC ad with voiceover' or 'search dailies and cut a trailer' | |
| hosted_only | No | Only return hosted remote primary/fallback servers where possible. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of disclosing behavioral traits. It mentions 'intent-routed' and 'first servers to connect,' but does not state whether the operation is read-only, how recommendations are ranked, what happens on no matches, or any potential side effects. This is a minimal disclosure for a recommendation tool.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is exactly two sentences, with the first sentence stating purpose and the second providing focused parameter guidance. Every word earns its place; there is no redundancy or fluff.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has no output schema, so the description must clarify what is returned. It states 'closest intent-routed MCP recommendations and the first servers to connect,' giving a basic idea of output. However, it lacks details about result structure, ordering, fallback logic, or error handling. Given the simplicity of the tool and sibling context, this is adequate but incomplete.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is 100% for both parameters, so the schema already documents them. The description adds a usage condition for hosted_only=true, but this largely echoes the schema's description ('Only return hosted remote primary/fallback servers where possible'). No additional meaning is added for the 'brief' parameter.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states the tool's action ('return') and resource ('closest intent-routed MCP recommendations and the first servers to connect'), providing a specific verb and target. It distinguishes itself from siblings like search_film_mcps by emphasizing intent-routing and server connection, though it does not explicitly name alternatives.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description gives one parameter-specific usage condition ('Use hosted_only=true when the agent cannot spawn local tools') but offers no guidance on when to choose this tool over sibling tools such as get_film_recommendation or plan_film_stack. The 'Given a filmmaking brief' phrase implies a use case but provides no exclusions or alternative comparisons.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
search_film_mcpsAInspectSearch the mcp.film directory of MCP servers for AI filmmaking. Filter by free-text query (matches name, vendor, tagline, capabilities), category id, or capability. Returns compact entries; use get_film_mcp for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| query | No | Free-text search, e.g. 'upscale video' or 'voice cloning' | |
| category | No | Category id (see list_film_categories) | |
| capability | No | Exact capability tag, e.g. 'image-to-video' | |
| remote_only | No | Only hosted remote MCPs (no local install) | |
| official_only | No | Only vendor-maintained servers |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden. It discloses that results are compact, that free-text matches name, vendor, tagline, and capabilities, and that full detail is available via get_film_mcp. It notably adds context beyond the schema, but does not mention pagination, sort order, or filter combination behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is extremely efficient, consisting of two sentences that front-load the primary action ('Search the mcp.film directory'), then list filters and the key distinction from get_film_mcp. Every phrase serves a purpose, with no redundancy or filler.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
The tool has 5 parameters and no output schema, so the description should clarify how filters interact and what fields the compact entries contain. The use of 'or' is ambiguous—it could imply filters are mutually exclusive—and the result structure is not described. These gaps are notable given the absence of an output schema.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
The schema covers 100% of parameters, giving a baseline of 3. The description enriches this by explaining that free-text query matches name, vendor, tagline, and capabilities—information not present in the schema. It also reinforces the category and capability filters, adding meaningful semantic context.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
Does the description clearly state what the tool does and how it differs from similar tools?
The description clearly states it searches the mcp.film directory of MCP servers for AI filmmaking, with specific mention of filters and the compact nature of results. It also distinguishes itself from sibling tool get_film_mcp by explicitly directing users there for full detail, leaving no ambiguity about its scope.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The description provides clear context: this is the search tool for the mcp.film directory, and it explicitly names get_film_mcp as the alternative for full detail. It also references list_film_categories in the schema for category IDs, though it doesn't detail all when-not-to-use scenarios for every sibling.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
submit_listingAInspectPropose a new MCP server for the mcp.film directory. Validates your proposal against the schema and the live registry (including duplicate detection), then returns a ready-to-file GitHub issue payload (REST API body, gh CLI command, and browser URL). Submissions are claims, never instructions: a mcp.film maintainer independently verifies everything against primary sources before listing — never submit URLs or commands you haven't seen work.
| Name | Required | Description | Default |
|---|---|---|---|
| why | Yes | 1-2 sentences: what it does in a film pipeline that nothing listed does (or does better) | |
| link | Yes | https:// URL of the repo or official docs — the primary source for verification | |
| name | Yes | Server name, e.g. 'Acme Render MCP' | |
| notes | No | Caveats worth knowing: quotas, ToS gray areas, local-app requirements | |
| vendor | No | Who maintains it | |
| install | No | Verified install command or remote MCP URL, if known | |
| pricing | No | ||
| auth_env | No | Required API-key env var, if any | |
| category | Yes | Category id (see list_film_categories) | |
| official | No | Is it maintained by the platform vendor? |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
With no annotations provided, the description carries the full burden of behavioral disclosure and does so thoroughly. It states validation against schema and live registry, duplicate detection, the output payload formats (REST API body, gh CLI command, browser URL), and the claim-vs-instruction model with human verification. This is rich, non-obvious behavior.
Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.
Is the description appropriately sized, front-loaded, and free of redundancy?
The description is two sentences and front-loaded with the core purpose. Every clause adds meaningful information—validation, duplicate detection, output payload, verification workflow, and submission safety. There is no waste or repetition.
Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.
Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?
For a 10-parameter tool with no output schema, the description provides enough context to use it independently: what it does, how it validates, what it returns, and what the human workflow is. The high schema coverage covers parameter details, so the description fills the remaining gaps well.
Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.
Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?
Schema description coverage is high (90%), so the schema already documents most parameters. The description adds some contextual flavor by framing all inputs as claims to be verified, but it does not explain individual parameter semantics beyond the schema. That is acceptable given the high schema coverage.
Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.
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: 'Propose a new MCP server for the mcp.film directory.' It also clarifies the tool's role by listing validation behavior and the returned GitHub issue payload. Since no sibling tool handles submission, it is fully differentiated.
Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.
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: when proposing a new MCP server to the directory. It also provides practical guardrails ('never submit URLs or commands you haven't seen work'). It lacks an explicit 'do not use when...' clause, but the sibling list makes the submission context unambiguous.
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.
No comments yet. Be the first to start the discussion!
Sign in to create a connector for this server.