Loading ToolBench
AI-powered content strategy, analytics, and professional networking through the Model Context Protocol
This server has 3 tools with inconsistent quality. debug_context has no input parameters documented, get_my_profile has no input parameters documented, and only get_profile has a detailed input schema. Tool descriptions exist but are generic and lack the specificity needed for LLM tool selection. No parameter descriptions for any of the tools with parameters. Output schemas are not documented. The server uses STDIO transport which severely limits its production utility. No tool annotations (readOnlyHint, destructiveHint) despite claiming READ_ONLY risk classification. Error handling is minimal, debug_context returns raw tracebacks rather than actionable recovery guidance. The tools follow basic verb_noun naming conventions but descriptions lack clarity on WHEN to use each tool vs alternatives, dependencies between tools, and expected return structures.
Debug tool to check the internal state of the MCP server. Returns information about: - Whether LinkedIn client is initialized - Settings configuration - Cookie file status - Initialization errors
Get the authenticated user's LinkedIn profile. Returns profile data including: - Basic info (name, email, picture) - LinkedIn member ID. Uses the Official LinkedIn API (OAuth 2.0) when available for reliable results. Falls back to unofficial API if official client is not configured.
Get comprehensive LinkedIn profile data with multi-source enrichment. Uses the Profile Enrichment Engine to aggregate data from multiple endpoints in parallel, providing the most complete profile information available.
Missing input schemas for debug_context and get_my_profile. Code shows @mcp.tool() async def with no parameters, but no JSON Schema is visible in the provided source. Per hard scoring rules, if schema is not visible, it scores 0.
Output schemas are not documented anywhere in the source. LLMs cannot plan downstream tool calls or structure data extraction without knowing what fields to expect in responses. Every tool must document return type.
Descriptions are generic and lack actionable guidance. 'Get comprehensive LinkedIn profile data with multi-source enrichment' does not explain WHEN to use get_profile vs get_my_profile, what 'multi-source enrichment' means in practice, or what fields are returned. When should LLM call it instead of similar tool? What does it return?
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | <=2025-11-25 | v2 |
| 2026-03-09 | F | 26 | - | v1 |
No parameter descriptions for get_profile. Parameters like 'use_cache', 'include_activity', 'include_network', 'include_badges' have names but no descriptions in the schema visible in source. LLMs cannot infer whether 'use_cache' means database cache, HTTP cache, or browser cache.
debug_context returns raw Python tracebacks ('traceback': traceback.format_exc()) when errors occur. Per error handling pattern, errors must tell LLM what to do next. A stack trace is useless, e.g. 'Cookie file not found at /app/data/cookies.json. Run linkedin-mcp-auth to generate credentials.' is actionable.
No tool annotations despite claiming READ_ONLY risk. FastMCP supports readOnlyHint annotation; none of the three tools declare it. This forces the LLM to infer safety from descriptions, which is error-prone.
Unclear distinction between get_my_profile and get_profile. Both fetch user profiles, but one is 'authenticated user', the other accepts a 'profile_id'. Descriptions do not explain the relationship or when to call each. Per naming patterns, tools with overlapping functionality must make distinctions obvious.
Missing pagination support. get_profile mentions 'multi-source enrichment' but no pagination params (limit, offset, cursor). If enrichment returns dozens of activities or network connections, context window could be exhausted. No mention of result limits or batching strategy.