linkedin-mcp has 11 tools with complete input schemas and descriptions visible in src/tools.rs. Naming follows verb_noun convention (get-, create-, delete-, search-, send-). However, descriptions are brief (10-100 chars, well below the 194-char baseline), parameter descriptions are sparse or missing, output schemas are undocumented, and error handling lacks recovery guidance. No tool annotations (readOnlyHint/destructiveHint) despite clear risk levels. The manage-accounts tool conflates three distinct operations (list/add/remove) into one tool, violating single-responsibility. search-people explicitly states 'not available in the standard LinkedIn API' yet remains registered, creating confusion. Parameter descriptions often omit format/constraint details (e.g., 'recipient_urn' lacks URN format guidance). No documented output structure for any tool.

• Document output schema for every tool. Example for create-post: 'Returns {post_id: string, created_at: ISO8601, visibility: string, author_urn: string}'. This enables agents to chain calls (e.g., create-post → get-own-posts with post_id).
• Expand parameter descriptions to include format/constraint details. E.g., 'recipient_urn (string, required): LinkedIn member URN in format urn:li:member:NUMERIC_ID or urn:li:person:NUMERIC_ID. Use get-connections to discover valid URNs.'
• Split manage-accounts into three separate tools: list-accounts (no params), add-account (account_name required), remove-account (account_name required). Each tool has one clear responsibility.
• Remove search-people or document a fallback. If removal is not possible, add a note: 'This tool is not available via the standard LinkedIn API. As a workaround, use get-connections and filter results manually, or use a third-party people search API.'
• Add tool annotations to all tools. Mark create-post, create-article, delete-post, send-message with destructiveHint: true. Mark all get-* and search-* tools with readOnlyHint: true. This helps agents reason about side effects and retry safety.