Critical failure: tools are dynamically generated from OpenAPI spec at runtime. No explicit tool registration visible in source code, tool names, descriptions, schemas, and parameters cannot be statically verified. The generator.py file is referenced but not provided. Without seeing actual tool definitions, schema validation, parameter descriptions, or error handling logic, this server cannot be scored above the inference cap of 50. Additionally, the single 'dynamically_generated_from_openapi' entry is a placeholder description, not a real tool. The server exposes an unknown number of tools with unknown quality. This violates the core principle that tool definitions must be inspectable and documented.

• Replace dynamic tool generation with explicit, static tool registration. Parse the OpenAPI spec at build time (not runtime) and generate a tools.py file with full FastMCP @mcp.tool() decorators, complete with descriptions, parameter types, and docstrings.
• For each OpenAPI operation, create a dedicated tool function with a verb_noun name (e.g., 'create_user', 'list_realms', 'update_client') instead of relying on operation_id. Ensure names are action-oriented and unambiguous.
• Add comprehensive parameter descriptions to every tool. Map OpenAPI parameter descriptions to FastMCP parameter docstrings. Include constraints (enums, min/max, regex patterns) in descriptions, not just in schema.
• Document output schemas explicitly. For each tool, describe the return type and structure. Include pagination info (limit, offset, total_count) if applicable. Strip verbose API metadata and return only fields agents need.
• Implement error handling that guides LLM recovery. Catch HTTP errors (401, 403, 404, 5xx) and return structured error responses with actionable messages (e.g., 'User not found. Try search_users() with a partial name.').

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

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