Skip to main content
Glama
deepset-ai

deepset-mcp

Official
by deepset-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

create_deployment_revision

Pushes a new revision onto a deployment from a platform or external pipeline version. Activate the revision separately to serve it.

Instructions

Pushes a new revision onto a deployment, e.g. from a platform pipeline version.

Creating a revision does not serve it automatically; call activate_deployment_revision to make it the deployment's served revision. :param deployment_id: ID of the deployment. :param comment: Comment describing the revision. :param config_yaml: Inline pipeline configuration YAML, for an externally pushed revision. :param source_version_id: ID of the source pipeline version, for a platform pipeline revision. :param source_type: Where the revision's pipeline configuration comes from, "PLATFORM_PIPELINE" (default) or "EXTERNAL_PIPELINE". :returns: The newly created revision or error message.

All parameters accept object references in the form @obj_id or @obj_id.path.to.value.

Examples::

# Direct call with values
create_deployment_revision(data={'key': 'value'}, threshold=10)

# Call with references
create_deployment_revision(data='@obj_123', threshold='@obj_456.config.threshold')

# Mixed call
create_deployment_revision(data='@obj_123.items', threshold=10)The output is automatically stored and can be referenced in other functions.

Returns a formatted preview with an object ID (e.g., @obj_123). Use the object store tools in combination with the object ID to view nested properties of the object. Use the returned object ID to pass this result to other functions.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
commentYes
config_yamlNo
source_typeNoPLATFORM_PIPELINE
deployment_idYes
source_version_idNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Addedv0.1.27

TDQS

A4.1/5.0
Behavior4/5

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

With no annotations, the description carries the burden and does well: it discloses that creation is non-serving and requires a separate activation step, and explains that the result is auto-stored and returned as a preview with an object ID. It omits permission/auth requirements, reversibility, and error conditions beyond a generic "or error message".

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

Conciseness2/5

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

The purpose and parameter notes are front-loaded and useful, but the description is padded with leaked Sphinx directives and a generic template block whose examples use parameters that do not exist on this tool (data, threshold). Those examples are actively misleading and do not earn their place.

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 5-param mutation tool with no annotations and no output schema, the description covers purpose, the activation prerequisite, per-parameter meaning, the object-reference convention, and the return shape. Missing pieces are edge behavior such as auth requirements and validation failures.

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 compensate, and it documents all five parameters including the source_type enum values and the situational role of config_yaml vs source_version_id. It also explains the @obj_id / @obj_id.path.to.value reference syntax, which the schema never mentions.

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?

States a specific verb and resource ("Pushes a new revision onto a deployment") and immediately scopes it against the sibling that serves revisions. An agent can distinguish it from activate_deployment_revision without opening the schema.

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?

Explicitly names the follow-up tool and the condition that selects it: creating a revision does not serve it, call activate_deployment_revision to serve it. No exclusions are given for when *not* to create a revision, so it stops short of a full when/when-not/alternatives statement.

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