Loading ToolBench
MCP server for LinkedIn API interactions including creating posts with media (images, videos, documents) and managing LinkedIn content
Single tool with reasonable naming and basic schema coverage, but critical deficiencies in parameter descriptions, error guidance, and security posture. The 'create_post' tool is well-named and follows verb_noun convention, but parameter documentation is sparse and validation logic, while present, lacks actionable error messages for the LLM. The tool exposes credentials via environment variables (correct), but the server's input validation and error responses do not guide LLM recovery paths. Output schema is not formally documented in the tool registration. The source code shows defensive handling (file existence checks, timeout management, HTTP status handling), but these safeguards are invisible to the MCP schema layer where the LLM makes decisions.
Create a LinkedIn post with optional media (image, video, or document).
Parameter descriptions are incomplete and lack format/constraint guidance. 'media_type' description does not explain the enum constraint explicitly enough for LLM parsing ('Type of media - "TEXT", "IMAGE", "VIDEO", or "DOCUMENT"' reads as prose, not a formal constraint). 'file_path' description says 'Absolute path to media file (required for IMAGE/VIDEO/DOCUMENT)' but LLMs do not reliably parse prose dependencies, this should be formalized in schema or field metadata. 'content' lacks minimum/maximum length guidance.
Tool description (97 chars) is adequate in length but lacks WHEN-to-use guidance and prerequisite clarity. It says WHAT the tool does ('Create a LinkedIn post') but does not explain WHEN an agent should call it vs. alternatives (if any), what authentication is required, or what happens on success. Should state: 'Creates a post on LinkedIn that is immediately published. Requires LINKEDIN_ACCESS_TOKEN and LINKEDIN_MEMBER_URN environment variables to be set.' This guides the agent to verify auth before calling.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
Error responses are generic and do not guide LLM recovery. Example: 'File not found: {file_path}' tells the agent the file is missing but not what to do next. Per the recovery-guide pattern, should return 'File not found: {file_path}. Verify the absolute path is correct and the file exists before calling create_post again.' Similarly, 'Invalid media_type: ...' should suggest 'Must be one of: TEXT, IMAGE, VIDEO, DOCUMENT' in the error message itself, not just in the description.
Output schema is not formally documented. The tool returns a dict with 'success', 'data'/'error'/'message'/'status_code', but the MCP schema layer has no `outputSchema` declaration visible. LLMs need to know the structure of the response (e.g., 'Returns {"success": bool, "data": {"post_urn": string} | null, "error": string | null}') to plan downstream actions. Without it, the agent cannot confidently extract the post URN for later reference.
No idempotency or dry-run support for this destructive (irreversible) operation. LinkedIn posts cannot be easily deleted via this MCP server, once created, they exist. Per the confirmation-request pattern, tool should support a 'dry_run' parameter (default false) to validate inputs without publishing, or should ask for explicit confirmation before executing. This prevents accidental post creation by an agent.
Parameter 'file_path' defaults to null/None but is conditionally required. Schema shows 'default': null, but validation inside the function checks 'if media_type != "TEXT" and not file_path' and returns error. This conditional requirement is not visible to the LLM in the schema, it should be reflected in either: (1) separate overloaded tools (create_text_post vs create_media_post), or (2) explicit schema validation metadata stating 'file_path is required when media_type is IMAGE, VIDEO, or DOCUMENT'.
No rate limiting or quota management visible. LinkedIn API has rate limits (likely per-minute or per-day post creation quotas). If an agent enters a retry loop or calls create_post in rapid succession, it could hit rate limits and receive 429 errors. Tool should either (1) implement server-side rate limiting with clear feedback ('Rate limit reached. Retry after X seconds'), or (2) document the quota in the tool description so the agent knows to space out calls.