Critical failures across all dimensions. The server dynamically generates tools from OpenAPI specs with operationId suffixes (e.g., 'API-createDatabase'). Tool definitions are inferred from OpenAPI metadata, not explicitly registered in MCP code. Input schema shows empty properties object with additionalProperties=true, no actual parameter definitions visible. Tool description is generic boilerplate about OpenAPI derivation, not LLM-optimized guidance on WHEN/WHY to use each tool. No per-parameter descriptions. No output schema documentation. No error handling guidance. This violates core patterns: tool-description, constrained-input, response-shaper, and recovery-guide.

• Explicitly register each Notion API operation as a distinct MCP tool with a verb_noun name (e.g., 'create_database', 'query_database', 'update_page') instead of generic 'API-{operationId}' suffix. This enables LLMs to parse intent from the name alone.
• For each tool, write a 50 - 200 character description answering: What does it do? When should I call it instead of a similar tool? What does it return? Example: 'create_database: Creates a new Notion database with specified properties. Use this to set up a new workspace structure. Returns database_id, name, and created_at.'
• Extract and document the input schema for each operation. For each parameter, include: type (string|number|boolean|object|array), description (20+ chars), constraints (enum, min/max, pattern), and whether it's required. Example: 'parent_type: string (enum: database|page|workspace), The type of parent object. Required.'
• Document the output schema for each operation. Include field names, types, and descriptions. Highlight IDs and references needed for chaining (e.g., 'database_id: string, Use this in subsequent query_database calls'). Cap result lists at 20 - 50 items with pagination support.
• Add error handling guidance. Categorize Notion API errors (e.g., 'invalid_request_body' → user-fixable, 'rate_limited' → retryable, 'unauthorized' → fatal). Return actionable messages: 'Invalid database_id format. Expected UUID (e.g., 550e8400-e29b-41d4-a716-446655440000). Call list_databases() to find valid IDs.'

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

• Relies on Stateful initialize / Mcp-Session-Id (removed; protocol is stateless) - make each request self-contained