frpdeck defines 10 tools with generally clear naming and reasonable descriptions. Most tools follow verb_noun conventions (add_proxy, remove_proxy, list_proxies). Input schemas are present for all tools with proper JSON Schema formatting, including enums, type constraints, and parameter descriptions. However, several issues limit the score: (1) descriptions are adequate but generic in places, lacking actionable recovery guidance for errors; (2) output schemas are documented in code but not visible in the provided excerpt, making full validation impossible; (3) error handling is present but doesn't follow the recovery-guide pattern consistently; (4) some parameter descriptions are minimal (e.g., 'Proxy name' for the 'name' param lacks context on valid formats or length); (5) the 'patch_spec' parameter in update_proxy is poorly constrained, it accepts arbitrary key-value pairs with no schema or validation hints; (6) tool composition is good overall, but instance_dir is required on every tool despite being repetitive, suggesting the server could benefit from context binding.

• Refactor update_proxy's 'patch_spec' parameter into explicit parameters or a strict enum of allowed keys with documented types. E.g., 'enabled' (bool), 'description' (string), 'remote_port' (int for tcp/udp only). Provide clear error messages when invalid keys or type mismatches are detected.
• Enhance parameter descriptions with format, length, and constraint details. For 'name' parameters across all tools, add: 'Proxy name (alphanumeric and hyphens, 1 - 64 chars, case-sensitive).'
• Document the FacadeResult schema explicitly in the tool descriptions or in a separate type definition visible to LLMs. Include sample output structures showing what fields agents can expect (success flag, error_code, data payload, validation_errors, etc.).
• Implement and document error recovery guidance. For each tool, specify: (1) common error codes (not_found, already_exists, invalid_input, permission_denied), (2) what to do next ('Use list_proxies to verify the name, then retry'), and (3) whether the error is retryable or user-fixable.
• Add a preview or dry-run mode to remove_proxy or implement a confirmation-before-delete pattern. E.g., add an optional 'dry_run: bool' parameter (defaulting to false) that previews the deletion without executing it.
• Add pagination support (limit, offset) and return metadata (total_count, next_offset) in list_proxies and preview_proxy_changes responses. Set a reasonable default limit (e.g., 20) and cap maximum to prevent context exhaustion.
• If instance_dir is typically constant within a session, consider adding support for an initialization step or configuration that binds the server to a default instance. This would reduce parameter repetition and simplify tool invocations.

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

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