MCP server for Azure Face API liveness detection and face verification
This server has critical definition quality gaps. All 4 tools lack proper input schemas (empty objects or missing type definitions). Descriptions are present but generic and under 100 chars, failing to explain WHEN to use each tool or what distinguishes the 'with verify' variants. No output schemas documented. Parameter descriptions are minimal. The tool names are verbose and redundant ('startLivenessAuthentication' vs 'startLivenessAuthenticationWithVerify') rather than using clear verb_noun patterns. No error handling guidance for LLMs. Security concern: environment variables like FACEAPI_KEY are read at startup but not validated for presence before tool execution.
Get the result of liveness session without verify. @param sessionId {string} the session id in the url. @return {string} if the person is real or spoof.
Get the result of liveness session with verify. @param sessionId {string} the session id in the url. @return {string} if the person is real or spoof with verify scores.
Start new a liveness face authentication session without verify. @return {string} the url generated for the user to perform the authentication session without verify.
Start new a liveness face authentication session with verify. @return {string} the url generated for the user to perform the authentication session with verify.
Input schemas are empty objects or missing type definitions. startLivenessAuthentication and startLivenessAuthenticationWithVerify have {} schemas with no parameters defined. getLivenessResult and getLivenessResultWithVerify have sessionId as string but lack minLength, pattern, or format constraints.
Tool names are verbose and redundant. 'startLivenessAuthentication' and 'startLivenessAuthenticationWithVerify' differ only by a suffix; LLMs cannot easily distinguish them from names alone. Should use clearer verb_noun patterns like 'start_liveness_session' and 'start_liveness_session_with_verify' or better yet, a single 'start_liveness_session' tool with a 'verify_image' optional parameter.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 31 | 2026-07-28+ | v2 |
Descriptions lack context for tool selection. All descriptions are under 100 chars and do not explain WHEN to use each variant, what 'verify' means, or what the user should do next. Descriptions should state: What does it do? When should I call it? What does it return? Current descriptions only state the return type.
No output schemas documented. Tools return CallToolResult with text content, but LLMs cannot parse the structure. Should document: Does it return a URL? A session ID? A boolean result? What fields are in the response? This forces LLMs to guess and parse unstructured text.
Error handling does not guide LLM recovery. When FACEAPI_ENDPOINT is missing, the tool returns a generic message. LLMs need to know: Is this retryable? Should I ask the user? What's the next step? Current errors provide no guidance.