Skip to main content
Glama
itmplatform

ITM Platform MCP Server

Official

query_datamart

Run custom MongoDB queries against ITM DataMart to filter, list, or aggregate project components for advanced analysis beyond standard typed tools.

Instructions

Run a custom query against ITM DataMart (MongoDB-backed). For advanced analysis beyond typed tools.

Operations:

  • "components": list with filters. Params: where, project, sort, limit (max 200), skip

  • "component": single by ID. Params: id, project

  • "aggregateComponents": aggregation pipeline. Params: pipeline (must end with $limit, max 1000)

Allowed filter operators: $eq, $ne, $in, $nin, $gt, $gte, $lt, $lte, $regex, $options, $exists, $not, $and, $or, $nor Allowed pipeline stages: $match, $project, $group, $sort, $limit, $skip, $unwind, $addFields, $set, $unset Banned: $lookup, $merge, $out, $function, $accumulator, $where, $facet

Key fields: id, name, code, componentType, statusLabel, priorityLabel, percentComplete, startDate, endDate, methodology, managers, budgetTopDown, budgetActual, customFields (object keyed by field display name; see get_custom_fields).

Projecting full embedded arrays (tasks: 1, risks: 1, etc.) is rejected as too large; use dot notation (e.g. "tasks.name": 1) or the subcomponent tools with limit/skip.

This account defines custom fields. In DataMart documents they live under "customFields", an object keyed by the field's display name. Keys present (with component counts):

  • project: "Exposure" (13), "Invoice paid" (13), "Client acceptance date" (13), "Area" (13), "ERP Code" (13) Query them via query_datamart: project {"customFields": 1} to read all values, or where {"customFields.": ...} to filter. Keys are case- and accent-sensitive and may contain trailing spaces. Keys with lower counts than their siblings are usually language variants of the same field on multilingual accounts; cover both variants with $or when totals matter. Field types and dropdown values: get_custom_fields and get_custom_field_options.

Input Schema

NameRequiredDescriptionDefault
idNoComponent ID (for "component" operation)
skipNoOffset for pagination
sortNoSort spec (1 = ascending, -1 = descending)
limitNoMax results (default 50, max 200 for list, 1000 for agg)
whereNoMongoDB filter (for "components")
projectNoField projection (1 = include)
pipelineNoAggregation pipeline stages (must end with $limit)
operationYesThe DataMart operation

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observedv0.1.0

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 the full behavioral burden and does so thoroughly: it lists allowed filter operators and pipeline stages, banned stages such as $lookup, $merge, and $out, hard limits for list and aggregation operations, and projection restrictions. It effectively signals a read-only query surface and discloses key operational constraints an agent needs before invoking it.

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 appropriately structured for a complex query tool. The first sentence is front-loaded with purpose and scope, and the subsequent sections group operations, constraints, key fields, and custom-field guidance cleanly.

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?

Given the tool's complexity, eight parameters, nested objects, and absence of an output schema, the description is complete enough for an agent to invoke it correctly. It covers operation semantics, query capabilities, restrictions, limits, custom-field handling, and alternatives for large embedded arrays.

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?

Although schema coverage is 100%, the description adds substantial meaning beyond the schema by mapping each operation to its relevant parameters and constraints. It explains allowed where operators, pipeline restrictions, sort behavior, limit maxima, and customFields query patterns, which materially improves correct invocation.

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 and resource: run a custom query against ITM DataMart, MongoDB-backed, for advanced analysis beyond typed tools. This clearly distinguishes it from typed sibling tools such as get_project or search_tasks.

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 clearly frames usage as 'advanced analysis beyond typed tools' and routes agents away from projecting full embedded arrays toward dot notation or subcomponent tools. It also points to get_custom_fields and get_custom_field_options for field metadata, though it does not enumerate explicit when-not cases for every operation.

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