Plori

Official

by plori-ai

Overview Schema Source Related Servers Discussions Admin

JavaScript

Remote

Get Workspace costs

get_workspace_costs

Read-only

Retrieve the amount charged to a Workspace or task group over a time window, including total, coverage, and per-run charges. No runs start and no data changes.

Instructions

Get the amount charged to the account's balance for the runs of a Workspace, or of one task group in it, in a time window: the total, how complete it is (coverage), and the charges that make it up per run. A token limit is not a cost. No run starts and nothing changes.

Input Schema

Name	Required	Description
`to`	No	End of the window, RFC 3339, not in the future. Omitted, now. The window is at most 366 days.
`from`	No	Start of the window, RFC 3339. Omitted, 30 days before to.
`workspace_id`	Yes	The Workspace UUID.
`task_group_id`	No	Only report the charges of this task group of the Workspace.

Output Schema

Name	Required	Description
`id`	Yes	The Workspace or task group UUID.
`to`	Yes	End of the time window, RFC 3339.
`from`	Yes	Start of the time window, RFC 3339.
`rows`	Yes	The charges that make up the total, one row per run and kind of usage, at most 200.
`notes`	Yes	What the total includes and excludes.
`scope`	Yes	workspace or task_group.
`coverage`	Yes	partial when charges were found and unavailable when none were. The total is the sum of the charges linked to runs in this scope, not a complete cost; notes say what it leaves out.
`rows_truncated`	No	True when the scope has more than 200 charge rows; the total still includes all of them.
`charged_micro_usd`	Yes	The total charged to the account's balance for runs in this scope and window, in micro-US-dollars.
`pending_compute_runs`	Yes	Runs whose compute charge is not settled yet; the total grows when they settle.

Schema Changelog

Changes observed during successful MCP inspections.

Addedv0.17.1Oct 18, 2026

TDQS

A3.8/5.0

Behavior4/5

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

Annotations already declare readOnlyHint=true, openWorldHint=false and idempotentHint=false, so the safety profile is covered. The description adds real value beyond that: it clarifies that no run is started and no state changes, and it explicitly rules out a common misinterpretation (token limits are not costs). It does not explain why repeat calls may differ despite being read-only (the 'now'-defaulted window behind idempotentHint=false), which would have been the ideal addition.

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?

Two sentences, front-loaded with the primary outcome and followed by two short, high-value clarifiers. Nothing is padded and every clause carries information.

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?

An output schema exists, so return values need no explanation, and the four parameters are fully documented in the schema. The description supplies scope, semantics and no-side-effect guarantees, leaving only the sibling-selection question unanswered.

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?

Schema description coverage is 100%: from/to defaults, RFC 3339 format, the 366-day cap, and the task_group_id narrowing are all documented in the schema. The description only restates the task-group and time-window concepts, adding no syntax or edge-case detail beyond the schema, so the baseline 3 applies.

Input schemas describe structure but not intent. Descriptions should explain non-obvious parameter relationships and valid value ranges.

Purpose4/5

Does the description clearly state what the tool does and how it differs from similar tools?

States a specific verb and resource with precise scope: charges to the account balance for a Workspace's runs (or one task group) within a time window, plus what is returned (total, coverage, per-run charges). It even disambiguates domain terms ('A token limit is not a cost'). It does not name an adjacent sibling such as get_credits, so an agent must infer the boundary between cost and credit tools.

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

Usage Guidelines3/5

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

The description conveys the applicable scope (a Workspace, optionally narrowed to one task group, within a time window) but never says when to choose this over siblings like get_credits or how to combine it with list_runs. Usage is implied by the resource, not stated as guidance or exclusions.

Agents often have multiple tools that could apply. Explicit usage guidance like "use X instead of Y when Z" prevents misuse.