Skip to main content
Glama
delimit-ai

delimit

Official
by delimit-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Hybrid

Delimit Deploy Publish

delimit_deploy_publish

Publish previously built container images to the configured registry, enabling deployments. Requires Delimit Pro.

Instructions

Publish previously built images to the registry (Pro).

When to use: after delimit_deploy_build has produced images locally. When NOT to use: to build images (delimit_deploy_build) or to start the deploy chain (delimit_deploy_plan).

Sibling contrast: deploy_build produces local images; this pushes them to the registry; deploy_verify confirms rollout health.

Side effects: gated by require_premium. Calls backends.deploy_bridge.publish, which performs network writes to the configured container registry.

Prerequisite: requires Delimit Pro. An unlicensed call returns {"error": ..., "upgrade": "https://delimit.ai/pricing"} without running.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
appNoApplication name (project key in the deploy backend).
git_refNoGit ref the images were built at. Default None.
repo_pathNoExplicit Git worktree root.

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv4.13.2
    • addedInput schema / properties / repo_path
      Added value: +{
+  "default": "",
+  "description": "Explicit Git worktree root.",
+  "type": "string"
+}
  2. Changed2 schema fields changedv4.7.9
    • addedInput schema / properties / app / description
      Added value: +"Application name (project key in the deploy backend)."
    • addedInput schema / properties / git_ref / description
      Added value: +"Git ref the images were built at. Default None."
  3. Changed2 schema fields changedv4.5.5
    • addedInput schema / properties / app / default
      Added value: +""
    • removedInput schema / required
      Removed value: -[
-  "app"
-]
  4. First observedv0.1.0

TDQS

A4.7/5.0
Behavior5/5

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

The annotations only set readOnlyHint=false and destructiveHint=false, so the description carries the transparency burden. It discloses that publish is gated by require_premium, calls backends.deploy_bridge.publish, performs network writes to the registry, and returns a specific unlicensed response without running. This is valuable behavioral context an agent cannot infer from annotations alone.

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

Conciseness5/5

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

The description is organized into labeled, scannable sections and front-loads the core action before caveats. Every section serves a purpose: what it does, when to use it, when not to, side effects, and prerequisite. Minor redundancy around the Pro requirement is acceptable and does not reduce clarity.

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?

For a mutating publish operation with an output schema, the description covers the essential context: position in the deploy flow, side effects, licensing failure mode, and sibling roles. Parameters are fully covered by the input schema and return values by the output schema. No material gap remains for correct invocation.

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

Parameters3/5

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

Input schema coverage is 100%, with descriptive comments for app, git_ref, and repo_path. The description does not add parameter-specific detail beyond what the schema already provides. A baseline of 3 is appropriate when the schema fully documents the parameters.

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 opening sentence uses a specific action and resource: 'Publish previously built images to the registry (Pro)'. It distinguishes this tool from siblings by naming delimit_deploy_build as the local-image producer and delimit_deploy_verify as the rollout-health checker. This goes well beyond restating the title.

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

Usage Guidelines5/5

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

The description has explicit 'When to use' and 'When NOT to use' guidance, directing the agent to use this after delimit_deploy_build has produced local images. It names the alternatives for building and starting the deploy chain, and contrasts with delimit_deploy_verify. Tool selection is unambiguous.

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