How do I use @crewone/mcp-server?

1. Click on "Install Server". 2. Wait a few minutes for the server to deploy. Once ready, it will show a "Started" state. 3. In the chat, type @ followed by the MCP server name and your instructions, e.g., "@@crewone/mcp-server How much does a Sony FX6 rent for per day in Taipei?" That's it! The server will respond to your query, and you can continue using it as needed. Here is a step-by-step guide with screenshots.

@crewone/mcp-server

by tzipway-dotcom

Overview Schema Related Servers Score Discussions

JavaScript

Local

@crewone/mcp-server

MCP (Model Context Protocol) server for CrewOne. Lets Claude Desktop, Cursor, Continue, Cline, and any other MCP-aware AI agent query Taiwan film equipment rates, studio rentals, photographer style references, MV/commercial director references, and (with API key) generate full pre-production packages.

npm license

What is this

CrewOne maintains a structured database of:

1,187 real Taipei film equipment rental rates (cameras, lenses, lighting, grip, sound)
561 real Taiwan studio rates with size, ceiling, lighting, power, parking
69 commercial / fashion / portrait photographer style references with on-set lighting hallmarks and AI prompt tokens
30+ MV and commercial director style references with prompt tokens for video generation models

This MCP server exposes that data (and the generative pipeline) to AI agents. When you ask Claude Desktop "how much does an FX6 rent for in Taipei" or "give me a Tim Walker–style lighting setup", the agent calls this server, gets a real answer, and replies.

Related MCP server: agnes-mcp

Two tiers of tools

Free (no API key required)

These work as soon as the server is installed. Rate-limited server-side.

search_equipment(query, category) — find Taipei rental rates
search_studios(size_pings, max_budget_per_4h, amenities, location) — find Taiwan studios
get_photographer(name) — pull style reference for a specific photographer
list_photographers(region, cluster) — browse the 69-photographer library
get_director(name) — director reference
list_directors(region, genre) — browse the director library

Paid (requires `CREWONE_API_KEY`)

These consume credits from your CrewOne plan.

create_project(brief, type, photographer_references?) — full package generation, 1 credit
get_project(project_id) — fetch existing project
export_pdf(project_id) — get PDF download URL

Get your API key at https://crewone.ai/dashboard/settings/api after signing up.

Install

Claude Desktop

Add to ~/Library/Application Support/Claude/claude_desktop_config.json (macOS) / %APPDATA%\Claude\claude_desktop_config.json (Windows):

{
  "mcpServers": {
    "crewone": {
      "command": "npx",
      "args": ["-y", "@crewone/mcp-server"],
      "env": {
        "CREWONE_API_KEY": "your-key-here-or-omit-for-free-tools-only"
      }
    }
  }
}

Restart Claude Desktop. CrewOne tools will appear in the tool palette.

Cursor

Add to ~/.cursor/mcp.json:

{
  "mcpServers": {
    "crewone": {
      "command": "npx",
      "args": ["-y", "@crewone/mcp-server"],
      "env": { "CREWONE_API_KEY": "..." }
    }
  }
}

Continue

In ~/.continue/config.json, add to the experimental.modelContextProtocolServers array:

{
  "transport": { "type": "stdio", "command": "npx", "args": ["-y", "@crewone/mcp-server"] },
  "env": { "CREWONE_API_KEY": "..." }
}

Cline / any other MCP client

Same npx -y @crewone/mcp-server command pattern. Set CREWONE_API_KEY if you want paid tools.

Example prompts

After installing, try these in your AI chat:

Free tier

"How much does a Sony FX6 rent for per day in Taipei?"
"Find me a 8-ping studio in Taipei under NT$ 4,000 per 4 hours with cyc wall."
"Give me Tim Walker's lighting hallmarks and AI prompt tokens for a fashion editorial shoot."
"List all Japanese photographers in CrewOne's library that lean into surreal high-saturation."

Paid tier (needs API key)

"Create a CrewOne project: 30-second commercial for a Taiwan coffee brand, hero shot pour, three location options."
"Get my CrewOne project abc-123 and summarise the call sheet."

Configuration

