machship-mcp

Ping / Check Auth Status

machship_ping

Read-onlyIdempotent

Verify current Machship login status and retrieve session properties to confirm authentication and get user/company context.

Instructions

Determines the current user's login status and retrieves session properties from Machship. Use this to verify authentication is working and to get the current user/company context.

Returns: session info including user details, company ID, and permissions.

Input Schema

Name	Required	Description	Default
No arguments

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.

Changed1 schema field changedv1.0.1Nov 3, 2026

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.8/5.0

Behavior3/5

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

Annotations already declare readOnlyHint, idempotentHint, openWorldHint and destructiveHint=false, so the safety profile is fully covered by structured data. The description adds that this is an auth/session check returning user details, company ID and permissions, but that return content is largely duplicated by the existing output schema. It does not mention failure behavior (e.g., what an unauthenticated response looks like), which is the one piece of behavior an agent would most want here.

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?

Three short sentences, front-loaded with the core purpose before usage and return summary. The 'Returns:' line partially restates what the output schema already provides, which is minor redundancy but not harmful bloat.

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 zero-parameter, read-only, output-schema-backed tool, the description covers purpose, usage and return content sufficiently. The only real gap is error/unauthenticated behavior, which matters for an auth-check tool but is a small omission against an otherwise complete definition.

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?

The tool takes no parameters, so there is nothing for the description to disambiguate; baseline for a zero-param tool is 4. Nothing in the description misleads about inputs.

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: determines login status and retrieves session properties from Machship, reinforced by the title 'Ping / Check Auth Status'. An agent can immediately tell this is the auth/session-check tool, though the description does not explicitly name a distinguishing case against siblings (none of which overlap functionally).

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?

'Use this to verify authentication is working and to get the current user/company context' gives clear when-to-use guidance tied to a concrete scenario. It stops short of stating when not to use it or pointing to any alternative, but with zero-parameter scope and no functional siblings, that omission is low-cost.

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

Deploy Server