machship-mcp

Get Recently Created or Updated Consignments

machship_get_recent_consignments

Read-onlyIdempotent

Retrieves consignments created or updated within a UTC date range for sync and polling workflows, with pagination, carrier filtering, and optional notes or reconciliation data.

Instructions

Returns consignments created or updated within a UTC date range. Ideal for sync/polling workflows.

Args:

companyId (number): Company ID
fromDateUtc (string): Start datetime in UTC (ISO 8601)
toDateUtc (string): End datetime in UTC (ISO 8601)
startIndex (number, optional): Pagination start index
retrieveSize (number, optional): Number to retrieve
carrierId (number, optional): Filter by carrier
includeChildCompanies (boolean, optional): Include sub-companies
getNotes (boolean, optional): Include notes in response
getReconciliationData (boolean, optional): Include reconciliation data

Tool call template

Replace each placeholder with a value matching the input schema. Only required parameters are included; add optional parameters as needed.

{
  "id": 1,
  "jsonrpc": "2.0",
  "method": "tools/call",
  "params": {
    "arguments": {
      "companyId": "<companyId>",
      "fromDateUtc": "<fromDateUtc>",
      "toDateUtc": "<toDateUtc>"
    },
    "name": "machship_get_recent_consignments"
  }
}

Input Schema

Name	Required	Description
`getNotes`	No	Include notes in the response
`carrierId`	No	Filter by carrier ID
`companyId`	Yes	Company ID
`toDateUtc`	Yes	End datetime UTC (ISO 8601)
`startIndex`	No	Pagination start index (default 1)
`fromDateUtc`	Yes	Start datetime UTC (ISO 8601)
`retrieveSize`	No	Number of results to return (default 40, max 200)
`getReconciliationData`	No	Include reconciliation data in the response
`includeChildCompanies`	No	Include consignments from child companies

Output Schema

Name	Required	Description	Default
`errors`	No	Validation errors returned by Machship, if any
`object`	No	Response payload from the Machship API

Schema Changelog

Changes observed during successful MCP inspections.

Changed10 schema fields changedv1.0.1Nov 3, 2026

addedInput schema / properties / carrierId / description
```
Added value: +"Filter by carrier ID"
```
addedInput schema / properties / carrierId / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / companyId / maximum
```
Added value: +9007199254740991
```
addedInput schema / properties / getNotes / description
```
Added value: +"Include notes in the response"
```
addedInput schema / properties / getReconciliationData / description
```
Added value: +"Include reconciliation data in the response"
```
addedInput schema / properties / includeChildCompanies / description
```
Added value: +"Include consignments from child companies"
```

addedInput schema / properties / retrieveSize / description

Added value: +"Number of results to return (default 40, max 200)"

addedInput schema / properties / startIndex / description
```
Added value: +"Pagination start index (default 1)"
```
addedInput schema / properties / startIndex / maximum
```
Added value: +9007199254740991
```

changedOutput schema / (root)

Previous value: -nullNew value: +{
+  "$schema": "http://json-schema.org/draft-07/schema#",
+  "additionalProperties": {},
+  "properties": {
+    "errors": {
+      "anyOf": [
+        {
+          "items": {},
+          "type": "array"
+        },
+        {
+          "type": "null"
+        }
+      ],
+      "description": "Validation errors returned by Machship, if any"
+    },
+    "object": {
+      "description": "Response payload from the Machship API"
+    }
+  },
+  "type": "object"
+}

First observedv1.0.0Jun 12, 2026

TDQS

A3.6/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, non-destructive and open-world, so the safety profile is fully covered. The description adds the sync/polling framing and the optional response-shaping flags, but says nothing about result ordering, maximum date-range span, or rate limits that would matter for a polling tool. Useful but not rich behavioral context.

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?

The two opening sentences are well-formed and front-loaded with the key scoping fact. The nine-line Args block then duplicates parameter documentation the schema already carries verbatim-or-better, padding the definition without adding 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?

With an output schema present, rich annotations, and full schema coverage, the description only needs to establish purpose and scoping, which it does. Minor gaps around date-range limits and result ordering keep it from a 5, but an agent can call this correctly from what is given.

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%, so the baseline is 3. The Args block mostly restates the schema, and in a few places is thinner than it ("startIndex: Pagination start index" omits the default of 1; "retrieveSize: Number to retrieve" omits the default 40 and max 200 that the schema states), so it adds no meaning beyond what is already structured.

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 a clear scope: consignments created OR updated within a UTC date range, and ties it to sync/polling workflows. This implicitly separates it from siblings like machship_get_all_consignments or machship_get_active_consignments, but it never names an alternative, so it stops short of explicit differentiation.

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?

"Ideal for sync/polling workflows" gives a concrete use case, which is enough context to pick this over a general list or search tool. It provides no when-not-to-use conditions and no named alternatives for the case where an agent needs a different filter (e.g. carrier-only or status-based retrieval).

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

Deploy Server