MCP: client provided naming of output files

[ghchinoy]

Veo/Imagen/Lyria/Chirp tools to be able to specify an optional output_filename (s). and if cardinality is >1, a deterministic naming, like
"foo.png" => "foo_1.png".. "foo_3.png"

from @palladius

[github-actions]

🤖 Hi @ghchinoy, I've received your request, and I'm working on it now! You can track my progress in the logs for more details.

[palladius]

The reason why I'd want to achieve this is that I'm working on a declarative kubectl-style way of creating video/audio resources. If Gemini CLI dictates a certain file output, I can be aware if its done, WIP, or maybe failed after a certain timeout.

• I think the output_filename should be consistent for all tools, and be a single string, for simplicity, and optional (if not set, defaults to current naming).
• If cardinality >1, deterministically take the default name, and append _1.._10 before extension.

[ghchinoy]

A little bit of gemini cli analysis, prior to planning:

---

After a thorough review of the mcp-genmedia-go servers and the mcp-common library, here is the assessment of the feasibility of adding a client-supplied output filename parameter.

Overall Feasibility: High

It is highly feasible to implement an optional parameter for client-supplied filenames. The foundational logic for this already exists in the mcp-common package, and two of the servers already use this pattern.

Analysis by Server:

Server	output_file_name Parameter	Implementation Details	Feasibility to Add/Standardize
mcp-avtool-go	Yes (Implemented)	The output_file_name parameter is present in most tool definitions (e.g., ffmpeg_convert_audio_wav_to_mp3). The handlers use the common.HandleOutputPreparation function, which correctly prioritizes the user-supplied name.	Complete
mcp-lyria-go	Yes (Implemented)	The lyria_generate_music tool accepts a file_name parameter. The handler uses this name for both local and GCS output files, falling back to a unique ID if it's not provided.	Complete
mcp-chirp3-go	No	Filenames are generated using a combination of a fixed prefix (output_filename_prefix), the voice name, and a timestamp. It does not accept a specific filename from the client.	High
mcp-imagen-go	No	Filenames are generated automatically with a timestamp for local saves. For GCS, the name is determined by the Imagen API's response.	Medium
mcp-veo-go	No	Filenames are determined by the Veo API when it writes to the GCS bucket (e.g., sample_0.mp4). The server does not control the initial naming.	Medium

Path to Implementation:

The existing code in mcp-common is well-suited to handle this feature. The primary task is to update the individual MCP servers that don't currently support it.

1. For mcp-chirp3-go (Low Effort):

   • Add an optional output_file_name parameter to the chirp_tts tool definition.
   • In the chirpTTSHandler, modify the file saving logic to use this name if provided, otherwise, fall back to the current timestamp-based naming scheme.

2. For mcp-imagen-go and mcp-veo-go (Medium Effort):

   • Add an optional output_file_name parameter to the respective tool definitions (imagen_t2i, veo_t2v, veo_i2v).
   • The key challenge is that the generative APIs (Imagen and Veo) control the initial file creation and naming within the GCS bucket. To implement the client's desired filename, the handlers would need to perform a "rename" operation in GCS after the file is generated. This is typically a copy-and-delete operation.
   • The logic would be:
     1. The API generates the file (e.g., sample_0.mp4).
     2. The MCP handler receives the GCS URI of the generated file.
     3. The handler performs a GCS copy to a new object with the user-supplied name (e.g., my-video.mp4) and then deletes the original sample_0.mp4.
     4. If a local download is requested, it downloads the newly named file.

In conclusion, adding a client-supplied filename parameter is a very feasible and recommended enhancement for standardizing the behavior of the generative media MCP tools. The mcp-avtool-go and mcp-lyria-go servers provide a clear and effective implementation pattern to follow.