Official MCP server for Notion API that converts OpenAPI specifications into MCP tools
Critical failure: The single tool 'API-{operationId}' has NO visible input schema definition in the source code. The schema property shows an empty object with additionalProperties=true, which violates the constraint that parameters must have type definitions. Description is generic boilerplate ('Dynamically generated from OpenAPI specification'), under 20 chars of actionable guidance. No parameter descriptions, no output schema documentation, no error handling guidance. Tool names are not verb-noun patterns; they are templated placeholders. This server exposes raw OpenAPI operations without abstraction, forcing LLMs to reason about unfamiliar API semantics. No evidence of schema validation, input sanitization, or recovery guidance.
Dynamically generated from OpenAPI specification - each operation in the Notion API OpenAPI spec becomes a tool
Input schema is empty object with additionalProperties=true. No parameter types, constraints, or descriptions visible.
Tool description is generic boilerplate ('Dynamically generated from OpenAPI specification'). Does not explain WHAT the tool does, WHEN to use it, or what it returns.
Tool name 'API-{operationId}' is a templated placeholder, not a verb-noun pattern. LLMs cannot infer intent from 'API-*'. Violates naming baseline: '90% of A+ tools start with an action verb.' No distinction between get_*, create_*, delete_* operations.
No output schema documented. LLMs cannot plan downstream calls or extract required fields. Violates baseline: '100% of A+ tools have documented return types.'
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 22 | <=2025-11-25 | v2 |
No error handling guidance. Raw API errors will be returned to LLM without recovery hints. Violates pattern: 'Error responses must tell the LLM what to do next.' No categorization of retryable vs fatal errors.