Nosana MCP
Server Configuration
Describes the environment variables required to run the server.
| Name | Required | Description | Default |
|---|---|---|---|
| NOSANA_API_KEY | No | Your Nosana API key. Can be omitted if you have already run `nosana-deploy login`, in which case the key is read from `~/.config/nosana-deploy/config.json`. |
Instructions
Guidance the server publishes about itself, which clients place ahead of the tool catalog so the model reads it before choosing anything.
This server publishes no instructions, or was last inspected before Glama recorded them.
Capabilities
Features and capabilities supported by this server
Protocol revision2025-11-25
| Capability | Details |
|---|---|
| tools | {
"listChanged": true
} |
| prompts | {
"listChanged": true
} |
| resources | {
"listChanged": true
} |
Tools
Functions exposed to the LLM to take actions
| Name | Description |
|---|---|
| get_balanceA | Credits on the Nosana account behind the API key: assigned, reserved by running deployments, settled (spent) and available. 1 credit is priced like 1 USD. |
| list_templatesA | Ready-to-run Nosana templates (MiniMax H3 video, Qwen and Gemma models via Ollama, ComfyUI, Jupyter, VS Code, Whisper, ...). Templates with variants need a variant id when deploying. |
| get_templateA | Details of one template or variant: VRAM needed, hardware notes (e.g. MiniMax H3 needs a Blackwell GPU), whether it exposes a web endpoint, variants, and optionally the job definition it deploys. |
| list_gpusA | GPU markets with price per hour (network fee included, matches deploy.nosana.com), idle hosts available right now, VRAM, and, when a template is given, whether each GPU fits it. |
| estimate_deploymentA | Dry run: resolve the template/variant and GPU, validate the plan, and return the cost in credits for one timeout window plus warnings (too little VRAM, non-Blackwell card, insufficient credits, no idle hosts). Nothing is created. Call this before create_deployment and show the user the cost. |
| create_deploymentA | SPENDS CREDITS. Creates a Nosana deployment from a template or job definition on the chosen GPU and starts it. Requires confirm=true, which you must only pass after the user has seen the estimate from estimate_deployment and agreed. Returns the deployment id; then poll wait_for_deployment until the endpoint is ready or the job completes. |
| wait_for_deploymentA | Blocks up to max_seconds (default 60, max 120) watching a deployment. Returns outcome "online" (service answers; includes ready URLs), "completed" (job finished; includes logs), "failed" (with the scheduler error), or "pending" (call again). Safe to call repeatedly. |
| get_deploymentA | Current status of a deployment with endpoints (tunnel online and whether the service actually answers), recent jobs and recent events. |
| list_deploymentsB | Deployments on this account (newest first) with status, strategy, active jobs and timeout. |
| stop_deploymentA | Stops a deployment and its running jobs. Billing stops with them. Use when the user is done or when a deployment can never schedule. |
| start_deploymentA | SPENDS CREDITS. Starts a DRAFT or STOPPED deployment again with its existing settings. Requires confirm=true after the user agreed. |
| extend_deploymentA | Sets a new timeout in minutes for a deployment (minimum 60). Longer timeouts reserve more credits. |
| get_job_resultB | Logs and results of a deployment job (latest job by default). |
| get_deployment_eventsA | Scheduler event log for a deployment (job listed, stopped, errors such as insufficient funds or bad timeout). Newest first. |
Prompts
Interactive templates invoked by user choice
| Name | Description |
|---|---|
| deploy_minimax_h3 | Guided flow: check credits, pick the variant and GPU, estimate, confirm, deploy, and hand back the ComfyUI URL. |
Resources
Contextual data attached and managed by the client
| Name | Description |
|---|---|
| templates | Ready-to-run template catalog with variants and VRAM needs. |
| gpus | GPU markets with price per hour and idle hosts right now. |
TDQS
Scored across 14 tools
Each tool targets a distinct resource or action: balance, templates, GPUs, deployment lifecycle, and job artifacts are clearly separated. Even the closely related get_deployment, wait_for_deployment, and get_job_result serve different purposes (status snapshot, blocking wait, and log retrieval) without meaningful overlap.
All tools follow a consistent verb_noun snake_case pattern, such as get_balance, list_templates, create_deployment, and extend_deployment. The naming is predictable and makes the action and target of each tool immediately obvious.
14 tools is a reasonable size for a deployment platform that covers credits, templates, GPU availability, cost estimation, deployment lifecycle, and job results. Each tool represents a distinct capability needed to follow the user's workflow from planning through execution to cleanup.
The core lifecycle is covered well: estimate, create, wait, poll, stop, start, extend, and fetch results. The main gap is the lack of a delete/remove operation for deployments, so users cannot fully clean up old or unwanted deployments from their account.