Skip to main content
Glama
Sign In
machship-mcp

machship-mcp

by devkindhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Pending Consignment

machship_get_pending_consignment
Read-onlyIdempotent

Retrieve details for a single pending consignment by ID to inspect its shipment data and status before processing.

Instructions

Returns details for a single pending consignment by ID.

Args:

  • id (number): Pending consignment ID

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": {
      "id": "<id>"
    },
    "name": "machship_get_pending_consignment"
  }
}

Input Schema

NameRequiredDescriptionDefault
idYesPending consignment ID

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. Changed2 schema fields changedv1.0.1
    • addedInput schema / properties / id / 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

A3.5/5.0
Behavior3/5

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

The annotations already declare readOnlyHint=true, idempotentHint=true, openWorldHint=true, and destructiveHint=false, so the safety profile is covered. The description adds only that this returns one pending consignment by ID and does not add further behavioral context such as error behavior or pagination, which is acceptable here but not rich.

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?

The description is front-loaded and short: the core behavior is stated in the first sentence. The following Args block mostly repeats the schema's existing id documentation, which is minor redundancy rather than harmful verbosity.

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 simple single-record getter with an output schema, full parameter description coverage, and clear read-only annotations, the definition is largely complete. The main missing piece is sibling differentiation, especially versus plural pending-consignment lookups and get_consignment_by_pending_id.

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 schema already defines the single required id parameter with type integer and a positive constraint. The description repeats the parameter as 'id (number)' without adding format or lookup semantics beyond the schema, so the baseline of 3 applies.

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?

The description states a specific verb and resource: it 'Returns details for a single pending consignment by ID.' This is clear, but it does not explicitly distinguish itself from close siblings such as machship_get_pending_consignments_by_ids or machship_get_consignment_by_pending_id.

Agents choose between tools based on descriptions. A clear purpose with a specific verb and resource helps agents select the right tool.

Usage Guidelines3/5

Does the description explain when to use this tool, when not to, or what alternatives exist?

The phrase 'by ID' implies that this tool should be used when a single pending consignment ID is known. However, the description gives no explicit when-to-use guidance, no exclusions, and no comparison to the plural or pending-ID-related sibling tools.

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