MCP server for fetching LinkedIn profile data using the Fresh LinkedIn Profile Data API
Single tool 'get_profile' has a basic description but critical gaps in schema documentation, parameter descriptions, and error handling. The input schema is visible (linkedin_url: string) but lacks constraints, format guidance, or validation rules. Output is returned as raw JSON string with no documented schema. No error recovery guidance. Tool does one thing (acceptable) but lacks production-grade polish.
Get LinkedIn profile data for a given profile URL.
Output schema not documented. Tool returns JSON string but LLM has no visibility into response structure (fields, types, nesting). Prevents downstream tool chaining and forces LLM to parse unstructured text.
Parameter 'linkedin_url' lacks format constraints. No guidance on valid URL format, required domain, or examples. LLM may pass invalid URLs (e.g., 'linkedin.com' vs 'linkedin.com/in/username'). Should specify format and provide validation.
Error handling returns generic 'Unable to fetch LinkedIn profile data.' with no recovery guidance. LLM cannot distinguish between invalid URL, rate limit, API outage, or auth failure. Should return specific error codes and suggest next steps (e.g., 'Try a different profile URL' or 'Rate limited, retry in 60s').
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 42 | 2026-07-28+ | v2 |
API key (RAPIDAPI_KEY) exposed in environment but no documentation of secret injection pattern. While not in tool parameters (good), the server should document that this is server-side secret injection and that agents cannot override it.
No timeout or rate-limit handling documented. Tool sets 30s timeout internally but LLM has no visibility into retry behavior, rate limits, or backoff strategy. Should document expected latency and failure modes.