Server has 14 tools with basic schemas and descriptions. All tools have names starting with action verbs (get_, list_, trigger_, rescale_) and descriptions present. However, descriptions are terse (10-50 chars for most tools), parameter descriptions are minimal or absent, and output schemas are not documented. Two write-operation tools (trigger_savepoint, rescale_job) include approval tokens for governance, which is good practice. No tool annotations (readOnlyHint/destructiveHint) visible in code. Schemas show basic type info but lack depth, most parameters have only type and description, no constraints, enums, or ranges. Error handling and recovery guidance not evident in tool definitions.

• Expand tool descriptions to 100-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and what it returns. E.g., 'List all active Flink jobs with their IDs, status, and submission time. Use this to discover available jobs before calling get_job for details. Returns paginated results (default 20 per page).'
• Document output schemas for all tools. Add a 'Returns' section to each tool definition specifying field names, types, and meanings. E.g., get_job returns {jobId: string, name: string, status: enum[CREATED|RUNNING|FINISHED|FAILED|CANCELED], startTime: ISO8601, ...}.
• Add pagination parameters (limit, offset) to all list_* tools. Set sensible defaults (limit=20) and document max limits. Return a total_count or next_cursor field to enable multi-page iteration.
• Enrich parameter descriptions with format, constraints, and discovery hints. E.g., jobId: 'The Flink job ID (UUID format). Obtain via list_jobs() if you only have a job name.'
• Add tool annotations (readOnlyHint, destructiveHint) to tool definitions. Mark trigger_savepoint and rescale_job as destructive to signal to agents that these operations have side effects and should be confirmed.

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

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