Skip to main content
Glama
Sign In
deepset-mcp

deepset-mcp

Official
by deepset-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_models

Discover available models and their configuration options for workspace pipelines and indexes. Filter by provider, connection status, or model name to choose the right chat generator.

Instructions

Lists the models including their configuration options available for use in a workspace's pipelines and indexes.

This includes predefined models offered by deepset as well as custom models configured at the workspace or organization level. Use this tool to discover which model names and providers can be used, which configuration options are available, and which default configuration is offered when configuring chat generators. :param limit: Maximum number of models to return per page. :param page_number: The page to fetch, starting at 1. :param connected: If set, only return models for which the workspace does (True) or does not (False) have a working integration configured. :param provider: If set, only return models from this provider. Accepts a well-known ModelProvider value (e.g. 'openai', 'anthropic', 'gemini', 'aws-bedrock') or any other provider name as a plain string. Case-insensitive, exact match. :param model: If set, only return models whose configured model name contains this value (e.g. 'gpt-4o'). Case-insensitive, substring match. :param include_price: If True, each model also carries its effective price in USD per 1,000 tokens (input, output and cache prices), with the workspace's and organization's custom prices applied. Requires read access to costs. Models without a known price have no price, e.g. Azure models that are only identified by their deployment name. Defaults to False. :returns: A page of models including their configuration options or an error message.

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

NameRequiredDescriptionDefault
limitNo
modelNo
providerNo
connectedNo
page_numberNo
include_priceNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.1.40
    • addedInput schema / properties / include_price
      Added value: +{
+  "default": false,
+  "title": "Include Price",
+  "type": "boolean"
+}
  2. Changed3 schema fields changedv0.1.13
    • addedInput schema / $defs
      Added value: +{
+  "ModelProvider": {
+    "description": "Well-known providers of models.\n\nThis is not an exhaustive list of all providers a model may report. Other provider values\n(e.g. from custom or newly added integrations) are still valid and accepted as plain strings.",
+    "enum": [
+      "aws-bedrock",
+      "openai",
+      "gemini",
+      "anthropic"
+    ],
+    "title": "ModelProvider",
+    "type": "string"
+  }
+}
    • addedInput schema / properties / model
      Added value: +{
+  "anyOf": [
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Model"
+}
    • addedInput schema / properties / provider
      Added value: +{
+  "anyOf": [
+    {
+      "$ref": "#/$defs/ModelProvider"
+    },
+    {
+      "type": "string"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Provider"
+}
  3. Addedv0.1.11

TDQS

A4.5/5.0
Behavior4/5

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

With no annotations, the description does real work: it discloses the side effect that results are auto-stored as an object with an ID (e.g. @obj_123) to be read via object-store tools, and that include_price requires read access to costs and silently omits price for models like Azure deployment-named ones. Missing are explicit read-only framing, auth scope beyond costs, and ordering/pagination edge behavior.

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?

Purpose is front-loaded, then parameters, then return behavior, so scanning order is correct. It is somewhat long and the boilerplate object-store paragraph plus ':returns' line add bulk, but nearly every line carries actionable information.

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 six-optional-parameter list tool with no output schema and no annotations, the description covers purpose, filtering semantics, cost/permission caveat, pagination and the shape of the returned result (preview + object ID). An agent has enough to call it correctly and know how to retrieve nested details.

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

Parameters5/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 does: every one of the six parameters is documented with semantics beyond the schema — limit as per-page cap, page_number starting at 1, connected as integration-status filter, provider as case-insensitive exact match accepting well-known or arbitrary provider strings, model as case-insensitive substring match, and include_price's units (USD per 1,000 tokens, input/output/cache).

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 first sentence gives a specific verb and resource ('Lists the models including their configuration options') plus the scope ('available for use in a workspace's pipelines and indexes'). It immediately separates itself from sibling list tools such as list_pipelines, list_indexes and get_custom_components.

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?

It explicitly names the discovery use case: finding model names/providers, available configuration options, and default configuration when setting up chat generators. There are no explicit exclusions or named alternatives, but the usage context 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