Skip to main content
Glama

query

Read-onlyIdempotent

Query the manufacturer's live data with an RSQL filter. Datasets: order (Orders and quotes share the same entity. The state field distinguishes QUOTE, ORDER, and DRAFT. Payment status is independent: a placed PO/invoice order can remain UNPAID until settlement. 'price' is the order total in the order's own 'currency'; 'localPrice' is the same total converted to the operator's home currency ('localCurrency'). Sum localPrice (not price) to compare revenue across orders in different currencies. 'source' is the sales channel: INBOUND = placed by the customer through the storefront (self-service, online); OUTBOUND = created and sent out by the manufacturer's team (a staff-built quote). Filter or group by source to split self-service vs staff-created orders.); partRevision (Part revisions (a versioned 3D part). 'designName' is the manufacturer's INTERNAL name for the part design — not what the customer sees; when a user names a part they usually mean the customer-facing requisition.name, so prefer that for matching user references. Geometry detail is via inspectPartRevision.); partSpecification (Part specifications: how a part revision is to be made (process, material, finish).); productionStep (A stage in production: a build group of parts undergoing one operation (e.g. 3D Print, Post-Process, Quality Control). Parts move from step to step as they are manufactured.); customerOrganisation (Customer organisations (the manufacturer's customers).); cart (Storefront shopping carts (status OPEN, CONVERTED to an order, or DELETED). Use for conversion analysis.); requisition (Requisitions: a part specification ordered on an order (the order line item; carries quantity and pricing). 'name' is the CUSTOMER-FACING part name — this is what customers and users call the line, so match it when someone refers to a part by name (filter name=="...", or name-contains via RSQL). It is distinct from the manufacturer's internal partRevision.designName; the same physical part can have a different customer-facing name here. pricePaid is the actual per-line revenue in the parent order's currency; localPricePaid is the same in the operator's home currency (sum this for cross-order revenue). quotedPrice is a snapshot taken at quote time and can be stale (use explainPrice to recompute).); workOrder (Work orders: production execution for a requisition (quantity to build, routing template). 'steps' is the ordered list of operations this work order will go through on the shop floor (its routing) — read it to know what will be done to build this order.); processPrices (Manufacturing processes and their pricing configuration. 'pricingAlgo' says how a process is priced: TS_EQUATION processes use a TypeScript pricing equation (activeTypescriptEquationId; read it with describePricingEquationApi(includeSource=true)); any other value is a legacy built-in algorithm with no equation to read. The row folds in the process's setup: boundingBox (max part size L x W x H), bulkQuantities (the quantity breaks shown for bulk pricing), materialVariables (the per-material variable names the equation reads), and counts of materials, post-processings, precision and infill options. isInternal processes are hidden from the storefront. A row with a customerOrganisationId is a customer-specific copy of a process.); materialPrices (A material's pricing configuration for one process (a process x material pairing). Carries the material (materialId/materialName), its density, and 'variables' — the material's TypeScript-equation variable values (operator-defined name=value pairs the pricing equation reads off the material). Use to see a material's rates without reverse-engineering them from quotes: filter by processPricesId and materialId (both from partSpecification). The 'variables' text isn't itself filterable — filter on materialId/processPricesId/density/isDefault instead. Rates are process-specific, so the same material can appear once per process.); postProcessing (Post-processing / finishing options the manufacturer offers (e.g. painting, polishing). 'type' says how it is priced: TS_EQUATION ones have their own TypeScript equation (activeTypescriptEquationId; read it with describePricingEquationApi(scope=POST_PROCESSING, ownerId, includeSource=true)); any other type is a legacy built-in formula with no equation to read. 'processes' lists the processes it is available on, 'operations' the shop-floor operations it adds, 'colors' its colour choices and 'incompatibleMaterials' the materials it cannot be applied to. Options sharing a mutuallyExclusiveGroup cannot be combined on one part.); typescriptEquation (TypeScript pricing equations (metadata only — describePricingEquationApi(includeSource=true) for the live source). 'scope' is PROCESS (processPricesId), POST_PROCESSING (postProcessingId) or ORDER (the operator's single order-level equation that adds whole-order line items; both ids null); 'isLive' tells whether it is the one currently used for quoting. Several draft equations can sit next to the live one; 'origin' is UI or MCP (written through save) and 'createdBy' the authoring user.); operation (Manufacturing operations (shop-floor stations) in 'sequence' order, e.g. 3D Print, Post-Process, Quality Control. Parts move operation to operation; batches moved at an operation are grouped into production steps (build groups). Column meanings: productionStepType is the station kind — BASE (a normal station), DOWNLOAD_PARTS_AS_GROUP (parts are downloaded as one build file), UPLOAD_THREED_NESTED (a nested build / bill of parts is uploaded), QUALITY_CONTROL (inspection; scrap is recorded here). viewType is the backlog's default view at this station: PART lists individual parts, BUILD lists build groups. buildConstraint says which parts may share one build group: NONE, MATERIAL (same material), MATERIAL_AND_COLOR, MATERIAL_AND_SHEET_THICKNESS. stepNamePrefix + stepNamingStrategy control how a new build group is named when a batch arrives: ALWAYS_RENAME (new name every time), RENAME_IF_BUILD_CHANGED (new name only when the build composition changed), INHERIT_FROM_PREVIOUS (keep the previous station's group name). allowOverproduction lets staff move more parts than the ordered balance. durationHours is the planning estimate for time spent at the station. isCompletedStatus marks the station whose exit means the part is finished. automations run when staff progress parts here (NOTIFY_ON_ORDER_COMPLETED). Referenced by productionStep.operationId and scrap.operationId.); batchMovement (Forward batch moves through production: each row is a batch of parts ADVANCING from one operation to the next (throughput). Scrap events are NOT here — see the scrap dataset for those. 'batchSize' is the quantity that moved; 'operationName' is the operation the batch left; 'toOperationName' is the one it moved to. Filter by createdAt for a time window or requisitionId/workOrderId for one job. For a SCRAP RATE by operation, aggregate sum(batchSize) here grouped by [operationName] (the parts that passed) and aggregate scrap the same way (the parts scrapped); rate = scrap / (scrap + moved) at each operation.); scrap (Scrap events: parts scrapped as they move through production. This is the floor-wide scrap log — query or aggregate it DIRECTLY for any scrap question; do not gather scrap by iterating requisitions or getProductionHistory. 'reason' is the free-text scrap cause; 'batchSize' is the quantity scrapped; 'operationName' is the operation the scrap happened at; filter by createdAt for a time window or requisitionId/workOrderId for one job. To find what causes the most scrap, aggregate sum(batchSize) grouped by reason (or operationName). For a scrap RATE you also need the parts that passed — aggregate the batchMovement dataset by operationName and divide.); material (The material catalogue (platform materials plus the manufacturer's own). Rates are NOT here — a material only has prices once it is paired with a process; query materialPrices (materialId==) for those.); color (Colour options. Each colour belongs to one materialPrices row (a material on a process) or to one post-processing; 'kind' says which and the matching *Id column points at the parent.); jurisdiction (The platform's tax-jurisdiction catalogue: every code a taxJurisdiction can be created for, with its name and country. Platform reference data, identical for every manufacturer (not tenant data). Use it to find the isoCode for save(entity="taxJurisdiction"): filter by country (the Country enum name, e.g. GERMANY) and read the region names; DEFAULT and EXEMPT are the two special codes.); leadTime (Lead-time options offered at checkout. 'buffer' is the number of days added to the production estimate; the default one is pre-selected on the storefront and read by the pricing equation.); precisionPrices (Precision / tolerance options sold per process, each with a price adder. A row with a customerOrganisationId is a customer-specific override of the base option.); infill (Infill options per process (FDM-style density presets). 'infillValue' is the fill percentage; the default is pre-selected on the storefront. A row with a customerOrganisationId is a customer override.); taxJurisdiction (Tax setup per jurisdiction (country / region). 'components' lists the tax components applied (name and percentage) and 'totalPercentage' their sum. The DEFAULT jurisdiction is the fallback when a customer's address matches nothing; EXEMPT is used for tax-exempt customers.); taxComponent (Reusable tax components (e.g. VAT 19%) that jurisdictions combine. See taxJurisdiction.components for where each is applied.); paymentTerm (Payment terms offered to customers (e.g. Net 30). accountingSystemTermId links the term to the connected accounting system.); discount (Discounts: GENERIC (a code any customer can use), CUSTOMER (a code for one customer) or INSTANT (applied automatically). Active means endTime is in the future.); shippingBox (Shipping box sizes used to pack orders (dimensions in unitBasis).); shippingMethod (Shipping methods offered at checkout. shippingMode is FIXED_PRICE (flat price, optional weight tiers and a country list), CARRIER_ACCOUNT (live rates from the manufacturer's carrier account) or SELF_COLLECTION (pick-up). Tier and country detail is folded into the row.); routingTemplate (Routing templates: the ordered operations a work order goes through. 'steps' is the sequence of operation names. A template can be generic or bound to one partSpecification. When the storefront setting isApprovedRoutingTemplateRequired is on, only approved templates can be used.); kanbanColumn (Order-board (kanban) columns in display order. 'automations' lists what fires when an order enters the column (NOTIFY_CUSTOMER_OF_NEW_STATUS, SEND_INVOICE, SEND_ORDER_CONFIRMATION).); documentTemplate (Document templates (order confirmation, invoice, estimate, traveller sheets, labels) per language. Metadata only — use getDocumentTemplate(id) to read the HTML content.). Operators: == != =gt= =ge= =lt= =le= =in=(a,b) =out=(a,b); combine with ';' (AND) and ',' (OR). Each row is returned as 'field=value' pairs and always includes its id and foreign keys (the join keys); pass 'fields' to select specific columns (any field from describeQueryableFields). Call describeDataModel to see how datasets relate, and describeQueryableFields(entity) to learn a dataset's filterable fields.

Input Schema

TableJSON Schema
NameRequiredDescriptionDefault
sortNoSort as 'field,asc' or 'field,desc', using a field listed by describeQueryableFields.
limitNoMax rows (1-50, default 20).
entityYesWhich dataset to query. One of: order, partRevision, partSpecification, productionStep, customerOrganisation, cart, requisition, workOrder, processPrices, materialPrices, postProcessing, typescriptEquation, operation, batchMovement, scrap, material, color, jurisdiction, leadTime, precisionPrices, infill, taxJurisdiction, taxComponent, paymentTerm, discount, shippingBox, shippingMethod, routingTemplate, kanbanColumn, documentTemplate.
fieldsNoOptional: choose which columns to return, by field name. Any field listed by describeQueryableFields(entity) can be selected. The row 'id' and foreign-key ('*Id') fields are always included. Omit for the default columns.
filterNoRSQL filter, e.g. field==value;other=gt=5 (';'=AND, ','=OR). Call describeQueryableFields for the valid field names. Omit to return recent rows.

Schema Changelog

Changes observed during successful MCP inspections.

  1. First observed

TDQS

A4.6/5.0
Behavior4/5

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

Annotations already carry the safety profile (readOnlyHint=true, idempotentHint=true, destructiveHint=false), so with that bar lowered the description adds genuine behavioral detail beyond them: rows return as 'field=value' pairs, always include id and foreign keys, fields selects columns but id/FK stay included, limit defaults to 20, and filter combines with ';'=AND / ','=OR. No contradiction with any annotation.

Agents need to know what a tool does to the world before calling it. Descriptions should go beyond structured annotations to explain consequences.

Conciseness3/5

Is the description appropriately sized, front-loaded, and free of redundancy?

Purpose is front-loaded and the body is consistently organized dataset-by-dataset with a parallel structure, which is a strength. However, the description runs several thousand words; while each parenthetical adds semantic value, the aggregate length strains an agent scanning for selection and pushes against 'every sentence earns its place.' Dense and defensible, but heavy for orientation.

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?

Exceptionally complete for a 29-dataset query tool with 100% schema coverage and no output schema: it covers dataset semantics, operator set, result format, default limit, and routes deeper access to describeQueryableFields, describeDataModel, describePricingEquationApi, inspectPartRevision, and explainPrice instead of duplicating exhaustive field lists. Nothing needed to pick a dataset or compose a filter is missing.

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 coverage is 100% so the baseline is 3, but the description adds the tool's real value: semantic distinctions the schema's enum list cannot convey — price vs localPrice for cross-currency revenue, requisition.name vs partRevision.designName for user reference matching, source INBOUND/OUTBOUND for channel splits, materialPrices 'variables' not being filterable, and the price vs quotedPrice staleness note. The RSQL operator syntax is also expanded well beyond the schema's single example.

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 opening sentence states a specific verb (query), resource (manufacturer's live data), and mechanism (RSQL filter), making the tool's role unambiguous before the 29-dataset enumeration. It also delimits what it is not by pointing to describeDataModel and describeQueryableFields, and it is clearly distinct from sibling aggregate (aggregation) and the various describe/lint/save tools.

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?

Routing guidance is explicit and recurring: 'do not gather scrap by iterating requisitions or getProductionHistory' tells the agent to query scrap directly; 'Rates are NOT here — query materialPrices (materialId==<id>)' redirects to the correct dataset; every typescriptEquation/postProcessing points to describePricingEquationApi(includeSource=true) for live source; stale quotedPrice is handled via 'use explainPrice to recompute'; and describeQueryableFields/describeDataModel are named for field and relationship questions. These are concrete when-vs-alternative decisions, not vague context.

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

Try in Browser

Glama MCP Gateway

Add one secure layer between your agents and this server.

Resources