Single tool 'submit_planning_permit' has a well-structured schema with proper enum constraints and date pattern validation. Description is clear and mentions idempotency. However, parameter descriptions are minimal (1-3 words each), falling short of the 72-char baseline for production tools. Output schema is not documented, callers cannot predict the structure of AutomationResult. Error handling is absent from the tool definition; no guidance on retryability or recovery paths. The tool is explicitly registered with schema, so no inference penalty applies.

• Expand parameter descriptions to 50-100 chars each. Example: 'idempotencyKey: A unique, stable identifier (UUID or timestamp-based string) that ensures the same permit is never submitted twice. Reusing the same key returns the cached result.'
• Document the output schema in the tool description: 'Returns {referenceId: string, status: "submitted"|"failed", screenshotBase64: string, timestamp: ISO8601}.'
• Add error handling guidance: 'On failure, returns status="failed" with error details in the response. Safe to retry with the same idempotencyKey, the operation is fully idempotent.'
• Add tool annotations to the schema: include 'idempotentHint: true' and 'destructiveHint: true' (since it modifies external state) to help LLMs reason about safety.
• Migrate from STDIO to HTTP+SSE or Streamable HTTP transport to enable remote deployment and hosted client compatibility.

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

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