Target Customer Authentication MCP Server - provides interactive authentication UI components for Target customer sign-in
Server has 3 tools with explicit schemas and descriptions. Naming follows verb_noun pattern (create-, authenticate-, get-). Descriptions are present (60-180 chars) and explain prerequisites/sequencing. However, parameter descriptions are minimal or missing for some fields. Output schemas are not documented, responses return unstructured text + structuredContent without formal schema declaration. Tool annotations (readOnlyHint, destructiveHint) are present and correct. Error handling is absent, no recovery guidance or actionable error messages. Composition is reasonable (3 focused tools in a workflow), but lacks pagination, batch operations, and structured output documentation.
STEP 2: Show Target authentication UI. REQUIRES sessionId from create-target-session (STEP 1). DO NOT call this until you have a sessionId from create-target-session. After user completes auth, use get-target-auth-status to check status.
STEP 1: Create a new Target authentication session. You MUST call this FIRST to get a sessionId. Returns a sessionId that must be passed to authenticate-target.
Check authentication status and retrieve user profile. Call this AFTER the user has clicked the authentication link and says they have signed in. Returns authenticated customer name and email. No UI is shown.
Output schemas not documented. Tools return {content: [{type, text}], structuredContent: {...}} but no formal schema declares what fields structuredContent contains or their types. LLMs cannot plan downstream calls without knowing return structure.
Parameter descriptions incomplete. 'sessionId' in authenticate-target and get-target-auth-status lacks format/constraint details. No description of what sessionId format is (e.g., 'sess_*' prefix), making validation unclear.
No error handling or recovery guidance. If sessionId is invalid, expired, or not found, the tool returns no actionable error message. LLM cannot self-correct or know whether to retry, ask user, or call a different tool.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2025-06-18+ | v2 |
Tool descriptions use imperative language ('MUST call this FIRST', 'DO NOT call this until') rather than declarative descriptions of what the tool does. This is prompt-engineering anti-pattern; descriptions should state function, not command the LLM.
No pagination or result limits documented. If get-target-auth-status returns user profile data, no schema specifies fields, types, or max response size. Unstructured responses waste tokens and invite parsing errors.