# Render MCP > Render MCP gives your agent direct control over your cloud infrastructure. Instead of opening the dashboard, you can use natural language prompts to list services, suspend compute resources to save costs, deploy hotfixes instantly from GitHub, or build brand-new backend services—all through conversation. ## Overview - **Category:** ship-it - **Price:** Free - **Tags:** cloud-hosting, deployment-automation, scaling, server-management, infrastructure-as-code, web-services ## Description Your AI client connects directly to Render's capabilities via this MCP. This changes how you manage your entire cloud stack; it turns standard chat into a powerful DevOps control center. You can ask your agent to inspect the status of every web endpoint, database, and cron job in your account. Need to save money? Tell it to suspend compute on inactive projects, or wake them up when needed. If a hotfix lands on GitHub, you don't need to click buttons; just prompt your AI client to trigger a full deployment for the service. You can even tell your agent to create brand-new services pointing to specific repository branches or completely delete obsolete staging environments. This level of infrastructure management is what makes Vinkius such a vital catalog, giving your agent deep operational control over complex systems. ## Tools ### create_service Creates a brand new Render service instance linked directly from a GitHub repository. ### delete_service Permanently removes an existing, unwanted Render service; this action cannot be undone. ### get_deploy Pulls specific details about a single recorded deployment run. ### get_service Retrieves full, detailed status information for one particular Render service. ### list_deploys Generates a list of all recent deployment attempts made to a specific service. ### list_services Lists every single resource in the account, including web apps, databases, and cron jobs. ### resume_service Restarts a service that was previously suspended, bringing it back online. ### suspend_service Stops a running service to halt compute usage and prevent billing charges. ### trigger_deploy Forces a manual rebuild and deployment of code for an existing service. ### update_service_branch Changes which specific branch in GitHub is used as the source for a running service. ## Prompt Examples **Prompt:** ``` List my web services, then suspend the one named 'old-staging-app'. ``` **Response:** ``` I checked your services utilizing `list_services`. I found the matching instance ('old-staging-app', ID: srv-...a1s). By executing `suspend_service`, the application is now safely paused, terminating related compute billing operations momentarily until you need it again. ``` **Prompt:** ``` Check the recent deployment history for my main front-end service (srv-xyz123). ``` **Response:** ``` Pulling data using the `list_deploys` interface on `srv-xyz123`, I can confirm the last 3 deployments occurred at [10:30 AM], [11:15 AM], and [1:00 PM]. The most recent deployment completed successfully and is live. ``` **Prompt:** ``` Trigger a force deployment on service ID 'srv-backend88' and clear its build cache. ``` **Response:** ``` Deploy triggered using `trigger_deploy` with instructions pointing at `srv-backend88`. As requested, I bypassed internal optimizations establishing a true clean slate by clearing the previous build cache prior to cloning code. ``` ## Capabilities ### Assess current service status Lists all active web apps, databases, and cron jobs to show their current running state. ### Control compute costs Suspends or resumes services instantly, stopping billing cycles when the project isn't needed. ### Build new infrastructure Automatically provisions entirely new cloud services linked to a specific GitHub repository branch. ### Force deployments and updates Triggers an immediate, manual deployment for any service, even clearing the build cache if necessary. ### Review deployment history Retrieves a chronological log of past deployment attempts for deep auditing. ### Remove resources Permanently deletes specific services that are no longer required in the staging environment. ## Use Cases ### Debugging an intermittent staging failure The founder noticed production was behaving strangely. Instead of guessing which resource was failing, they asked their agent to run `list_services` and check the status of all connected databases and web endpoints. The agent immediately flagged a specific service that needed attention. ### Preparing for end-of-quarter cost savings The ops engineer knows several staging environments are idle until next month. They prompt their agent to check the status of all non-production projects, then instruct it to `suspend_service` on every single one, stopping unnecessary billing overnight. ### Testing a critical hotfix build A developer pushes a fix that needs immediate testing. They ask their agent to force the deployment (`trigger_deploy`) and clear the cache for the main web app, ensuring they are testing against a completely clean code slate. ### Building out a new microservice architecture A team leader needs to spin up a whole new API worker. They tell their agent to use `create_service`, specifying the repository and branch, letting the AI handle the entire provisioning workflow. ## Benefits - Save time on maintenance tasks. Instead of navigating multiple dashboards, you can ask your agent to list all services and immediately suspend costly non-production workers using `suspend_service`. - Control deployments without UI clicks. Need a hotfix deployed now? Simply tell your AI client to execute a fresh build pipeline via `trigger_deploy`, even clearing the previous cache. - Scale infrastructure on demand. Have an idea for a new service? Your agent provisions it automatically using `create_service`, pointing directly at the right GitHub repository branch. - Maintain cost control effortlessly. You can list all services and tell your agent to suspend compute usage, ensuring you only pay for what's actively running. - Audit deployments instantly. If something breaks, use your AI client to run `list_deploys` and get a clean history of the last few build attempts. ## How It Works The bottom line is you talk to your agent like a terminal command and it handles the complex API calls. 1. Install the Render platform extension module into your MCP connection. 2. Obtain and securely enter your personal Render API Key into the Vinkius configuration settings. 3. Use natural DevOps language in your chat, for example: "List my web services, then suspend the one named 'old-staging-app'." ## Frequently Asked Questions **Can I use Render MCP to check which services are running?** Yes. Running list_services shows all connected resources—web apps, databases, and cron jobs—so you always know what's active in your account. **How do I stop billing for a test environment using Render MCP?** You use the suspend_service tool. You tell the agent to suspend the specific service name, which immediately halts compute usage and prevents related charges. **What if I need to deploy code from an old branch?** First, you must run update_service_branch to point the service to that historical branch. Then, use trigger_deploy to start the build process from that new source. **Is delete_service permanent? Should I worry about it?** Yes, this action is irreversible and permanently deletes the resource. Use it only when you are 100% certain you never need the service again. **Can the AI clear the cache when triggering a deploy?** Yes, absolutely. The tool `trigger_deploy` incorporates an optional variable explicitly created for cache management. You can command the agent: "Redeploy the web app named Node-Backend and bypass rendering cache." **Which type of new services can the AI deploy using `create_service`?** The MCP can provision and launch exactly three core resource forms utilizing GitHub repos: standard web services (`web_service`), private network-locked processes (`private_service`), and asynchronous task handlers (`background_worker`). **Warning: Is there a confirmation before using `delete_service`?** Since natural language agents can occasionally misinterpret parameters, invoking the text request explicitly will route straight to the Render API resulting in instantaneous destruction. Please ensure absolute clarity when pointing the AI logic toward deletion operations.