# Modal MCP > Modal MCP Server connects your AI agent directly to a high-performance serverless compute backend. It lets you audit active apps, check GPU deployments, and track persistent storage volumes using natural conversation. Need to manage complex ML infrastructure without touching the CLI? This is it. ## Overview - **Category:** superpower - **Price:** Free - **Tags:** serverless-compute, gpu-deployment, infrastructure-as-code, cloud-scaling, distributed-computing ## Description **Modal MCP Server - Audit GPU & Compute Infrastructure** Look, you gotta manage complex ML infrastructure without opening a terminal and running twenty lines of ugly CLI commands. This server connects your AI client straight to Modal's backend. It lets your agent handle the heavy lifting: checking active apps, auditing GPU deployments, and tracking persistent storage volumes—all just by talking to it. You'll get full control over high-performance, serverless compute resources through natural conversation. Here’s what you can do with these tools: * **Checking Status:** You can use `list_apps` to pull a rundown of every Modal application context—whether it’s running right now or if it just finished up. Need to know where your services are? Use `list_deployments` to get a list of all promoted, long-running service deployments on the platform. * **Storage and Security:** You gotta see what's attached to your account, so you can use `list_volumes` to show every persistent disk network block volume connected to your project. For security checks, run `list_secrets`; it gives you a list of all configured secret dictionary references in your account. * **Deep Dives:** If you need the nitty-gritty on one specific thing, you've got two ways to drill down. Use `get_app` and give it an App ID; it pulls precise JSON metadata about that single running application instance. Same deal with deployments: use `get_deployment` and reference a Deployment ID to get its detailed status information. * **Controlling the Compute:** Sometimes you gotta hit the kill switch. If an app’s running too long and racking up bills, use `stop_app`. You feed it the App ID, and it forces the immediate termination of that active Modal App execution, stopping billing charges right away. Basically, if you need to audit resources or check a status without typing out a single command, this is your ride. It gives you visibility into what's running, where it's stored, and lets you shut down runaway processes instantly. ## Tools ### list_apps Lists all active and historical Modal app contexts currently running or stopped. ### get_app Pulls specific details for one Modal App ID you provide. ### stop_app Forces the immediate termination of an active Modal App execution using its ID. ### list_secrets Lists every configured secret dictionary reference in your account for auditing purposes. ### list_volumes Shows a list of all persistent disk network block volumes attached to your project. ### list_deployments Provides a list of all actively managed, promoted service deployments on the platform. ### get_deployment Retrieves detailed status information for a single tracked deployment. ## Prompt Examples **Prompt:** ``` List all active Modal apps running in my account ``` **Response:** ``` I've retrieved your active Modal apps. Currently, 2 apps are running: 'gpu-trainer-alpha' (ID: ap-123, State: Running) and 'image-gen-service' (ID: ap-456, State: Initializing). Would you like to check the resource allocation for the GPU trainer? ``` **Prompt:** ``` Force stop Modal app ID 'ap-123' ``` **Response:** ``` Executing stop command… Success. Modal app 'ap-123' has been forcefully terminated. The serverless container has been spun down, and no further billing cycles will be triggered for this specific execution ID. ``` **Prompt:** ``` Show me all persistent volumes configured in my workspace ``` **Response:** ``` I've identified 3 persistent disk volumes: 'model-cache-v1' (Size: 50GB), 'training-datasets' (Size: 200GB), and 'user-data-store'. I can provide the mount paths for any of these volumes if you'd like. ``` ## Capabilities ### List active/historical apps Checks the status and context of all running Modal application instances. ### Stop a live app execution Terminates an actively running Modal App using its ID, preventing further billing charges. ### List managed deployments Retrieves a list of all promoted, long-running service deployments and their endpoint details. ### View persistent volumes Lists the disk network block volumes attached to your Modal account for storage visibility. ### Audit secrets Retrieves a list of secret dictionary references and associated environment variable mappings. ### Get specific resource state Pulls detailed JSON metadata for any single App or Deployment ID you reference. ## Use Cases ### The runaway GPU job A data scientist kicks off an experimental model training run, forgets to monitor it, and gets hit with a massive bill. They ask their agent: 'What apps are running?' The agent uses `list_apps` to identify the rogue App ID, which the user then passes to `stop_app`, stopping the billing cycle immediately. ### Checking pre-launch readiness A DevOps engineer is deploying a new microservice. Before merging, they use their agent: 'List all deployments and check the credentials.' The agent runs `list_deployments` to verify endpoints and then `list_secrets` to confirm necessary keys are available. ### Tracing dataset location A new ML engineer needs to know where the historical data lives. They ask: 'Show me all stored datasets.' The agent runs `list_volumes`, providing a list of named persistent disks, allowing the user to confirm which volume ID holds the source files. ### Debugging an app failure An AI engineer finds that a specific application (`app-xyz`) is failing. They ask: 'What's wrong with this app?' The agent runs `get_app` and returns the full JSON metadata, letting the user pinpoint if the issue is resource allocation or configuration. ## Benefits - Stop unexpected bills immediately. Instead of logging into the console to find a rogue job, use `stop_app` to force-terminate an active App execution with a single command. - Keep track of deployed services without manual lookups. Use `list_deployments` to get all web endpoints and serving configurations in one shot. - Audit your data security instantly. Running `list_secrets` lets you verify every stored secret reference, which is crucial before deploying sensitive models. - Manage massive datasets easily. `list_volumes` shows all persistent disk volumes, letting you know exactly where your training data lives across the cluster. - Get deep state info on demand. Use `get_app` or `get_deployment` to pull precise JSON metadata for any resource ID, bypassing vague status messages. - See everything at once. Running `list_apps` gives a clear snapshot of all running and historical compute contexts. ## How It Works The bottom line is you get full visibility into complex AI infrastructure by talking to your agent instead of writing boilerplate CLI commands. 1. Subscribe to this server and provide your Modal Token ID and Secret. 2. Your AI client uses the tokens to authenticate with your compute environment. 3. You ask your agent a question (e.g., 'What apps are running?'), and it runs the necessary tool calls, returning the structured data. ## Frequently Asked Questions **How do I find out what apps are running using list_apps?** Run `list_apps`. This gives you a clear rundown of all active and historical Modal app contexts. It's the first place to check if something is running unexpectedly. **Can I stop an app with stop_app using just the name?** No, `stop_app` requires the specific App ID. You must use `list_apps` or `get_app` first to get the exact identifier before you can terminate it. **What is the difference between list_volumes and getting app details?** `list_volumes` shows *all* disk volumes attached to your account. `get_app` provides state-specific information about a single running application, which might reference those volumes. **Do I need list_secrets if I just want to check my app?** You should run `list_secrets` whenever you suspect credential issues. It gives an audit trail of every secret dictionary reference attached to your services. **What happens if I use list_secrets with expired or wrong credentials?** The server immediately fails and returns a specific authentication error code. You must ensure your Modal Token ID and Secret are current before running this tool. **If I run stop_app on an App ID that is already terminated, will it cause an error?** No, the system handles this gracefully. It returns a status message confirming the app is already inactive and takes no action, preventing unnecessary billing cycles. **Does list_volumes show real-time network usage or just static storage details?** It only lists the persistent disk block volumes. You get information on size and mount paths for the connected data stores, not active bandwidth metrics. **What if I try to use get_deployment with an ID that was never promoted?** The tool returns a clear error stating that no tracked deployment exists for that specific ID. This confirms whether the resource is managed by Modal's promotion system. **Can I stop a running Modal app through my agent to save costs?** Yes. Use the `stop_app` tool with an active App ID. Your agent will dispatch a termination command to Modal, gracefully stopping the serverless container spin-up and preventing further billing for that specific execution. **How do I check which web endpoints are active for my deployments?** The `list_deployments` and `get_deployment` tools retrieve the Promoted image data. Your agent will expose the public URL endpoints and serving metadata associated with your long-running Modal deployments. **Can my agent audit the secrets and persistent volumes in my workspace?** Absolutely. Use the `list_secrets` and `list_volumes` tools to monitor your infrastructure assets. Your agent will report the names and references for your stored secrets and network block storage mounts attached to your compute instances.