Env var	Default	Purpose
`CREWONE_API_KEY`	(none)	Required for paid tools. Generate at https://crewone.ai/dashboard/settings/api.
`CREWONE_API_BASE`	`https://crewone.ai`	Override for local dev / staging.

Privacy

The MCP server runs entirely on your local machine. Your prompts go from the AI client to this server (stdio) to crewone.ai HTTPS endpoints. CrewOne does not log MCP-originated requests differently from web requests. Free-tier tool calls are anonymous (no auth). Paid-tier calls are tied to your account via the API key.

Source

Open-source MIT, https://github.com/tzipway-dotcom/crewone-mcp-server

Pricing

CrewOne plans:

Free trial: 2 generations
Project Pack: $12 one-time, 1 credit
Director: $24-29 / month, 4 credits / month
Studio: $89-109 / month, 20 credits / month
Founding Member: $15.84 / month lifetime (limited to first 25 sign-ups)

Free MCP tools (search_equipment, search_studios, get_photographer, etc.) do not consume credits. Only create_project and other generative tools do.

Troubleshooting

Tools don't appear in Claude Desktop — verify claude_desktop_config.json JSON is valid; restart Claude Desktop fully.
Error: 401 — API key invalid; regenerate at https://crewone.ai/dashboard/settings/api.
Insufficient credits — top up via https://crewone.ai/pricing.
Free tools work but paid tools fail — confirm CREWONE_API_KEY is set in the env block of your MCP config.

License

MIT — © Way Directs.

Available Tools

6 tools

get_directorA

Look up a single director in the CrewOne 30-MV-director and Taiwan-commercial-director reference library. Returns AI prompt tokens for video generation models (Veo, Kling, Higgsfield), representative works, and signature techniques.

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Director name in English or Traditional Chinese.

TDQS

A4.3/5.0

Behavior4/5

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

The description discloses key behavioral output (AI prompt tokens, representative works, signature techniques) and the 'look up' verb indicates a non-destructive read. However, it does not explicitly state side-effect freeness, auth requirements, or rate limits, which is a minor gap for a lookup tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences, front-loaded with the main purpose, and efficiently includes necessary return details without any waste. Each sentence earns its place.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness5/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the tool's simplicity (one param, no output schema, no annotations), the description is complete. It explains the lookup scope, the source library, and the exact return values, covering all essential context for an agent.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema fully describes the single parameter 'name' as 'Director name in English or Traditional Chinese' (100% coverage). The description does not add any additional meaning beyond referencing the library scope, so the baseline of 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb ('look up') and resource ('single director... reference library'), clearly distinguishing it from siblings like list_directors and get_photographer. It also specifies the two included collections, adding precision.

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

Usage Guidelines4/5

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

