Roxy is a proxy server that delegates tool definitions to upstream backends (FastCGI/HTTP). The three example tools (echo, add, book_flight) have basic schemas and descriptions, but fall short of production quality. Tool descriptions are minimal (10-30 chars), parameter descriptions are sparse, and output schemas are not documented. The book_flight tool accepts only 'destination' as required input, yet the description mentions 'elicitation for missing details', the schema does not reflect what fields will be elicited. No error handling guidance, no output schema documentation, and no tool annotations (readOnlyHint/destructiveHint). The architecture delegates responsibility to backends, which is reasonable, but the example handlers do not demonstrate best practices.

• Expand tool descriptions to 100-200 chars. Example: 'echo' → 'Echoes back the input message unchanged. Use to test connectivity or verify message transmission. Returns the exact input string.'
• Document output schemas for all tools. Example for 'add': 'Returns {"result": number, "a": number, "b": number, "operation": "addition"}'.
• For book_flight, expand the schema to document elicitation fields: add optional parameters (departure_date, return_date, num_passengers, cabin_class) with descriptions, and update the tool description to explain which fields trigger elicitation.
• Add tool annotations to the schema. Mark echo and add with readOnlyHint=true; mark book_flight with destructiveHint=true (booking is irreversible).
• Add error handling guidance to descriptions. Example: 'If destination is invalid, returns error with available airports. If booking fails due to unavailability, suggests alternative dates.'

Inferred effective spec: 2025-06-18+.

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