Four well-structured GST tools with complete JSON schemas, clear descriptions (100-200 chars), and proper parameter typing. All tools declare input schemas with zod validation. Naming follows verb_noun pattern (gst_validate_*, gst_einvoice_*, gst_reconcile_*). Descriptions explain WHAT, WHEN, and output. However, output schemas are not documented in tool definitions, LLMs cannot see what fields to expect from responses. Error handling is minimal; no recovery guidance or actionable error messages visible. Tool composition is sound (each does one thing), but parameter descriptions lack format constraints (e.g., 'date must be YYYY-MM-DD' is stated but not enforced via regex in schema). Security: no secrets in params (good), but no audit logging or permission gates visible.

• Document return types for all tools. Add a 'Returns' section to each tool description or a separate schema field showing output structure (e.g., 'Returns: {valid: boolean, errors: string[], extracted_pan: string}').
• Implement structured error responses with classification. Return {error: string, code: 'INVALID_GSTIN'|'MISSING_FIELD'|'NETWORK_ERROR', retryable: boolean, suggestion: string} so LLMs know whether to retry, ask the user, or fail.
• Move seller_public_key_pem from tool parameter to server-side configuration. Load it from environment variable or vault at startup; do not expose it as a parameter.
• Add format constraints to zod schemas. Use z.string().datetime() for dates, z.string().regex(/^\d{6}$/) for pincodes, z.string().length(15) for GSTIN. This makes constraints machine-parseable.
• Add audit logging. Log every tool call with caller identity, parameters (excluding secrets), timestamp, and result. This enables compliance tracing and debugging.

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

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