Server has 10 tools with basic naming (verb_noun pattern) and minimal descriptions. All tools have input schemas with type definitions, but descriptions are generic and lack LLM-optimization guidance. No output schemas documented. Parameter descriptions are sparse (e.g., 'Search query for people' lacks format/constraint details). No error handling guidance, no idempotency markers, no permission scopes declared. Tool composition is reasonable (single responsibility per tool), but descriptions fail to explain WHEN to use each tool vs. alternatives or dependencies. Baseline: 549 production tools average 194-char descriptions; these average ~50 chars. No tool reaches the 50-200 char LLM-optimized range.

• Expand tool descriptions to 100-200 characters. Include WHAT the tool does, WHEN to use it (vs. similar tools), and any prerequisites. Example: 'Retrieve a LinkedIn person profile by URL or ID. Use this when you have a direct link or LinkedIn ID. For discovering people by name/title, use search_people() first.'
• Document output schemas for all tools. Specify field names, types, and which fields are required for downstream tool calls. Example: 'Returns {profile_id: string, name: string, title: string, company_id: string, ...}'
• Add min/max bounds and format constraints to all numeric and string parameters. Example: 'limit: integer, 1-100 (default 20)' and 'query: string, 1-500 characters, supports LinkedIn search operators'.
• Add idempotency and confirmation markers to send_message. Document that repeated calls with the same recipient_id and message content should be idempotent, or require a confirmation step before sending.
• Add error handling guidance to all tools. Document common failure modes and recovery paths. Example: 'If profile not found, try search_people() with a partial name. If rate limited, wait 60 seconds before retrying.'

Inferred effective spec: <=2025-11-25.

• Relies on Logging (deprecated) - log to stderr or use OpenTelemetry