MCP server that exposes Paragon integration actions as tools, with support for dynamic OpenAPI specs, custom tools, and proxy API requests
The Paragon MCP server exposes 2 tools with significant quality gaps. Tool naming follows verb patterns (CUSTOM_NOTION_CREATE_PAGE, CALL_API_REQUEST), but parameter descriptions are incomplete and schemas contain errors. The CUSTOM_NOTION_CREATE_PAGE tool has a typo in the schema ('descriptions' instead of 'description' in JSON Schema), making it non-compliant with JSON Schema spec. CALL_API_REQUEST is overly generic and accepts arbitrary HTTP parameters without proper documentation of expected formats or constraints. Both tools lack comprehensive error handling guidance and output schema documentation. Error handling is present at the server level but not integrated into tool response design.
Call an API if no tool is available for an integration that matches the user's request. Always follow the user's instructions regarding required and optional parameters.
Use this tool to create a page in Notion
Schema contains JSON Schema syntax error: 'descriptions' key instead of 'description' in CUSTOM_NOTION_CREATE_PAGE inputSchema (line in custom-tools.ts). This violates JSON Schema spec and will fail validation.
CALL_API_REQUEST tool name is generic and ambiguous. 'CALL_API_REQUEST' does not convey what action happens or what API is being called. LLMs cannot infer intent from the name alone. Violates verb_noun naming convention. Should be scoped by integration type or action (e.g., 'make_api_request_to_integration' or split into integration-specific tools).
CALL_API_REQUEST description is minimal (93 chars) and lacks critical context. Does not explain WHEN to use this vs a dedicated integration tool, what formats are supported for queryParams/headers/body, or error handling behavior. LLMs cannot determine if this is the right tool.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 48 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 36 | - | v1 |
CALL_API_REQUEST parameters 'queryParams', 'headers', 'body' are typed as plain 'object' with no schema constraints. No documentation of required vs optional fields, data types, or formatting rules. LLMs will guess at structure and pass invalid payloads.
Neither tool documents output schema. LLMs do not know what fields to expect in responses, making downstream tool chaining impossible and forcing extra discovery calls.
CUSTOM_NOTION_CREATE_PAGE description (52 chars) is too terse and lacks context about prerequisites (Notion workspace must be connected), expected markdown format, or what fields are returned. Baseline average param description is 72 chars; this fails to meet standard.
CALL_API_REQUEST accepts 'integration' as a free-form string with no enum constraint. No documentation of valid integration names. LLMs will hallucinate invalid integration values and fail calls.
No error classification in tool descriptions. Tools do not tell LLMs which errors are retryable, user-fixable, or fatal. Error responses require a recovery guide.
CALL_API_REQUEST is a dangerous 'generic proxy' tool that bypasses integration-specific controls. No mention of rate limits, timeout handling, or permission verification. This violates the principle that each tool should do exactly one thing, this tool does everything.