Skip to main content
Glama
Sign In
deepset-mcp

deepset-mcp

Official
by deepset-ai
OverviewSchemaSourceRelated ServersDiscussionsAdmin
Python
Remote

get_cost_over_time

Tracks daily LLM costs in USD for a workspace or pipeline to identify cost spikes and compare periods; filter results by service, provider, or API key.

Instructions

Reads the LLM cost of the workspace, or of one pipeline, per UTC day.

Use this to see how spending developed, find the day a cost spike started, or compare periods. Costs are in USD. There is one point per day with usage; days without usage are left out, so a missing day means zero cost. A cost_total of null means that day had usage but none of it was priced. Without dates the range is the last 30 days. start_date is inclusive and end_date exclusive. The daily figures leave out unpriced LLM calls; use get_cost_totals to check whether the cost is complete.

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. :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 daily cost, 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.9/5.0
Behavior5/5

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

With no annotations provided, the description carries the full burden and discloses key behavior: USD costs, one point per day with usage, omitted zero-usage days, null cost_total semantics for unpriced usage, inclusive/exclusive date bounds, and default ranges. It also states permission needs and the organization-admin-only behavior when workspace is omitted.

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?

The description is long but front-loaded and information-dense, with the primary purpose and usage context first. It is appropriately sized for the tool's complexity, though some parameter explanations and object-store boilerplate are slightly verbose.

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?

There are no annotations, no output schema, and six sensitive query parameters, but the description covers defaults, permissions, filter semantics, limitations, return behavior, and the object-store preview mechanism. An agent has enough information to invoke the tool correctly without opening other documentation.

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 fully explain all six parameters, and it does. It documents date inclusivity, filtering combination logic, id sources from get_cost_breakdown, permission implications, and the organization-view restriction on pipeline_name and Service names.

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 description states a specific verb, resource, and scope: reading LLM cost per UTC day for a workspace or one pipeline. It clearly distinguishes the tool from related siblings by naming get_cost_totals and get_cost_breakdown in relevant contexts.

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?

It gives explicit use cases such as seeing spending over time, finding when a cost spike started, or comparing periods. It also routes the agent to get_cost_totals for completeness checks and to get_cost_breakdown for obtaining provider, Service, and API key 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