Skip to main content
Glama
machship-mcp

machship-mcp

Get Linked-From Organisations

machship_get_linked_from_organisations
Read-onlyIdempotent

Retrieve organisations linked into a Machship organisation, such as suppliers and partners, with optional name filtering, sorting, and pagination.

Instructions

Returns all organisations that have linked INTO this organisation (suppliers, partners).

Args:

  • startIndex (number, optional): Pagination start index

  • retrieveSize (number, optional): Number to retrieve

  • sort (string, optional): Sort field

  • searchText (string, optional): Filter by name

Input Schema

NameRequiredDescriptionDefault
sortNoSort field name
searchTextNoFilter results by organisation name
startIndexNoPagination start index
retrieveSizeNoNumber of results to return (max 100)

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. Changed6 schema fields changedv1.0.1
    • addedInput schema / properties / retrieveSize / description
      Added value: +"Number of results to return (max 100)"
    • addedInput schema / properties / searchText / description
      Added value: +"Filter results by organisation name"
    • addedInput schema / properties / sort / description
      Added value: +"Sort field name"
    • addedInput schema / properties / startIndex / description
      Added value: +"Pagination start index"
    • 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

B3.3/5.0
Behavior3/5

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

Annotations already carry the full safety profile (readOnlyHint, idempotentHint, non-destructive, open world), so the description only needs to add context beyond that. It adds nothing about result volume, ordering, pagination behavior with startIndex/retrieveSize, or whether an empty result means no links versus insufficient permissions, which are the practical concerns for a paginated read.

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 single explanatory sentence is well-formed and front-loaded, but the four-line Args block duplicates the input schema verbatim and consumes roughly two-thirds of the description without adding value. Stripping that would leave a tight, effective definition.

Shorter descriptions cost fewer tokens and are easier for agents to parse. Every sentence should earn its place.

Completeness3/5

Given the tool's complexity, does the description cover enough for an agent to succeed on first attempt?

With an output schema present, return values need not be explained, and the four optional parameters are simple. However, given there are four closely related organisation-link siblings, the definition should explicitly situate itself among them; the "linked INTO" phrasing points in the right direction but is easy to conflate with machship_get_linked_to_organisations.

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 merely restates the schema and actually loses information the schema provides (the max of 100 on retrieveSize and the minimum of 1), adding no syntax, format, or default guidance for sort or searchText.

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 first sentence gives a specific verb and resource and crucially disambiguates the direction ("linked INTO this organisation"), with a parenthetical naming what those organisations are (suppliers, partners). That direction is the one thing distinguishing it from the sibling machship_get_linked_to_organisations, but the sibling is never named, so the agent must infer the contrast rather than be told it.

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 direction clarification implies the use case (finding suppliers/partners that have linked in) but there is no explicit statement of when to use this instead of machship_get_linked_to_organisations, machship_get_organisation_links, or machship_get_linked_to_organisations. No prerequisites, no exclusions, and no note that mutating siblings like machship_add_organisation_link or machship_remove_organisation_link are the counterpart operations.

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