Critical gaps across all dimensions. Tool definitions lack visible input schemas, parameter descriptions, and output documentation. The 'ship' tool has only a generic description ('Primary workflow execution tool for Ship'). No evidence of JSON Schema definitions, parameter type constraints, or error handling guidance in the provided source. Tool names are reasonable (verb_noun pattern) but descriptions are too brief (10-30 chars) and lack context for LLM selection. No pagination, no structured output specs, no recovery guidance. This server appears to expose raw API surfaces without the abstraction layer required for reliable agent interaction.

• Add explicit JSON Schema definitions for all 14 tools. Each must include parameter types (string, number, boolean, array), required fields, enums for constrained values, and min/max for numeric ranges.
• Expand tool descriptions to 50-200 characters. Include WHAT the tool does, WHEN to use it (vs similar tools), and WHAT it returns. Example: 'Get details of a specific workflow run by ID. Use this after list_workflow_runs to inspect a run's status, logs, and artifacts. Returns run metadata, timestamps, and artifact list.'
• Add parameter descriptions for all inputs. For each parameter, state its type, format, constraints, and purpose. Example: 'workflow_run_id (string, required): The unique identifier of the workflow run to retrieve. Obtain from list_workflow_runs.'
• Document output schemas. For list_* tools, specify the array item structure and include pagination fields (total_count, next_cursor). For get_* tools, list all returned fields and their types.
• Add pagination to list_workflow_runs and list_artifacts: accept limit (1-100, default 20) and offset/cursor parameters. Return total_count and next_cursor in responses to enable multi-page iteration.

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry