This server has 3 tools with explicit definitions. Tool naming follows verb_noun convention (linkedin_get_auth_url, linkedin_exchange_auth_code, linkedin_create_post) and is appropriately specific. However, descriptions are present but minimal (34-89 chars), lacking WHEN-to-use guidance and outcome clarity. Input schemas are present with type definitions for all tools, but parameter descriptions are sparse or missing entirely. The linkedin_create_post tool has conditional parameter requirements (mediaUrl required if mediaType='image') that are documented in descriptions, but this dependency is not formally enforced in the schema itself. Output schemas are not documented, callers cannot know what fields to expect. Error handling guidance is absent; tool implementations catch errors but don't return structured recovery suggestions. The linkedin_exchange_auth_code tool accepts credentials-adjacent input (auth code) but stores tokens server-side, which is correct security practice. Overall, this server demonstrates basic competence in tool naming and input validation but lacks production-grade description depth and output documentation.
Output schemas completely undocumented across all 3 tools. Callers (LLMs) cannot know what fields to expect, forcing them to guess or fail when chaining tools.
Parameter descriptions are sparse (3 - 8 words in many cases). Missing constraint details: postContent length limits? mediaUrl image format/size requirements? articleUrl validation rules? Format patterns? These details are stated only in code comments, not visible to LLM.
linkedin_create_post
Recommendations
Document output schemas for all 3 tools. Example for linkedin_get_auth_url: 'Returns {auth_url: string (authorization URL for user to visit), expires_in: number (seconds until expiration)}'. For linkedin_exchange_auth_code: '{success: boolean, user: {id: string, name: string, email: string}, access_token: string (opaque, server-side storage), expires_in: number}'. For linkedin_create_post: '{post_id: string, post_url: string, created_at: string (ISO 8601), engagement_metrics: {likes: number, comments: number}}'.
Expand tool descriptions to 100 - 200 characters following WHAT-WHEN-OUTPUT format. Example for linkedin_create_post: 'Creates a LinkedIn post with optional image or article media. WHEN: after authenticating with linkedin_exchange_auth_code. Requires memoryKey. Returns post_id and post_url. Image size <10MB, JPEG/PNG only. Article URL must be valid and reachable.'
Add parameter constraints to schema using JSON Schema oneOf/allOf. For linkedin_create_post, model conditional requirement: {oneOf: [{required: ['postContent', 'mediaType'], properties: {mediaType: {enum: ['none']}}}, {required: ['postContent', 'mediaUrl', 'mediaType'], properties: {mediaType: {enum: ['image']}}}]}.
Add detailed constraint descriptions to all parameters. For mediaUrl: 'URL of the image file to upload (must be publicly accessible JPEG or PNG, max 10MB, max 4000x4000px). Downloaded and re-uploaded to LinkedIn via Assets API.' For postContent: 'Main text of the post (max 3000 characters, supports @mentions and #hashtags).'
Conditional parameter dependencies (mediaUrl required iff mediaType='image') are documented in description text, not enforced by JSON Schema. LLMs may not parse description-based constraints reliably, leading to invalid invocations.
No error handling guidance. Tools catch errors (e.g., 'Failed to obtain LinkedIn access token', 'Failed to download image') but do not return structured recovery suggestions or classify errors as retryable/user-fixable. LLM receives raw error text and cannot determine next action.
linkedin_create_post accepts media uploads from arbitrary URLs (mediaUrl, articleUrl). No validation that URLs are safe, reachable, or from allowed domains. Risk of SSRF or hosting malicious content links.
linkedin_create_post
Implement structured error responses with recovery guidance. Example: if image download fails, return {success: false, error: 'Image download failed', reason: 'HTTP 404 Not Found', recovery: 'Verify mediaUrl is publicly accessible and points to a valid JPEG or PNG image', retryable: true}. For auth failures: {success: false, error: 'Invalid auth code', recovery: 'Call linkedin_get_auth_url again and have user visit the new URL', retryable: true}.
Add validation for mediaUrl and articleUrl: check URL scheme (HTTPS), validate domain against allowlist, verify reachability (HEAD request) before passing to LinkedIn API. Log SSRF-suspicious patterns (internal IPs, localhost).
Document tool composition order in descriptions. Example: 'Step 1: Call linkedin_get_auth_url to get authorization URL. Step 2: User visits URL and approves. Step 3: Call linkedin_exchange_auth_code with code from redirect. Step 4: Call linkedin_create_post with memoryKey from exchange step.'
Add memoryKey parameter to tool descriptions. Current code uses memoryKey to store/retrieve auth state, but it is not documented as a parameter. Either expose it as a parameter or document how LLM should pass it (via request context? environment?).