Skip to main content
Glama
Sign In
machship-mcp

machship-mcp

by devkindhq
OverviewSchemaSourceRelated ServersDiscussionsAdmin
TypeScript
Remote

Get Complex Company Item

machship_get_item_complex
Read-onlyIdempotent

Retrieves a single item by ID with detailed dimensions and packaging data for freight shipment planning.

Instructions

Returns a single complex item (with detailed dimensions/packaging data) by ID.

Args:

  • id (number): Item ID

Input Schema

NameRequiredDescriptionDefault
idYesItem 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.7/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 openWorld, so the safety profile is fully covered. The description adds only that the payload carries detailed dimensions/packaging data — useful context, but no mention of not-found behavior, permissions, or lookup scope, which is the remaining gap for a read tool.

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?

One sentence plus a compact args block; the distinguishing detail (dimensions/packaging) is front-loaded. The Args line duplicates the schema but is brief enough not to harm the definition.

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?

An output schema exists and annotations are rich, so the description need not explain return shape; it just needs to say what is fetched and how it is keyed, which it does. The only shortfall is the absence of any differentiation from the SKU-based sibling, which an agent scanning item tools would benefit from.

Complex tools with many parameters or behaviors need more documentation. Simple tools need less. This dimension scales expectations accordingly.

Parameters4/5

Does the description clarify parameter syntax, constraints, interactions, or defaults beyond what the schema provides?

Schema description coverage is 100% and there is a single required integer id with constraints (exclusiveMinimum, maximum) documented in the schema. The description's 'id (number): Item ID' adds nothing beyond it, but with one fully documented parameter the baseline of 3 is comfortably met and slightly exceeded by the framing of the id as the item identity.

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 ('Returns a single complex item ... by ID') and the parenthetical 'with detailed dimensions/packaging data' distinguishes it from the plain machship_get_item. It stops short of naming the closest sibling (machship_get_item_complex_by_sku), so an agent must infer the retrieval-key difference.

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?

Usage is only implied: the phrase 'complex item (with detailed dimensions/packaging data)' hints that this is the choice when full packaging detail is needed rather than the lean machship_get_item. There is no explicit when-to-use, when-not, or alternative routing against the many item siblings.

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