Search the curated directory of MCP servers for AI filmmaking and plan a full production stack.
Scored across 16 tools
Most tools are distinct, but there is meaningful overlap among recommendation surfaces: list_film_recommendations, get_film_recommendation, and recommend_film_mcps all concern recommendations, while plan_film_stack and recommend_film_mcps both return suggested server sets. Descriptions help, but an agent could still confuse list/get/recommend-by-brief patterns.
All tool names use snake_case and begin with a verb, so the overall convention is predictable. However, the 'film' resource marker is applied inconsistently across otherwise similar tools (get_film_recommendation vs get_catalog_pulse vs list_client_profiles), which is a minor deviation.
At 16 tools, the set is slightly above the ideal range but each tool maps to a distinct directory operation: discovery, detail, categories, capabilities, playbooks, recommendations, install setup, planning, and submission. The count is reasonable for a registry that supports search, planning, and installation.
The surface covers discovery, detail retrieval, recommendations, playbooks, capability/category browsing, install configuration, client profiles, sponsor setup, pipeline planning, and listing submission. Minor gaps like direct category-detail retrieval or richer profile inspection are unlikely to block core workflows.
Get the mcp.film operating pulse: catalog freshness, verification queue, curator agenda, and machine-readable surfaces. Use this before deciding what to update next. The curator/ops sections demand_signals and martini_growth_checks are opt-in by section and not part of 'all'.
| Name | Required | Description | Default |
|---|---|---|---|
| section | No | Optional top-level pulse section. Default all (which omits the curator/ops sections demand_signals and martini_growth_checks; request those by name). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover read-only, idempotent, closed-world and non-destructive semantics, so the description does not need to restate safety. It earns credit for disclosing a non-obvious behavioral quirk: the default 'all' silently omits demand_signals and martini_growth_checks, which must be requested by name. It does not describe response shape, but no output schema exists and the section list largely implies it.
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?
Three short sentences, no filler, with the identity of the tool front-loaded and the opt-in caveat placed immediately after the usage trigger. Every sentence carries information an agent needs.
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-required-param, read-only, single-enum tool with no output schema, the description gives enough to call it correctly and to understand which sections come back by default. Return-value detail is left implicit, which is the only real gap.
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% and the enum is fully documented, so the schema carries this dimension. The description's remark about 'all' omitting the curator/ops sections restates the schema's field description almost verbatim, adding emphasis rather than new meaning. Baseline 3 is appropriate.
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?
States a specific verb and resource ('Get the mcp.film operating pulse') and enumerates the contents: catalog freshness, verification queue, curator agenda, machine-readable surfaces. This distinguishes it from the get_film_*/list_film_* siblings, which are all single-object or listing tools. It stops short of naming a sibling to contrast with, so a 4 rather than 5.
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?
'Use this before deciding what to update next' gives a concrete decision context rather than vague guidance. The note about opt-in sections tells the agent how to narrow the call. No explicit when-not or named alternative, so not a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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 |
|---|---|---|---|
| limit | No | Page size, 1-100. Default 20. | |
| offset | No | Start index for paging; use next_offset from the previous call. | |
| 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?
Annotations already declare readOnly, idempotent, non-destructive and closed-world, so the safety profile is covered. The description adds only the word 'ranked' (results are ordered by some ranking) without saying what the ranking is based on, and says nothing about paging behavior beyond what the schema documents.
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?
One front-loaded sentence with no filler, and the most useful content (what the tool returns, plus example inputs) comes first. It is arguably slightly under-specified rather than over-long.
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 read-only lookup with a fully documented schema and no output schema, the description covers the core, but it omits two things an agent needs: where to get valid capability tags (list_film_capabilities) and what 'ranked' actually means for the returned cluster.
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 baseline is 3; the description earns an extra point by supplying concrete example capability values (text-to-video, tts, voice-cloning, upscaling), which effectively act as an informal enum where the schema has none. It still doesn't clarify whether tags are case-sensitive or free-form.
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?
States a specific verb and resource (get the ranked server cluster for one capability tag) and enumerates concrete example tags, so the agent knows exactly what comes back. It does not, however, distinguish itself from the sibling list_film_capabilities, which an agent could easily mistake for the same lookup.
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?
Usage is only implied: 'one capability tag' hints at single-tag lookup versus a listing tool, but no when-to-use/when-not guidance or explicit pointer to list_film_capabilities for discovering valid tags is given. With 15 siblings, some explicit routing would materially help.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get the full mcp.film entry for one server by slug: description, install commands, auth requirements, sample tools, links, field notes (caveats), and machine-checked evidence (evidence level, last_probe of the hosted endpoint, package_check).
| 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?
The annotations already establish that this is a safe, idempotent read operation. The description adds useful behavioral context by enumerating the returned data, including machine-checked evidence fields like evidence level, last_probe, and package_check, though it omits what happens when a slug is not found.
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 dense but well-structured sentence. The core action is front-loaded, and the returned fields are listed efficiently with no 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?
With only one parameter and a fully described schema, the description provides a clear inventory of what the returned entry contains. It does not explain error behavior for an invalid slug, but for a simple read-only lookup the definition is nearly complete.
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%, and the schema itself gives the slug format with examples. The description only confirms retrieval by slug, adding no further semantics beyond the structured field, so the baseline of 3 is appropriate.
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-resource pair: get the full mcp.film entry for one server by slug. It clearly distinguishes this single-entry lookup from sibling tools like search_film_mcps and list_film_categories by emphasizing one server identified by slug.
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 phrase 'by slug' clearly signals when to use this tool: when the server slug is already known. It does not explicitly contrast this with search_film_mcps or list tools, but the context is strong enough to guide selection.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get one production playbook by id, including primary servers, setup order, auth requirements, workflow steps, failure modes, fallback servers, constraints, and links to each server's mcp.film page. Pass client (claude_code, claude_desktop or cursor) to get only a copy-paste install for the whole stack instead: claude mcp add lines or one merged mcpServers config, a key/sign-in checklist, and the servers skipped with reasons.
| Name | Required | Description | Default |
|---|---|---|---|
| id | Yes | Playbook id, e.g. 'commercial-sprint' or 'local-edit-bay' | |
| client | No | Optional. Return the whole-stack install script for this client instead of the playbook. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnly, idempotent, and closed-world, and the description adds substantial context beyond them: exactly what sections the playbook contains (setup order, auth requirements, failure modes, fallback servers, constraints) and what the install-mode response includes (skipped servers with reasons). That is a rich disclosure of return content for a tool with no output schema.
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 the primary behavior and then the alternate mode; no filler. The long enumeration of returned sections is dense but each item adds information. Slightly heavy for a single sentence but justified by the missing output schema.
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?
No output schema exists, so the description must carry the return-shape burden, and it does so for both the default and client modes. With annotations covering the safety profile and 100% schema coverage on the two params, an agent has everything needed to call it 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?
Schema coverage is 100% with the id example and client enum already documented, so the baseline is 3. The description earns above baseline by explaining the semantic effect of client — it replaces the playbook with a whole-stack install script — which is more than the schema's 'instead of the playbook' phrasing conveys about the resulting content.
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?
States a specific verb and resource ('Get one production playbook by id') and enumerates the returned payload, so an agent can distinguish it from list_film_playbooks. It also covers the second mode. It does not explicitly name the sibling it overlaps with, get_install_config, so it falls short of full sibling differentiation.
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 client branch has clear conditional guidance ('Pass client ... to get only a copy-paste install for the whole stack instead'), which is genuinely useful. However, there is no guidance on when to pick this tool over get_install_config or plan_film_stack, nor any stated prerequisites. Usage for the default mode is only implied.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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?
Annotations already declare readOnlyHint, idempotentHint, openWorldHint=false and destructiveHint=false, so safety is covered. With no output schema, the description's enumeration of returned fields (roles, reasons, fallbacks, playbook, handoff guidance) is genuinely additive context, though it says nothing about behavior for an unknown or invalid id.
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?
A single front-loaded sentence with no filler; the verb and lookup key come first and the payload list follows. Slightly dense with domain jargon ('Martini handoff guidance') but every clause carries information.
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 single-parameter read tool with full annotation coverage, the description covers both the lookup semantics and the returned record's composition, which is needed since no output schema exists. Only error/not-found behavior is unaddressed.
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% and the schema itself supplies the id format with examples ('fast-commercial'). The description's 'by id' adds no syntax, format, or constraint detail beyond the schema, so the 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?
States a specific verb and resource ('Get one intent-routed recommendation by id') and even enumerates what the record contains (primary server roles, reasons, fallbacks, playbook, handoff guidance). The singular 'one ... by id' implicitly separates it from list_film_recommendations, but no sibling is named explicitly, so it falls short of the top band.
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 'by id' framing implies this is the lookup used once you already have an id from list_film_recommendations, but the description never states when to use it, when not to, or names the listing sibling. Usage is left to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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?
Annotations already declare readOnlyHint, idempotentHint, non-destructive and closed-world, so the safety profile is covered. The description usefully adds what the payload contains (env vars and auth type), which is real behavioral context an agent needs to know it may surface credential requirements, though it doesn't say whether live secret values are included.
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 tightly written sentences with the deliverable front-loaded and the supporting content (env vars, auth type) trailing. 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?
For a two-param read-only tool with no output schema and annotations covering safety, the description covers what is returned across all three output modes. The remaining gap is the ambiguous client enum values and slug sourcing, which the schema does not resolve either.
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 0%, so the description must carry the load — and it does partially: 'a server' maps to slug and 'MCP client profile' maps to client, and 'hosted remote URL' hints at the hosted_remote enum value. However, it never explains slug format/lookup or the distinction between hosted_remote and generic_remote, so two undocumented params remain only half-explained.
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?
States a specific verb (get) and resource (install config) and enumerates the three output forms it can return: install command, JSON config, or hosted remote URL. That makes its scope clear against siblings like get_film_mcp or list_client_profiles, though it never explicitly names a sibling to differentiate from.
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?
Usage is only implied: the mention of 'a server and MCP client profile' tells the agent the inputs it needs, but there is no when-to-use, no when-not-to-use, and no routing against alternatives such as plan_film_stack or get_film_mcp. Adequate but leaves the agent to infer the trigger condition.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Ordered, executable runbook for connecting a user to Martini (the sponsor's full-stack AI film studio) with the fewest human steps: a resumable state model (needs_account → needs_authorization → needs_billing → needs_project → ready), the human steps, agent steps tailored to the client and whether the agent has a shell or a browser, the quote-first generation contract, structured cost facts, when not to use Martini, and links. Facts verified 2026-10-26.
| Name | Required | Description | Default |
|---|---|---|---|
| client | No | The MCP client the user is in. Default other. | |
| has_shell | No | Can the agent run commands (npm, martini CLI)? Default false. | |
| can_open_browser | No | Can the agent itself complete a browser OAuth sign-in (attach a connector)? Default false: the human does it. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
While annotations confirm it is a safe, read-only operation, the description adds significant behavioral detail by defining the output structure (resumable state model, tailoring to agent capabilities, structured cost facts). This provides much richer context than the hints alone.
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 dense and slightly verbose, listing every component of the runbook (state model, contract, links). However, this high level of detail is necessary to manage user expectations for such a complex, multi-part setup guide. It is not overly concise but is highly effective.
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 is exceptionally complete for a setup tool. It covers the specific goal, the required variables, the format of the output, and its operational constraints (e.g., agent capabilities like shell/browser access). Nothing critical is missing.
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?
With schema coverage at 100%, the parameters are fully defined in the input schema. The description does not add any semantic meaning or deeper explanation beyond what is already provided in the structured input definitions. This aligns with the baseline score for high 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 states the tool provides an 'Ordered, executable runbook for connecting a user to Martini'. It is highly specific and distinguishes its function (setup/connection runbooks) from the general film/MCP tools in the sibling list.
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 includes explicit guidance on 'when not to use Martini,' which is helpful for routing the user. However, it does not compare this setup guide against all relevant sibling tools like get_install_config or plan_film_stack, leaving a small gap in exclusion criteria.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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?
Annotations already declare readOnlyHint=true, idempotentHint=true, destructiveHint=false, and openWorldHint=false, so the safety profile is fully covered. The description adds the useful fact that the result is a fixed, closed set of four generateable profiles. It does not, however, clarify whether the list is static or environment-dependent, nor describe return shape.
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?
A single front-loaded sentence with no filler. The enumerations of concrete profiles add real information rather than restating the name, and nothing could be trimmed without losing content.
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 usefully enumerates the four profile names an agent will receive, which partly substitutes for a return-type definition. Combined with annotations covering safety and the trivial zero-parameter schema, an agent has enough to call it correctly; only the static-vs-dynamic nature of the list is left unstated.
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 takes zero parameters, which is the baseline-4 case; there is nothing for the description to document. Schema coverage is 100% and the empty schema matches the parameterless description, so no compensation is needed.
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?
Specific verb ('List') plus a precise resource ('MCP client setup profiles mcp.film can generate'), and it enumerates the concrete values (Claude Code, Claude Desktop, Cursor, hosted remote clients). This is clearly distinguishable from sibling listing tools such as list_film_capabilities or list_film_categories, which cover different resources.
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?
Usage is implied: call this when you need to know which client configuration profiles are available. There is no explicit when-to-use statement, no prerequisites, and no named alternative (e.g. get_install_config, which likely operates on one of these profiles). Implied-only guidance places it at the minimum viable level.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List capability tags in the mcp.film registry, ranked by number of matching servers (tag, page url, counts). Paged. Use get_film_capability for the server cluster behind one tag.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-100. Default 50. | |
| query | No | Optional substring filter, e.g. 'video', 'voice', or 'timeline'. | |
| offset | No | Start index for paging; use next_offset from the previous call. | |
| min_count | No | Only include capability tags with at least this many servers. Default 2 (tags with a published page). |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover readOnly/idempotent/non-destructive, so credit goes to what the description adds: ranking order (by number of matching servers), pagination behavior, and the shape of returned records. It does not state the registry's update cadence or whether counts are live, but for a read-only listing that is a minor gap.
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?
Three short sentences, verb and scope front-loaded, return fields and the sibling handoff packed without waste. Nothing redundant with the title or schema.
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?
No output schema exists, and the description compensates by enumerating the returned fields (tag, page url, counts) — an important disclosure. Combined with paging and ranking, an agent has enough to call and interpret results; only edge behavior (empty result, max offset) is unstated.
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%, so all four parameters are already documented in-schema; the description adds only the concept of paging and ranking-down by count. No additional meaning about how query interacts with ranking or how min_count affects the default page is supplied beyond the 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?
Specific verb+resource+scope: 'List capability tags in the mcp.film registry, ranked by number of matching servers', and it even declares the returned fields (tag, page url, counts). It names the sibling get_film_capability and the distinction (cluster behind one tag), so an agent can route without opening either schema.
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?
Explicitly routes to get_film_capability for per-tag detail, which is the main alternative an agent would confuse this with. No when-not-to-use guidance is given (e.g. use search_film_mcps for finding servers directly), but the alternative named is the relevant one for this listing's ambiguity.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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?
Annotations already declare readOnly, idempotent, non-destructive, and closed-world, so the safety profile is fully covered. The description adds the useful detail of what is returned (ids, pipeline stage, hints), but says nothing about ordering, caching, or refresh behavior, which matters for a reference listing.
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?
A single sentence that front-loads the resource and immediately names the payload, with no filler or restatement of the title.
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 read-only listing with rich annotations, the definition is nearly sufficient. The remaining gap is that there is no output schema and the description does not explain what 'pipeline stage' or 'agent hints' actually contain, so the agent knows the fields exist but not their meaning.
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 takes zero parameters, so there is nothing for the description to disambiguate; the schema is empty and 100% covered. Baseline 4 applies for a no-parameter tool.
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?
States a specific verb and resource ('List all mcp.film categories') and even enumerates the returned fields (ids, pipeline stage, agent hints). The resource name distinguishes it from siblings like list_film_capabilities and list_film_playbooks, though it does not explicitly say what makes categories different from those lists.
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?
Usage is only implied: because it returns pipeline stage and agent hints, an agent can infer it is a discovery/reference call, but there is no explicit when-to-use statement or pointer to alternatives such as get_film_capability or get_film_playbook.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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, auth requirements and constraints.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-100. Default 20. | |
| query | No | Optional free-text search over title, summary, best_for, constraints, and server names. | |
| offset | No | Start index for paging; use next_offset from the previous call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already declare readOnlyHint, idempotentHint, destructiveHint=false and openWorldHint=false, so the safety profile is covered. The description adds useful content context (setup order, failure modes, Martini handoff guidance) but says nothing about pagination behavior, result ordering, or what an empty list means beyond what the schema implies.
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 what the tool returns and followed by the routing instruction. Every clause earns its place; there is no filler or repetition of the title.
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 read-only list tool with complete schema descriptions and no output schema, the description covers purpose, content, and the handoff to the detail tool. It could mention pagination or result ordering, but the schema already defines paging parameters well enough for correct 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?
Schema description coverage is 100%, with clear descriptions for limit (page size 1-100, default 20), query (free-text fields searched), and offset (use next_offset). The description adds no parameter semantics beyond the schema, so the 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 states a specific verb (List) and resource (mcp.film production playbooks) and immediately defines what they are: curated MCP stacks for AI filmmaking jobs with setup order, failure modes, and Martini handoff guidance. It explicitly distinguishes itself from the sibling get_film_playbook, which returns full steps and constraints.
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 names the alternative tool directly: 'Use get_film_playbook for full steps, auth requirements and constraints,' which gives a clear selection rule between listing and fetching details. It doesn't address other siblings like plan_film_stack or recommend_film_mcps, leaving some ambiguity about when a playbook list versus a plan or recommendation is appropriate.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
List 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 |
|---|---|---|---|
| limit | No | Page size, 1-100. Default 20. | |
| query | No | Optional free-text search over titles, summaries, best_for text, tags, server names, and Martini handoff guidance. | |
| offset | No | Start index for paging; use next_offset from the previous call. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
The annotations already declare a safe, idempotent read with no destructive or open-world side effects. The description adds useful behavioral context by stating the return content includes reasons, fallbacks, and Martini handoff guidance, though it does not discuss pagination or rate limits (which the schema's offset/limit fields partly cover).
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 tight sentences: the first front-loads the purpose and content, the second gives the routing alternative. 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?
With annotations covering safety, schema documenting all three parameters, and the description explaining the returned content, an agent has enough to invoke correctly. The absence of an output schema is compensated by the description's mention of reasons, fallbacks, and handoff guidance.
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%, so the baseline is 3; the description does not mention limit, query, or offset, leaving their semantics entirely to the schema. No additional meaning is added beyond structured fields.
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 states a concrete verb ('List') and a well-scoped resource ('mcp.film intent-routed recommendations'), then elaborates what the list contains ('ranked MCP shortlists for common filmmaking jobs, with reasons, fallbacks, and Martini handoff guidance'). It also explicitly distinguishes itself from get_film_recommendation, so an agent can route correctly 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
It names get_film_recommendation as the alternative for full detail, giving clear context for choosing between summary and detail. It stops short of enumerating when-not-to-use or comparing against every sibling such as recommend_film_mcps, so a 4 rather than a 5.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Get 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, taglines and descriptions).
| Name | Required | Description | Default |
|---|---|---|---|
| brief | No | Optional: what you're making, e.g. 'a 60s commercial with a consistent character and licensed music' | |
| include_inactive | No | Also consider servers whose status is dead, archived or deprecated. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish read-only, idempotent, non-destructive, closed-world behavior. The description adds useful behavioral detail beyond that: returns are 1-3 picks per stage, ranked by official status and hosting, and briefs are matched against capabilities, taglines and descriptions. It does not cover rate limits or auth, but those are less central for a read-only 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 three tight sentences with no wasted wording. The core purpose and scope are front-loaded, followed by return shape and brief behavior.
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 recommendation tool with full schema coverage and no output schema, the description provides enough context about scope, return cardinality, ranking logic and brief matching. An agent can call it correctly without needing additional prose.
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%, so the baseline is 3. The description adds real semantic value for the brief parameter by explaining that it is matched against capabilities, taglines and descriptions, which goes beyond the schema example.
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 states a specific verb and resource: get a recommended set of MCP servers covering the full film pipeline. It also specifies the pipeline stages and return cardinality. It does not name or distinguish itself from close siblings like recommend_film_mcps or get_film_recommendation, so it falls 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.
Does the description explain when to use this tool, when not to, or what alternatives exist?
The full-pipeline framing implies when this tool is appropriate, and passing a brief is explained as a way to bias picks. However, there is no explicit when-not guidance and no direct comparison to sibling recommendation tools, leaving the agent to infer the best alternative.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Given a filmmaking brief, return the closest intent-routed MCP recommendations: one compact pick per primary server (slug, role, why, remote, official, verified) plus compact fallbacks. Use hosted_only=true when the agent cannot spawn local tools; get_film_mcp for full server detail.
| 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' | |
| verbosity | No | compact (default): one small object per pick in primary/primary_servers and fallback_servers. full: the complete server objects, as before. | |
| constraints | No | Hard constraints applied before relevance. Also inferred from the brief ('locally', 'without uploading', 'confidential', 'offline', 'no budget', 'free', 'no local install'). Picks that violate one are excluded; if nothing survives, unsatisfied_constraints explains why. | |
| hosted_only | No | Only return hosted remote primary/fallback servers where possible. | |
| include_inactive | No | Also consider servers whose status is dead, archived or deprecated. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already cover the safety profile (readOnly, idempotent, non-destructive), so the description earns credit for going further: it discloses that results are one compact pick per primary server with compact fallbacks, and that fallbacks exist as a concept. It doesn't explain pagination, result limits, or what happens when nothing matches, which is the main remaining gap.
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 the trigger condition and resource, followed by the return shape and the escalation path. No sentence is redundant with the name or title.
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 does the work of naming the returned fields (slug, role, why, remote, official, verified) plus fallbacks, which is enough to act on. It omits the unsatisfied_constraints failure mode and the inactive/deprecated filtering behavior, both of which matter for interpretation.
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 meaning beyond the schema by tying hosted_only to a specific agent situation ('cannot spawn local tools'), which the schema merely restates as a filter, and by clarifying that verbosity controls the compact per-pick object shape.
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?
States a specific verb and resource: given a filmmaking brief, return intent-routed MCP recommendations, including the shape of each pick. It does not distinguish itself from near-siblings like get_film_recommendation or plan_film_stack, so an agent must infer the boundary itself.
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?
Gives a concrete conditional rule ('Use hosted_only=true when the agent cannot spawn local tools') and routes to a named sibling ('get_film_mcp for full server detail'). It stops short of saying when NOT to use this tool versus the other recommendation/planning siblings.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Search the mcp.film directory of MCP servers for AI filmmaking. Filter by free-text query (matches name, vendor, tagline, description, capabilities, tools, category, pricing, auth, and the creative apps a server drives by name or alias, e.g. 'c4d' or 'resolve'), category id, or capability. Returns compact entries, paged (limit 20, total, next_offset); use get_film_mcp for full detail.
| Name | Required | Description | Default |
|---|---|---|---|
| limit | No | Page size, 1-100. Default 20. | |
| query | No | Free-text search, e.g. 'upscale video' or 'voice cloning' | |
| offset | No | Start index for paging; use next_offset from the previous call. | |
| 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 | |
| answering_only | No | Only listings whose hosted endpoint answered mcp.film's anonymous MCP check in the last 7 days (evidence: endpoint_answered; a sign-in challenge counts as answering). | |
| include_inactive | No | Also return listings whose status is dead, archived or deprecated. Default false. |
Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?
Annotations already establish that this is a safe, read-only, idempotent search. The description adds useful behavioral context: results are compact, paged with limit 20, total, and next_offset, and the free-text query matches many fields including creative app aliases.
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 front-loaded and dense with useful information: search scope, filter types, return format, paging, and the sibling alternative. No sentence is wasted.
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 nine optional parameters and no output schema, the description does enough by explaining the compact paged return shape and the detail alternative. The remaining filter semantics are covered by the fully populated input 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?
Schema coverage is 100%, so the baseline is 3. The description still adds value by explaining the breadth of free-text matching and the aliases it covers, and by clarifying the paged return shape with limit, total, and next_offset.
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 states a specific verb and resource: search the mcp.film directory of MCP servers for AI filmmaking. It also distinguishes the tool from the detail-oriented sibling by saying to use get_film_mcp for 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?
It clearly indicates the search use case and names get_film_mcp as the alternative for full detail. It does not explicitly contrast with recommend_film_mcps or plan_film_stack, but the context is still clear.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Propose 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?
Despite readOnlyHint=true, the description goes well beyond annotations: it explains that validation runs against schema and the live registry, that duplicate detection occurs, and that it returns three ready-to-file payload forms (REST body, gh CLI command, browser URL). It also clarifies the crucial behavioral nuance that submissions are claims and a maintainer verifies independently, which resolves any ambiguity between the name 'submit' and the read-only annotation.
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?
Three tight sentences, front-loaded with what the tool does before the caveats. The middle sentence is dense but each clause carries distinct information; nothing is redundant.
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 valuably describes the return payload structure, which the agent would otherwise have to guess. It omits what a validation failure returns and whether partial validation errors are surfaced, but for a 10-param tool with 90% schema coverage and no output schema, this is close to complete.
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 90%, so the schema already documents the 10 fields thoroughly, making a 3 the baseline. The description adds indirect semantics (the link is the primary source, the install command must be verified working) but does not explain parameter formats or the meaning of the pricing enum beyond what the schema 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?
States a specific verb and resource ('Propose a new MCP server for the mcp.film directory') and immediately distinguishes itself from the read/list siblings by describing its validate-then-return-payload behavior. No other sibling creates or proposes listings, so the role is 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?
Usage is implied (use this when you want to propose a server that isn't listed) and one constraint is given ('never submit URLs or commands you haven't seen work'), plus it notes duplicate detection happens inside the tool. However it never states when-not to use it or names an alternative (e.g. search_film_mcps first), leaving routing to inference.
Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.
Recent tool additions, removals, and schema changes observed during successful MCP inspections.
get_film_playbook1 field changedInput schema / properties / clientAdded value: +{
+ "description": "Optional. Return the whole-stack install script for this client instead of the playbook.",
+ "enum": [
+ "claude_code",
+ "claude_desktop",
+ "cursor"
+ ],
+ "type": "string"
+}search_film_mcps1 field changedInput schema / properties / answering_onlyAdded value: +{
+ "description": "Only listings whose hosted endpoint answered mcp.film's anonymous MCP check in the last 7 days (evidence: endpoint_answered; a sign-in challenge counts as answering).",
+ "type": "boolean"
+}get_catalog_pulse2 fields changedInput schema / properties / section / descriptionPrevious value: -"Optional top-level pulse section. Default all."New value: +"Optional top-level pulse section. Default all (which omits the curator/ops sections demand_signals and martini_growth_checks; request those by name)."Input schema / properties / section / enumPrevious value: -[
- "all",
- "summary",
- "demand_signals",
- "curator_agenda",
- "martini_growth_checks",
- "verification_queue",
- "machine_surfaces"
-]New value: +[
+ "all",
+ "summary",
+ "curator_agenda",
+ "verification_queue",
+ "machine_surfaces",
+ "demand_signals",
+ "martini_growth_checks"
+]get_film_capability2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Page size, 1-100. Default 20.",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Start index for paging; use next_offset from the previous call.",
+ "type": "number"
+}get_martini_setuplist_film_capabilities3 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Page size, 1-100. Default 50.",
+ "type": "number"
+}Input schema / properties / min_count / descriptionPrevious value: -"Only include capability tags with at least this many servers. Default 1."New value: +"Only include capability tags with at least this many servers. Default 2 (tags with a published page)."Input schema / properties / offsetAdded value: +{
+ "description": "Start index for paging; use next_offset from the previous call.",
+ "type": "number"
+}list_film_playbooks2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Page size, 1-100. Default 20.",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Start index for paging; use next_offset from the previous call.",
+ "type": "number"
+}list_film_recommendations2 fields changedInput schema / properties / limitAdded value: +{
+ "description": "Page size, 1-100. Default 20.",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Start index for paging; use next_offset from the previous call.",
+ "type": "number"
+}plan_film_stack1 field changedInput schema / properties / include_inactiveAdded value: +{
+ "description": "Also consider servers whose status is dead, archived or deprecated. Default false.",
+ "type": "boolean"
+}recommend_film_mcps3 fields changedInput schema / properties / constraintsAdded value: +{
+ "description": "Hard constraints applied before relevance. Also inferred from the brief ('locally', 'without uploading', 'confidential', 'offline', 'no budget', 'free', 'no local install'). Picks that violate one are excluded; if nothing survives, unsatisfied_constraints explains why.",
+ "properties": {
+ "free_only": {
+ "description": "Only free or freemium pricing.",
+ "type": "boolean"
+ },
+ "has_shell": {
+ "description": "false means the agent cannot run local processes; implies hosted_only.",
+ "type": "boolean"
+ },
+ "hosted_only": {
+ "description": "Only hosted remote MCP endpoints.",
+ "type": "boolean"
+ },
+ "local_only": {
+ "description": "Only servers with a local install path (stdio or local app).",
+ "type": "boolean"
+ },
+ "no_upload": {
+ "description": "Only local servers with no cloud credential, so media never leaves the machine.",
+ "type": "boolean"
+ },
+ "os": {
+ "description": "macos | windows | linux; excludes listings that say they only run elsewhere.",
+ "type": "string"
+ }
+ },
+ "type": "object"
+}Input schema / properties / include_inactiveAdded value: +{
+ "description": "Also consider servers whose status is dead, archived or deprecated. Default false.",
+ "type": "boolean"
+}Input schema / properties / verbosityAdded value: +{
+ "description": "compact (default): one small object per pick in primary/primary_servers and fallback_servers. full: the complete server objects, as before.",
+ "enum": [
+ "compact",
+ "full"
+ ],
+ "type": "string"
+}search_film_mcps3 fields changedInput schema / properties / include_inactiveAdded value: +{
+ "description": "Also return listings whose status is dead, archived or deprecated. Default false.",
+ "type": "boolean"
+}Input schema / properties / limitAdded value: +{
+ "description": "Page size, 1-100. Default 20.",
+ "type": "number"
+}Input schema / properties / offsetAdded value: +{
+ "description": "Start index for paging; use next_offset from the previous call.",
+ "type": "number"
+}get_catalog_pulseget_film_capabilityget_film_mcpget_film_playbookget_film_recommendationget_install_configlist_client_profileslist_film_capabilitieslist_film_categorieslist_film_playbookslist_film_recommendationsplan_film_stackrecommend_film_mcpssearch_film_mcpssubmit_listingSearch and install 4,000+ security-scanned MCP servers from inside any MCP-aware AI client.
AI tool directory MCP server, live since July 2026. Tools, agents, models, companies, services.
MCP server for Luma Dream Machine AI video generation
Quality-ranked, cross-platform directory of AI coding skills, plugins and MCP servers.
Add one secure layer between your agents and this server.
