Skip to main content
Glama
gura105

Operational Ontology

by gura105
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Local

aggregate_order

Count selected orders, optionally sum their totals, and group by status, assignee, or other properties to get numeric metrics per group.

Instructions

Count the selected Order objects and optionally sum a numeric property. Omit group_by for one whole-set total (key: null, zero metrics for an empty set), or group by a property. Returns set and values; each row has a key, member pks and numeric metrics. Filter rows in client-side code and use their pks to continue exploring.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
pksYes
sumNo
group_byNo

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed1 schema field changedv0.5.2
    • changedInput schema / required
      Previous value: -[
-  "pks",
-  "group_by"
-]New value: +[
+  "pks"
+]
  2. Changed4 schema fields changedv0.5.1
    • addedInput schema / additionalProperties
      Added value: +false
    • removedInput schema / properties / filter
      Removed value: -{
-  "properties": {
-    "assignee": {
-      "anyOf": [
-        {
-          "type": "string"
-        },
-        {
-          "type": "null"
-        }
-      ]
-    },
-    "id": {
-      "type": "string"
-    },
-    "sourceId": {
-      "type": "string"
-    },
-    "sourceSystem": {
-      "enum": [
-        "north",
-        "south"
-      ],
-      "type": "string"
-    },
-    "status": {
-      "enum": [
-        "pending",
-        "shipped",
-        "cancelled"
-      ],
-      "type": "string"
-    },
-    "total": {
-      "maximum": 9007199254740991,
-      "minimum": -9007199254740991,
-      "type": "integer"
-    }
-  },
-  "type": "object"
-}
    • addedInput schema / properties / pks
      Added value: +{
+  "items": {
+    "type": "string"
+  },
+  "type": "array"
+}
    • changedInput schema / required
      Previous value: -[
-  "group_by"
-]New value: +[
+  "pks",
+  "group_by"
+]
  3. First observedv0.1.0

TDQS

A4.4/5.0
Behavior4/5

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

With no annotations, the description carries the behavioral burden: it explains the null key for whole-set totals, zero metrics on empty sets, and the row shape with key/member pks/metrics. It does not cover auth or rate limits, but aggregation is naturally non-mutating and the edge-case disclosure is strong.

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?

Every sentence earns its place: the core action comes first, followed by grouping variants, return shape, and a practical follow-up hint. No filler or repetition.

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 tool with no output schema, the description provides return-row anatomy (key, member pks, numeric metrics) and an empty-set edge case, which is enough to call it correctly. The main gap is the lack of an exact example or field-name mapping, but this is not critical for selection and invocation.

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 description coverage is 0%, yet the description compensates by explaining pks as selected Order objects, sum as an optional numeric metric, and group_by as the grouping dimension. It stops short of naming the exact sum value (total) or enumerating valid group_by values, but the enum in the schema covers those details.

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 opens with a specific verb+resource: 'Count the selected Order objects and optionally sum a numeric property.' It clearly identifies aggregate_order as the counting/summing tool for orders, setting it apart from sibling get/search/pivot tools.

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 gives concrete usage instructions: omit group_by for a whole-set total, group by a property for grouped totals, and filter returned rows client-side. It does not mention alternatives or exclusions, but the context is clear enough for an agent to know when this tool applies.

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