Single-tool server with critical gaps in schema documentation and parameter descriptions. The tool 'get_clerk_user_data' has a basic description but lacks any input schema definition, parameter documentation, and output structure specification. No validation guidance, no error handling documentation, and no indication of what the response format contains. The tool is registered with name and description only, but the core schema infrastructure that LLMs need to invoke it safely is missing entirely.

• Add a complete JSON Schema to the tool registration defining inputSchema with properties for all parameters. Example: { inputSchema: { type: 'object', properties: { userId: { type: 'string', description: 'The Clerk user ID' } }, required: [] } }. Currently the schema object passed to registerTool is empty.
• Expand the tool description to 150-250 characters explaining what user data is returned (email, name, phone, etc.), when to call it (to fetch authenticated user profile), and any prerequisites (Clerk auth must be configured).
• Document the response structure by adding a detailed description of what fields the returned user object contains and in what format. Include example fields: email, first_name, last_name, phone_number, created_at.
• Add error handling documentation: what happens if the user is not found, if the auth token is invalid, or if the Clerk API is unavailable. Provide recovery guidance for each error class.
• Declare the tool's security scope and permissions. Add a comment or annotation indicating this tool requires Clerk authentication and returns personally identifiable information (PII). Consider whether a destructiveHint or readOnlyHint annotation is appropriate.
• If the tool accepts optional parameters (e.g., includeMetadata, includePhoneNumber), declare them explicitly in the schema with type and description.