The description clearly implies when to use this tool (when needing a single director's details), but it does not explicitly mention alternatives or exclusions. Sibling tools like list_directors are not named, so guidance is clear but not fully explicit.

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

get_photographerA

Look up a single photographer in the CrewOne 69-photographer style reference library. Returns hallmarks (lighting / palette / composition), AI prompt tokens for image generators, and representative works. Use this when a user asks for a specific photographer style (e.g. "Tim Walker style portrait", "蜷川實花 lighting").

ParametersJSON Schema

Name	Required	Description	Default
`name`	Yes	Photographer name in English or Traditional Chinese (e.g. "Tim Walker", "Annie Leibovitz", "Mika Ninagawa", "蜷川實花", "Chen Man", "陳曼", "Leslie Zhang").

TDQS

A4.2/5.0

Behavior4/5

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. It reveals what the tool returns (hallmarks, lighting/palette/composition, prompt tokens, representative works) and implies a read-only lookup. It doesn't mention behavior for unmatched names or partial matches, but for a simple lookup this is reasonable coverage.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two sentences: the first states the function and outputs, the second gives usage context and examples. Every word contributes value, with no repetition or filler.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a single-parameter lookup tool with no annotations and no output schema, the description covers purpose, usage, and return contents, which is largely complete. However, it does not describe behavior for invalid or missing photographer names, which is a minor gap for a complete mental model.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The input schema covers the single parameter fully (name with detailed description and examples), so schema coverage is 100%. The description adds contextual examples but no additional semantic information beyond what the schema already provides, earning the baseline score of 3.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses a specific verb and resource ('Look up a single photographer in the CrewOne 69-photographer style reference library') and enumerates concrete outputs (hallmarks, AI prompt tokens, representative works). This clearly distinguishes it from sibling tools like list_photographers or search_equipment.

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

Usage Guidelines4/5

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

It explicitly states when to use the tool ('Use this when a user asks for a specific photographer style') with concrete examples. It does not mention when not to use it or explicitly name alternatives like list_photographers, so it falls just short of fully explicit guidance.

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

list_directorsB

Browse the director reference library. Filter by region or genre.

ParametersJSON Schema

Name	Required	Default
`genre`	No	all
`region`	No	all
`max_results`	No

TDQS

B3/5.0

Behavior2/5

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

With no annotations, the description must fully disclose behavior. It mentions filtering and implies read-only browsing, but omits pagination, max_results limits, ordering, and return fields. This is insufficient for a zero-annotation tool.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is two concise sentences with no filler. It front-loads the primary purpose and immediately indicates the filtering dimensions.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness2/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

Given the simple parameter structure and absence of annotations and output schema, the description should explain more. It does not mention output format, pagination, or enum meanings, leaving users underinformed.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters2/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The description explains that genre and region are filters, adding meaning to two of three parameters. However, it does not clarify the semantic meaning of enum values (e.g., 'mv', 'k-pop') and completely omits max_results. With 0% schema coverage, this leaves significant gaps.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly identifies the tool as a browse/list operation for the director reference library, with filtering by region or genre. It distinguishes itself from sibling tools by focusing on directors and implies a list action, though 'browse' is slightly less specific than 'list'.

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

Usage Guidelines3/5

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

The description implies usage for browsing directors but provides no explicit guidance on when to use this tool versus alternatives such as get_director for individual details. No exclusions or decision criteria are given.

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

list_photographersB

Browse the 69-photographer style reference library. Filter by region, cluster (lighting style group), or country.

ParametersJSON Schema

Name	Required	Description	Default
`region`	No		all
`cluster`	No	Optional cluster filter, e.g. "hard-flash glamor", "soft natural-window B&W", "painterly soft-focus", "high-saturation surrealism".
`max_results`	No

TDQS

B3.1/5.0

Behavior2/5

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

No annotations are provided, so the description must carry the full burden of behavioral disclosure. It states the library size and the available filter dimensions, but it does not describe the return shape, how max_results affects output, or what happens when no filters are supplied. It also does not explicitly confirm this is a read-only operation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is a single sentence that front-loads the resource and action, with no redundant words. Every phrase adds useful context, making it compact and easy to parse.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a relatively simple list tool with three optional parameters and no output schema, the description is adequate but leaves gaps. It does not mention max_results, does not specify what fields are returned, and the 'country' versus 'region' mismatch is a minor inconsistency. These omissions make it functional but not fully complete.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema covers only 33% of parameters with descriptions (only cluster has an explicit description). The description adds a helpful gloss for cluster ('lighting style group') and mentions 'country' as a filter concept, which loosely maps to the region enum. However, it does not explain max_results or the exact enum values for region, so it only partially compensates for the low schema coverage.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description uses the verb 'browse' and names a specific resource ('photographer style reference library'), and lists filtering dimensions. This distinguishes it from sibling tools like get_photographer or list_directors. However, it mentions 'country' as a filter, which is not a named parameter in the schema, creating slight ambiguity.

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

Usage Guidelines2/5

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

There is no explicit guidance on when to use this tool versus alternatives like search_equipment or get_photographer. The description implies a read-only browsing use case, but it does not state exclusions, prerequisites, or reference any sibling tools.

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

search_equipmentA

Search the CrewOne database of Taipei film equipment rental rates (1,187 SKUs covering camera bodies, lenses, lighting, grip, sound, monitors). Returns matching items with day rates in TWD. Free to use; no API key required.

ParametersJSON Schema

Name	Required	Description
`query`	Yes	Search term, e.g. "Sony FX6", "85mm prime", "ARRI SkyPanel". Can be in English or Traditional Chinese.
`category`	No	Optional: narrow to a specific category.
`max_results`	No

TDQS

A4.2/5.0

Behavior4/5

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

No annotations exist, so the description carries the full burden. It discloses the key behavioral aspects: it returns matching items with day rates, is free, and requires no API key. It does not explain ordering, pagination, or result limits, but for a simple read-only search, the essential behavior is covered.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Three sentences, with the main action and resource front-loaded. Every sentence adds relevant information (scope, return value, access), with no filler or redundancy.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with one required parameter and no output schema, the description explains what is searched and what is returned, and mentions access requirements. It does not describe the output format or any sorting options, but these are not critical for a basic search tool and are partly inferable from the schema and tool name.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

The schema already provides descriptions for query and category, covering 67% of parameters. The description adds context about the database size and categories, but it does not add meaningful detail about max_results beyond its obvious default. This is acceptable given moderate schema coverage, so a baseline of 3 is appropriate.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states a specific verb ('Search') and resource ('CrewOne database of Taipei film equipment rental rates'), and further specifies the scope (1,187 SKUs, categories, day rates in TWD). This makes it unmistakable and distinguishes it from the sibling tools, which cover studios, photographers, and directors.

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

Usage Guidelines4/5

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

The description implicitly guides use by identifying the exact domain (equipment rental) and the return value (day rates), which differentiates it from siblings. It also states 'Free to use; no API key required,' providing access prerequisites. However, it does not explicitly mention when not to use this tool or name alternatives, so it falls short of a 5.

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

search_studiosA

Search the CrewOne database of Taiwan studios (561 studios with real rates and amenities). Returns matching studios with hourly / 4hr / day rates and key features (size, ceiling height, lighting, power, parking). Free to use.

ParametersJSON Schema

Name	Required	Description
`location`	No	Geographic filter, e.g. "Taipei", "New Taipei", "Taoyuan".
`amenities`	No	Required amenities, e.g. ["cyc wall", "blackout", "drive-in", "kitchen"].
`size_pings`	No	Minimum studio size in 坪 (1 ping ≈ 3.3 m²).
`max_results`	No
`max_budget_per_4h`	No	Maximum 4hr rate in TWD.

TDQS

A4/5.0

Behavior3/5

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

No annotations are provided, so the description carries the burden. It discloses that it returns specific data (rates, key features) and that it's free, but doesn't mention pagination, sorting, filtering logic, or read-only nature. The 'Search' implies read-only, but more explicit disclosure would be helpful.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness5/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The description is compact and front-loaded with the core purpose. Each sentence adds value: the first defines the resource, the second explains the return content, the third notes cost. No wasted words.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a search tool with 5 optional parameters and good schema coverage, the description provides sufficient context about what results include and the free access. It lacks guidance on default behavior (e.g., max_results default) but that's in the schema. Overall complete enough for a filtered search.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters3/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema coverage is 80% (4 of 5 params have descriptions). The description adds no extra parameter detail beyond what the schema already provides, and doesn't clarify relationships like AND/OR logic. Baseline 3 is appropriate since the schema handles most parameter semantics.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description clearly states the action ('Search') and the specific resource ('CrewOne database of Taiwan studios'), making it distinct from sibling tools like search_equipment or list_photographers. Additional context (561 studios, rates, features) further clarifies scope.

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

Usage Guidelines4/5

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

While it doesn't explicitly name alternatives or exclusions, it clearly implies when to use: when searching for studios in Taiwan with specific criteria. The mention of 'Free to use' and returns of rates/features provides practical usage context.

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

Tool Schema Changelog

Recent tool additions, removals, and schema changes observed during successful MCP inspections. Dates show when Glama detected each change.

6 tool updatesv0.1.0Aug 4, 2026
- First observedget_director
- First observedget_photographer
- First observedlist_directors
- First observedlist_photographers
- First observedsearch_equipment
- First observedsearch_studios

Install Server

RayrunBuild, deploy, and operate MCP servers without becoming an infrastructure team.ray.runAd

TDQS

A4/5.0

Disambiguation5/5

Each tool targets a distinct resource type and action: searching rental databases for equipment/studios versus retrieving/browsing style references for photographers/directors. No overlap exists between the two categories or between individual/browse operations.

Naming Consistency5/5

All tool names follow the verb_noun pattern in snake_case: search_* for database queries, get_* for single-item lookups, and list_* for browsing. The verbs are semantically appropriate and the naming style is uniform.

Tool Count5/5

With exactly six tools, the server is tightly scoped to its purpose (film production resource lookup). Each tool has a clear role, and the count fits well within the ideal 3-15 range.

Completeness5/5

The tool surface covers the two primary domains (rental rates and style references) adequately. For the reference library, both individual lookup and browsing are provided; for equipment and studios, search fulfills the querying needs. No obvious dead ends or missing operations for a read-only reference server.

Maintenance

ActivityInactive

ResponsivenessSyncing

Resources

Need Help?

Related Servers

Unclaimed servers have limited discoverability.

Looking for Admin?

If you are the server author, to access and configure the admin panel.

Related MCP Connectors

OneSchema MCP Server
co.oneschema
MCP server that lets AI assistants use all OneSchema features exposed via the public API.
Data Platforms App Automation
1
Zyla API Hub A
com.zylalabs
Discover and call 10,000+ production APIs from one MCP server. Pay-per-call billing for AI agents.
Developer Tools
82
ClawLinkOAuth
dev.claw-link
MCP server connecting AI agents to 100+ apps (Gmail, Slack, Notion, GitHub) via one-click OAuth.
App Automation Workplace & Productivity
24
Artificial Wit AIOAuth
com.artificialwit
MCP server unifying ERPs, CRMs, APIs and knowledge base for Claude, ChatGPT and Gemini.
ERP Systems CRM Knowledge & Memory
2

Related MCP Servers

mcp-media-engine
Multimedia Processing AI & Machine Learning
Tr1ckyMag1ca1
A
license
A
quality
B
maintenance
MCP server for AI-powered image, audio, and video generation, enabling media creation directly from Claude, Cursor, and other MCP clients.
Updated 2 months ago (2026-07-14 15:20 UTC)
11
64
MIT
agnes-mcp
AI & Machine Learning Image & Video Processing
nontracey
F
license
A
quality
C
maintenance
MCP server that exposes Agnes AI's text, image, video, and multimodal capabilities as tools with up to 1M context and 4K video.
Updated 2 months ago (2026-06-25 01:39 UTC)
7
-
omnicinema-mcp
Image & Video Processing Multimedia Processing AI & Machine Learning
joeshwoa
A
license
Not graded
quality
C
maintenance
Local MCP server that plans, generates, and assembles production assets (images, audio, video) through multi-agent personas and official APIs, with free-tier budget guard.
Updated 2 months ago (2026-07-07 19:22 UTC)
MIT
RunAPI Midjourney MCP Server
AI & Machine Learning Image & Video Processing
runapi-ai
A
license
B
quality
A
maintenance
Provides AI agents with Midjourney API access for image and video generation, task polling, and pricing checks through a focused MCP server.
Updated a month ago (2026-07-31 09:36 UTC)
10
72
1
Apache 2.0

Latest Blog Posts

Who's Calling? MCP Hosts Are an Identity Blind Spot (And the Spec Knows It)
By Om-Shree-0709 on July 25, 2026.
mcp
Agent Identity
OAuth 2.1
Your AI Chatbot Just Exposed Your CEO's Salary to an Intern
By Om-Shree-0709 on July 2, 2026.
Agent Identity
MCP Security
OAuth Delegation
Why MCP Servers Need Execution Sandboxing (And Why Your Current Stack Isn't Enough)
By Om-Shree-0709 on June 30, 2026.
Agentic Ai
Prompt Injection
WebAssembly

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/tzipway-dotcom/crewone-mcp-server'

If you have feedback or need assistance with the MCP directory API, please join our Discord server

@crewone/mcp-server

What is this

Two tiers of tools

Free (no API key required)

Paid (requires CREWONE_API_KEY)

Install

Claude Desktop

Cursor

Continue

Cline / any other MCP client

Example prompts

Configuration

Privacy

Source

Pricing

Troubleshooting

License

Available Tools

Tool Schema Changelog

Maintenance

Resources

Looking for Admin?

Related MCP Connectors

Related MCP Servers

Latest Blog Posts

MCP directory API

Paid (requires `CREWONE_API_KEY`)