Skip to main content
Glama
amanharshx

ultralytics-mcp

by amanharshx
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

deployment_predict

Read-only

Run inference on a local image or video through a deployment's serving endpoint by owner/deployment or slug, returning images and metadata verbatim.

Instructions

Run inference through a deployment's own serving endpoint on a local image or video file, by owner/deployment or a bare slug (owner defaults to the account owner). Returns images/metadata verbatim, including undocumented metadata fields. No per-request cost is documented for this endpoint; costs follow the deployment's own resource configuration. A cold start on a scaled-to-zero deployment may respond slowly or with a 503 — check deployment_health rather than retrying blindly.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
iouNoIoU threshold (0-0.95, server default applies if omitted).
confNoConfidence threshold (0.01-1, server default applies if omitted).
imgszNoInference image size (32-1280, server default applies if omitted).
imagePathYesLocal path to an image or video file, uploaded as-is. The server decides which formats it accepts.
deploymentYesDeployment ref by owner/deployment or a bare slug.

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed2 schema fields changedv0.1.15
    • addedInput schema / additionalProperties
      Added value: +false
    • changedInput schema / properties / imagePath / description
      Previous value: -"Local path to an image file (.jpg, .jpeg, .png, .webp, .bmp, .tif, .tiff)."New value: +"Local path to an image or video file, uploaded as-is. The server decides which formats it accepts."
  2. Addedv0.1.12

TDQS

A4.3/5.0
Behavior5/5

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

Adds substantial behavior beyond the annotations (which only say read-only, open-world, non-destructive): verbatim return of images/metadata including undocumented fields, the fact that no per-request cost is documented and costs follow deployment resource configuration, and the cold-start/503 failure mode. This is exactly the context annotations cannot carry.

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?

Three tight sentences, front-loaded with what the tool does, followed by return behavior, cost, and failure handling. Dense but each sentence carries distinct information; no filler.

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

Completeness5/5

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

No output schema exists, and the description covers the return shape (images/metadata verbatim), cost semantics, and the primary operational failure mode. For a 5-parameter inference tool with high schema coverage, nothing an agent needs to call it correctly is missing.

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 coverage is 100%, so the baseline is 3. The description adds one piece of semantic meaning the schema lacks: a bare slug resolves owner to the account owner, clarifying the ambiguity of the deployment ref. Beyond that it does not restate thresholds or size ranges.

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

Purpose4/5

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

States a specific verb (run inference) plus resource (a deployment's own serving endpoint) and input type (local image or video file). It is clear against the deployment_* siblings, though the near-twin model_predict is never named or distinguished.

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

Usage Guidelines4/5

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

Gives real usage context: cold starts on scaled-to-zero deployments may be slow or 503, and the agent is told to check deployment_health rather than retry blindly. That routes to an alternative tool, but there is no explicit when-not-to-use-this versus model_predict guidance.

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