Skip to main content
Glama
AIops-tools

Inference AIops

Official
by AIops-tools
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

model_deploy

Destructive

Deploy a Ray Serve application from a Python import path into a cluster's declarative config, preserving existing apps and using the app's replica settings.

Instructions

[WRITE][risk=medium] Deploy a Serve application from an import path.

The app is merged into the cluster's declarative Serve config (existing apps preserved). Replica counts come from the app's own config; set them afterward with serve scale (deployment names are known only once the app materialises).

Args: application: Serve application name to create/replace. import_path: Python import path of the Serve app (e.g. 'module:app'). target: Inference target name from config; omit for the default.

Input Schema

NameRequiredDescriptionDefault
targetNo
applicationYes
import_pathYes

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.9.0
    • removedInput schema / properties / num_replicas
      Removed value: -{
-  "default": 1,
-  "title": "Num Replicas",
-  "type": "integer"
-}
  2. First observedv0.6.0

TDQS

A4.1/5.0
Behavior4/5

Does the description disclose side effects, auth requirements, rate limits, or destructive behavior?

Annotations already declare write/destructive/non-idempotent, and the description adds real behavioral context beyond them: the app is merged into declarative config with existing apps preserved, replica counts come from the app's own config, and deployment names only exist after materialisation. Auth/permission requirements and failure behavior are still unstated, and 'existing apps preserved' sits a little uneasily beside destructiveHint=true.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness4/5

Is the description appropriately sized, front-loaded, and free of redundancy?

The [WRITE][risk=medium] tag and the core purpose are front-loaded, and the Args block is compact. The final parenthetical about deployment names is a touch convoluted, but no sentence is wasted.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness4/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

For a non-idempotent mutation with no output schema, the description covers merge semantics, replica behavior, and naming. It stops short of permissions, error/rollback behavior, or what a successful response returns, so it is strong but not exhaustive.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 0%, so the description must carry parameter meaning, and it does document all three args: application semantics ('create/replace'), import_path format with an example ('module:app'), and target ('omit for the default'). This compensates well for the empty schema, though the descriptions stay terse.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose5/5

Does the description clearly state what the tool does and how it differs from similar tools?

The description states a specific verb and resource ('Deploy a Serve application from an import path'), plus the operational mode (merge into declarative config). This clearly separates it from siblings like model_undeploy and deployment_redeploy without needing to open any schema.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

It offers a sequencing hint ('set replica counts afterward with serve scale'), which is genuinely useful, but never says when to choose this over deployment_redeploy, nor any preconditions or exclusions. Usage is implied rather than stated.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.

Deploy Server

Other Tools