Skip to main content
Glama
Sign In
deepset-mcp

deepset-mcp

Official
by deepset-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_cost_totals

Calculate total LLM cost, tokens, and requests for a workspace or pipeline over a date range to answer spending questions.

Instructions

Reads the total LLM cost, tokens and requests of the workspace, or of one pipeline, over a date range.

Use this to answer how much a workspace or pipeline spent on LLM calls. Costs are in USD. Without dates the range is the last 30 days. start_date is inclusive and end_date exclusive, so for September 2026 pass 2026-09-01T00:00:00Z and 2026-10-01T00:00:00Z.

Without workspace the figures cover the whole organization, as the Cost Management page does for an organization admin; this needs the organization admin role. Use workspace for one workspace. In that organization view pipeline_name and Service names can't be used (they belong to a workspace); pass Service ids instead.

Narrow the figures with services, providers and api_keys. They combine: usage must match every kind you set, and any one value within a list.

Check is_cost_complete before reporting total_cost. When it is false, total_cost is a lower bound, not the final figure: say so, and name the models in unpriced_models (LLM calls with no price on file) and mention pending_generation_count (calls whose cost is still being calculated, which usually clears within a minute). total_requests counts queries, not individual LLM calls; one query can make several LLM calls. :param pipeline_name: Restrict to this pipeline. Omit for the whole workspace. Needs Pipelines read as well as Costs read. :param start_date: Inclusive start as an ISO timestamp. Defaults to 30 days before end_date. :param end_date: Exclusive end as an ISO timestamp. Defaults to no upper bound. :param services: Restrict to these Services (deployment in the API; a published Service endpoint, not a deployed pipeline, which is a pipeline). Each value is a Service name or its id, the key from get_cost_breakdown with group_by='deployment'. Looking a Service up by name needs Services read as well as Costs read; an id needs only Costs read. :param providers: Restrict to these providers. Use the provider ids from get_cost_breakdown with group_by='provider', such as bedrock_converse or openai, not their display names. :param api_keys: Restrict to these API keys. Use the key ids from get_cost_breakdown with group_by='api_key', never a key's secret token. :returns: The cost totals, 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
api_keysNo
end_dateNo
servicesNo
providersNo
start_dateNo
pipeline_nameNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed3 schema fields changedv0.1.40
    • addedInput schema / properties / api_keys
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Api Keys"
+}
    • addedInput schema / properties / providers
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Providers"
+}
    • addedInput schema / properties / services
      Added value: +{
+  "anyOf": [
+    {
+      "items": {
+        "type": "string"
+      },
+      "type": "array"
+    },
+    {
+      "type": "null"
+    }
+  ],
+  "default": null,
+  "title": "Services"
+}
  2. Addedv0.1.31

TDQS

A4.7/5.0
Behavior5/5

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

With no annotations, the description carries the full burden and does so: it discloses the admin-role requirement, the is_cost_complete lower-bound caveat with instructions to name unpriced_models and pending_generation_count, the asymmetry that total_requests counts queries rather than LLM calls, and that results are stored in the object store with an @obj id. That is behavioral detail an agent could not infer from the schema.

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?

Front-loaded with the core purpose and defaults, and the paragraph-per-concern structure is easy to scan. It is long, though, and partly inflated by a Sphinx-style ':param'/':returns:' block that restates parameter info plus a generic object-store boilerplate tail that adds little.

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 6-parameter, no-output-schema tool this covers defaults, permission requirements, filter combination logic ('usage must match every kind you set, and any one value within a list'), and result handling. The missing piece is the absent ``workspace`` parameter the description depends on for its main scoping story.

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 0%, so the description must compensate, and it largely does: inclusive start / exclusive end with a concrete September 2026 example, providers must be ids like bedrock_converse not display names, api_keys must be key ids never secret tokens, and services may be names or ids with different permission implications. The deduction is for referencing a ``workspace`` parameter that does not appear in the input schema, which would confuse an agent trying to scope to one workspace.

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 ('Reads the total LLM cost, tokens and requests') plus the exact scoping options (workspace, one pipeline, or whole organization) and a date range. The word 'totals' plus the scoping language distinguishes it from the sibling aggregates get_cost_over_time and get_cost_breakdown.

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?

Explicitly says what question it answers ('how much a workspace or pipeline spent on LLM calls'), what the defaults are (last 30 days, whole organization), and what constraint applies (whole-org view requires the organization admin role). It also names exclusions and workarounds: pipeline_name and Service names can't be used in the org view, pass Service ids instead, and it points to get_cost_breakdown as the source of ids.

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