Skip to main content
Glama
Sign In
machship-mcp

machship-mcp

by devkindhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Manifests

machship_get_manifests
Read-onlyIdempotent

Returns a paginated list of manifests for a company (max 200 per call). A manifest represents a carrier pickup booking for a group of consignments.

Instructions

Returns a paginated list of manifests for a company (max 200 per call). A manifest represents a carrier pickup booking for a group of consignments.

Args:

  • companyId (number, optional): Company ID

  • startIndex (number, optional): Pagination start index (default 1)

  • retrieveSize (number, optional): Number to retrieve (default 40, max 200)

  • carrierId (number, optional): Filter by carrier

  • includeChildCompanies (boolean, optional): Include sub-companies

  • startDate / endDate (string, optional): Date range filter (ISO 8601)

  • response_format ('json' | 'markdown'): Output format (default: 'json')

Returns: Array of manifest summary objects: { "id": number, "manifestDate": string, "carrierName": string, "status": string, "consignmentCount": number }

Examples:

  • Use when: "List today's manifests" -> set startDate/endDate to today

  • Use when: You need a manifestId to download a manifest PDF

Input Schema

NameRequiredDescriptionDefault
endDateNoFilter to date (ISO 8601)
carrierIdNoFilter by carrier ID
companyIdNoCompany ID
startDateNoFilter from date (ISO 8601)
startIndexNoPagination start index (default 1)
retrieveSizeNoNumber of results to return (default 40, max 200)
response_formatNoOutput format: 'json' (default) or 'markdown'json
includeChildCompaniesNoInclude manifests from child companies

Output Schema

NameRequiredDescriptionDefault
errorsNoValidation errors returned by Machship, if any
objectNoResponse payload from the Machship API

Schema Changelog

Changes observed during successful MCP inspections.

  1. Changed8 schema fields changedv1.0.1
    • 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 / includeChildCompanies / description
      Added value: +"Include manifests 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"
+}
  2. First observedv1.0.0

TDQS

A4.2/5.0
Behavior4/5

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

Annotations already declare readOnlyHint, idempotentHint, and destructiveHint=false, so the safety profile is covered. The description adds non-obvious operational facts: hard cap of 200 per call with a default of 40, default startIndex of 1, and the semantic meaning of a manifest. It stops short of mentioning authorization needs, empty-result behaviour, or date-range limits.

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

Conciseness4/5

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

Front-loaded opening sentence with scope and page cap, then Args/Returns/Examples — a predictable, scannable structure. The Args section duplicates the schema descriptions word-for-word, which is the main element that does not earn its place, but overall length is appropriate for an 8-parameter tool.

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?

An output schema exists, yet the description still sketches the manifest summary fields (id, manifestDate, carrierName, status, consignmentCount), and it covers filtering, pagination, and output format. For a read-only list tool with zero required parameters, an agent has everything needed to call it correctly.

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% and the Args block largely restates the schema text verbatim (e.g., "Pagination start index (default 1)", "Number to retrieve (default 40, max 200)"), so little meaning is added beyond structured fields. The only marginal additions are the max-200-per-call cap highlighted up front and pairing startDate/endDate in one line; baseline 3 applies.

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 a specific verb and resource ("Returns a paginated list of manifests"), scopes it to a company, and defines the domain object ("a carrier pickup booking for a group of consignments"). The purpose is unmistakably distinct from neighbours like machship_manifest_consignments or machship_get_manifest_label_pdf, and the closing example explicitly hands off to the PDF-download flow.

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?

The two "Use when" examples give concrete invocation contexts ("List today's manifests" → set startDate/endDate to today; "need a manifestId to download a manifest PDF"). That is a clear when-to-use signal, but there are no exclusions or named alternatives (e.g., how this differs from get_unmanifested_consignments or when to prefer manifest_consignments).

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