Automatic MCP Server & OpenAI Tools Bridge for apcore
APCore MCP exposes a single tool __apcore_approval_check with a clear, functional design. The tool has a well-defined input schema, explicit parameter descriptions, and structured output documentation in the description. However, the tool name violates verb-noun conventions (starts with underscore and uses 'check' instead of a more specific action verb like 'poll_approval' or 'get_approval_status'), and there are no parameter constraints (enums, min/max) defined. The description is adequate (116 chars) but lacks actionable recovery guidance beyond the basic workflow. The tool is narrowly scoped (approval polling only), which is appropriate for a bridge pattern, but the server overall offers limited functionality, this is a specialized integration tool rather than a general-purpose MCP server. The implementation is clean and secure (no secrets in parameters), but the naming and parameter validation fall short of production-grade baselines.
Poll the status of a pending approval request. Returns {approval_id, status, reason}. status is 'pending', 'approved', or 'rejected'. When 'approved', retry the original tool call with _meta.approvalId set to this approval_id.
Tool name violates verb-noun convention. '__apcore_approval_check' starts with an underscore (non-standard) and uses 'check' which is vague. Should be 'poll_approval_status' or 'get_approval_status' to clearly signal a polling/retrieval action.
approval_id parameter has no constraints (type is string with no pattern, enum, minLength, or maxLength). The description says it comes from APPROVAL_PENDING response but does not specify format (UUID, alphanumeric, length). LLMs may pass malformed values.
Tool description lacks error handling guidance. It describes the success path (polling and retrying with approvalId) but does not explain what to do if approval is rejected, if the approval_id is invalid, or if the service times out. LLMs have no recovery strategy for failures.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 61 | 2026-07-28+ | v2 |
Output schema is documented in description text only, not as a formal structured response schema in code. LLMs cannot parse 'returns {approval_id, status, reason}' as a guaranteed contract; it relies on prose parsing.