AI assistants are good at turning a loose request into a sequence of steps. On their own, though, they cannot open your design tool, start a render or read your media library. MCP, the Model Context Protocol, is the standard that connects them to such tools. This article explains how MCP works, what changes when the tools cost money and produce media, and which design choices make the difference between an assistant you can trust with a studio and one you have to watch. The examples come from the Yeşilçam Studios CLI and MCP server.

What is MCP?

MCP is an open protocol, published by Anthropic in late 2024, that describes how an AI application talks to external tools and data. There are three parts:

  • The client is the application you talk to, for example Claude Code, Claude Desktop or Cursor.
  • The server is a small program that offers tools. It can run on your own computer, started by the client and talking over standard input and output.
  • The tools are named operations with a description and a schema of their parameters, such as "create an image" with a prompt, a quality tier and an aspect ratio.

When you ask for something, the assistant reads the tool descriptions, chooses a tool, fills in the parameters and calls it. The server does the work and returns a result, and the assistant decides what to do next. Because the protocol is shared, one server works with any client that supports it.

What changes when the tools are creative and paid?

Many MCP servers read things: files, issues, documentation. A creative studio is different in three ways, and each one shapes the design.

  • Calls cost money. A video or a long film spends real tokens. An assistant that misreads a request, or retries a failed call, should not be able to spend without the person noticing.
  • Jobs take time. A render can run for minutes. The tools have to start work, report progress and pick up the result later.
  • The output is personal. Photos of people, voices and unreleased products are private by default, and some of them need consent.

Quote first, approve second

The simplest reliable answer to the first point is to split every paid operation into two calls. The first call returns a quote and charges nothing. In the Yeşilçam Studios server it is marked quote_only_nothing_charged and lists the line items, the total, the balance and whether the account can afford it. The server instructs the assistant to show this to the user and to call again with confirm=true only after the user agrees, never on its own.

This puts the decision where it belongs: with a person who has seen the number. It also helps the assistant, which can compare options ("draft costs this, standard costs that") before anyone commits. A second limit, max_tokens, makes the tool refuse a job above a given price, even when it is approved. The command line follows the same pattern: it shows the quote and asks, a script approves with --yes, and without approval it exits with a dedicated code so that "quote shown, not approved" is never mistaken for success.

Keys with limits, not passwords

An assistant or a build server needs credentials, and those credentials may end up in places you did not plan for. Two practices keep the damage small.

First, use API keys with a defined scope instead of a password. A read-only key can see balance, prices, library and job status but cannot create, edit, delete or spend. A key with create access can start work, still through quotes. Keys can expire after a set time and can be revoked at once. On the service side only a secure fingerprint of the key is kept.

Second, keep the most sensitive actions out of reach of any key. In Yeşilçam Studios no key can delete the account, change its password or email, pay or buy tokens, turn on automatic top-ups, create other keys or connect social accounts. Those stay in the web app, behind a normal sign-in.

A related detail: the secret should not live in the assistant's configuration file. The yesilcam-mcp server reads the key that the command line stored on your computer, readable only by your user, so the configuration only names the command.

Fewer tools, better choices

The Yeşilçam Studios server offers 131 tools. Every tool description takes space in the assistant's context, and a long list makes it harder to pick the right one. The server can therefore be started with only the studios you need (--studios image,film,influencer), or with only the reading tools (--read-only). Each tool is also marked with hints the client can show: whether it only reads, whether it is destructive, such as deleting a file, and whether it reaches outside your computer.

Long jobs and results

For work that takes minutes, the tools take wait=true: the server polls the job, sends progress notifications and returns when it is done. With save_to it downloads the result. Without waiting, the tool returns a kind and an id that a separate wait tool can follow later. The assistant does not need to invent its own polling loop.

Privacy by default

Media made through the tools is private. Links are signed and expire after a few hours, and the download tool refreshes them. A public link or a post on The Wall goes through a share request that may need approval. Characters are always adults, real public figures are not allowed, and a person's own photo or video is used only with an explicit consent flag and after a safety check.

One catalog for the assistant and the script

Every MCP tool of the Yeşilçam Studios server has an identical command in the yesilcam CLI, because both are generated from one catalog of operations. This has practical value: a workflow you discovered in a conversation can be repeated in a script with the same names and parameters, and both are tested against the same definitions.

A checklist before connecting an assistant to a paid tool

  • Does every paid operation show a price before charging, and does it need an explicit approval?
  • Can you set a maximum price per job?
  • Are there read-only keys, expiring keys and instant revocation?
  • Which actions can no key perform?
  • Is the secret kept out of the assistant's configuration?
  • Can you load fewer tools?
  • Are results private by default, and is consent required for real people?

Limits

MCP does not make an assistant infallible. It can still choose the wrong tool or misunderstand a request, which is exactly why approvals and limits belong in the tools rather than in good intentions. Some work also remains better in a visual editor, such as arranging a timeline or furnishing a 3D plan. The protocol is a way to hand over the repetitive steps, not a replacement for judgement.

Frequently asked

Do I need to be a developer to use MCP? No. Connecting a server to Claude Desktop or Cursor is a short configuration step, and after that you write to the assistant in plain language. The setup guide shows each step.

Does MCP send my files to the assistant? The assistant sees what the tools return, such as job details and links. Files stay in your library and in the folders you choose, and links to private media expire.

Is MCP the same as an API? It sits on top of one. The server calls the service's API and presents the operations as tools that an assistant can understand and choose from.