Design how to configure Cloud Run attributes,

[steren]

We need to think about and capture design principles for what gets added as a tool parameter.

I don't think we should start adding every single Cloud Run configuration attribute as a tool parameter as this:

1. would likely reduce the success rate of AI using the tool. There are hundreds of parameters
2. would need constant update as Cloud Run adds new attributes.

This issue is to capture the concrete proposals and agree on a design.

So far, we had requests for specifying:

• service account
• IAP
• GPUs

[steren]

My first instinct is to say that the deploy tools of this MCP sevrer should only take project, region, name, function / source / container,env vars.

We should be passing any other parameter as a config file. Cloud Run supports a few config files:

1. Cloud Run v1 YAML: documented. Can be hard to write due to heavy use of annotation.
2. Terraform resource: documented, but needs Terraform to actuate
3. API v2 JSON / YAML: not documented outside of API reference, well structured.

I suggest v1 YAML to be consistent with docs / Console. But we should test what files AIs are able to write the best.

Then, the deploy tools would accept function / source / container + env vars + config file.

The image attribute of the config file would be overridden by the passed container or built function / source.

[steren]

What's your take @justinmahood ?

[justinmahood]

I think exposing the entire API spec via tool options is likely to cause the quality of the deployments to go down. The yaml spec is an escape hatch, but it still gives models an opportunity to get 'creative'. I'd suggest we offer specific deployment 'presets' for different capabilities rather than each low-level flag. For example, 'ai inference' would configure GPU's (and the associated defaults). This keeps the tool-shapes simpler with fewer combinations required

[wietsevenema]

Ok I've been thinking a lot about this too. The solution we end up with should be simple and capable.

• Polluting the deploy tools with all options is out. Too complex, confuses the models, and it's a new interface.

• I like exposing service.yaml. I think we can assume models have seen it in training.

• Presets are simple but not capable. They abstract useful information from the AI and while they are reliable and help with getting started fast, they're less suitable for continued evolution or clever combinations of multiple presets.

Recipes: guided deployment configuration

To address this, I propose recipes. A recipe is essentially a Markdown document with a service.yaml, and it contains additional instructional guidance and context for the AI. It includes:

• A descriptive title: "Static website with nginx", "Using Cloud SQL", "LLM inference service."
• A service.yaml: A pre-written service.yaml file that serves as a starting point.
• Requirements: A list of requirements or dependencies ("Use this connection string format to connect to Cloud SQL").
• Cross references to other recipes: For example, the Cloud SQL recipe links to the Memorystore recipe.

How do recipes work?

Expose these two capabilities (in one tool or two)

• Recipe list: Returns a list of available recipe titles with their ID and descriptive title. I don't worry too much about this list getting too long.
• Recipe get: Retrieves the full content of a specific recipe.

The AI can then use the information in the recipe to:

1. Understand the user's intent: By suggesting recipes, the AI can help the user clarify their needs.
2. Guide the user: The AI can use the recipe's instructions to ask the user for the right information.
3. Create required resources: Creating a Memorystore instance using gcloud.
4. Construct the service.yaml: The AI can use the recipe's template as a starting point and modify it.

Why this might work

I think this might work well, because:

• Flexibility and guidance: Recipes provide the flexibility of a service.yaml configuration file with the ease of use of presets, while also offering the guidance that is missing from all options discussed so far.
• Empowers the AI: Recipes help the AI become a solution architect, enabling it to create and evolve more complex deployments.

Let me know what you think!

[steren]

I like the suggestion, but "recipes" are too close to "presets" in my opinion. Presets are going to be a cross-surface concept. I would prefer not to duplicate it. Presets are not rigid, clients can override any config.

So what I hear is that we should allow customization of the presets. I.e. our deploy tools should take preset and YAML as parameters, "preset" defaulting to Cloud Run' default web serving and YAML optional.

[wietsevenema]

My intuition here is that the information hiding presets do is bad for LLMs because it'll confuse them.

Or are presets "open"? I need to look into them better