Skip to main content
Glama
dbos-inc

DBOS MCP Server

Official
by dbos-inc

get_workflow_aggregates

Retrieve workflow aggregates grouped by status, queue, name, or other dimensions to see counts, failures, and latency at a glance for dashboards.

Instructions

Get workflow aggregate metrics from DBOS Conductor.

Returns workflow aggregates grouped by one or more dimensions. Useful for dashboards and understanding workflow status at a glance (e.g., "how many workflows failed today?", "how many workflows are pending per queue?", "what's the worst queue-wait time per workflow name?").

Select at least one select_* flag to populate aggregate values. At least one group_by_* flag is mandatory to break the results down by dimension; a query with no group_by_* will fail.

Args: application_name (string, required): Name of the DBOS application group_by_status (bool, optional): Group results by workflow status (default: false) group_by_name (bool, optional): Group results by workflow name (default: false) group_by_queue_name (bool, optional): Group results by queue name (default: false) group_by_executor_id (bool, optional): Group results by executor ID (default: false) group_by_application_version (bool, optional): Group results by application version (default: false) group_by_application_name (bool, optional): Group results by application name (default: false) select_count (bool, optional): Include count of workflows in each group (default: false) select_min_created_at (bool, optional): Include earliest creation time (ISO 8601) in each group (default: false) select_max_queue_wait_ms (bool, optional): Include max queue wait time (ms) in each group (default: false) select_max_total_latency_ms (bool, optional): Include max end-to-end latency (ms) in each group (default: false) status (array of strings, optional): Filter to these statuses before aggregating start_time (string, optional): Filter workflows created after this time (ISO 8601) end_time (string, optional): Filter workflows created before this time (ISO 8601) completed_after (string, optional): Filter workflows completed after this time (ISO 8601) completed_before (string, optional): Filter workflows completed before this time (ISO 8601) dequeued_after (string, optional): Filter workflows dequeued after this time (ISO 8601) dequeued_before (string, optional): Filter workflows dequeued before this time (ISO 8601) name (array of strings, optional): Filter to these workflow names before aggregating app_version (array of strings, optional): Filter to these application versions executor_id (array of strings, optional): Filter to these executor IDs queue_name (array of strings, optional): Filter to these queue names workflow_id_prefix (array of strings, optional): Filter to workflow IDs starting with these prefixes time_bucket_size_ms (int, optional): Bucket aggregates into time windows of this many milliseconds schedule_name (array of strings, optional): Filter to workflows started by these schedules

Returns: aggregates: Array of aggregate objects, each containing: - group (object): Map of dimension names to values. Keys are snake_case: status, name, queue_name, executor_id, application_version, application_name (e.g., {"status": "ERROR", "name": "processOrder"}). If time_bucket_size_ms is set, each group also carries a time_bucket key whose value is the bucket's start time as Unix epoch milliseconds (a string), not ISO 8601. - count (int, optional): Number of workflows matching this group (if select_count) - minCreatedAt (string, optional): Earliest creation time, ISO 8601 (if select_min_created_at) - maxQueueWaitMs (int, optional): Max queue wait time in ms (if select_max_queue_wait_ms) - maxTotalLatencyMs (int, optional): Max end-to-end latency in ms (if select_max_total_latency_ms) application (string): Name of the application queried

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
nameNo
statusNo
end_timeNo
queue_nameNo
start_timeNo
app_versionNo
executor_idNo
select_countNo
group_by_nameNo
schedule_nameNo
dequeued_afterNo
completed_afterNo
dequeued_beforeNo
group_by_statusNo
application_nameYes
completed_beforeNo
workflow_id_prefixNo
group_by_queue_nameNo
time_bucket_size_msNo
group_by_executor_idNo
select_min_created_atNo
select_max_queue_wait_msNo
group_by_application_nameNo
select_max_total_latency_msNo
group_by_application_versionNo

Output Schema

TableJSON Schema
NameRequiredDescriptionDefault

No arguments

Install Server

TDQS

A4.8/5.0
Behavior5/5

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

With no annotations, the description carries full behavioral disclosure burden and does so thoroughly. It documents required flag combinations, failure behavior, return shape details, and a subtle format caveat that time_bucket values are Unix epoch millisecond strings rather than ISO 8601. This richly exceeds the minimum needed for safe invocation.

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?

The description is long but every section earns its place: a front-loaded summary, usage guidance, a complete Args list, and a return-value breakdown. The structured layout makes the high parameter count navigable rather than overwhelming.

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 tool with 25 parameters, no annotations, and zero schema descriptions, the description is exceptionally complete. It covers all required invocation constraints, parameter semantics, and return values, leaving no obvious gap an agent would need to guess about.

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%, and the description compensates fully by documenting all 25 parameters with types, required status, defaults, and semantics. It adds meaningful meaning beyond the bare schema, such as explaining filters like workflow_id_prefix and the meaning of time_bucket_size_ms.

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 the specific verb-resource relationship ('Get workflow aggregate metrics') and clearly distinguishes from siblings like list_workflows or get_workflow by emphasizing grouped, dashboard-oriented summaries. Concrete example questions ('how many workflows failed today?') reinforce the tool's distinct purpose.

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?

Provides clear context for when to use the tool ('useful for dashboards and understanding workflow status at a glance') and gives mandatory usage rules: at least one select_* flag and at least one group_by_* flag, with the failure consequence for missing group_by. It does not explicitly name alternatives like list_workflows for raw enumeration, but the aggregate-vs-list distinction is strongly implied.

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

Other Tools

Latest Blog Posts

MCP directory API

We provide all the information about MCP servers via our MCP API.

curl -X GET 'https://glama.ai/api/mcp/v1/servers/dbos-inc/dbos-mcp'

If you have feedback or need assistance with the MCP directory API, please join our Discord server