Loading ToolBench
A community-driven MCP server framework that lets anyone expose personal information to AI assistants via the Model Context Protocol.
mcp-me demonstrates solid foundational quality with good naming conventions and descriptions, but has several structural gaps that prevent it from reaching higher grades. All 10 tools are explicitly registered with verb-based names ('ask_about_me', 'search_profile', 'get_*') and descriptions present. Descriptions range from 100-370 characters, within the productive range. However, parameter coverage is inconsistent: 'ask_about_me' and 'search_profile' have descriptions for their single parameters, but external API tools (Bluesky, DevTo, GitHub, GitLab, HackerNews, LastFM, LinkedIn) have minimal-to-no parameter descriptions or type definitions beyond the raw schema. Output schemas are undocumented, critical for agent chaining. Error handling is implicit (no recovery guidance visible in code). The core tools show solid intent but plugin-based tools lack polish expected for production use.
Ask any question about this person and get an answer based on their complete profile. Covers: bio, career history, skills, projects, interests, personality, goals, and FAQ. Examples: 'What programming languages do they know?', 'Where do they work?', 'What books have they written?'
Get recent posts from {{handle}}
Get the most recent articles by {{username}}
List public repositories for {{username}}
List projects for {{username}} with optional filters
Get current karma and submission count for {{username}}
Check what {{username}} is listening to right now
External API tool descriptions are generic and lack WHEN/WHY context. 'Get recent posts from {{handle}}' does not explain when to use this tool, what data is returned, or how it integrates with other tools. Descriptions under 60 characters lack sufficient context for LLM tool selection.
Plugin-based tools lack parameter descriptions. 'get_github_repos' has 'language' and 'min_stars' parameters with minimal descriptions (e.g. 'Filter by programming language' vs. 'Filter by programming language (e.g., TypeScript, Python, Rust, case-sensitive)'). LLMs cannot infer valid values or constraints from sparse descriptions.
Output schemas are not documented. Tools return JSON but the structure and field names are not specified in tool definitions. Agents cannot plan chaining (e.g., does get_github_repos return 'repo_id' or 'id'? Does it include 'language' field?). This forces agents to infer structure, risking hallucination.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 58 | 2026-07-28+ | v2 |
Get top artists or tracks for {{username}}
Search through the LinkedIn export data for specific information
Search across the entire personal profile for a keyword or phrase. Searches through: name, bio, job titles, companies, skill names, project names, article titles, book titles, social links, FAQ answers, and more. Returns matching fields with their location in the profile.
No error handling guidance. Code returns results or undefined but does not document what happens on API failures (e.g., Bluesky rate limit, GitHub auth failure, LastFM user not found). Agents receive no recovery hints and cannot self-correct.
Tools like 'get_hn_karma' accept empty input objects but do not explain what username/handle is being queried. The tool description says 'Get current karma... for {{username}}' but {{username}} is a template placeholder, not a resolved value. Unclear how the server knows which user to query.
No explicit parameter validation rules. 'limit' parameters in get_github_repos, get_devto_latest, get_lastfm_top lack explicit min/max constraints in descriptions. LLMs may pass limit=10000 expecting results, causing timeout or server load.
Plugin tools do not document which external services are required or how they are configured. An agent calling 'get_lastfm_top' has no way to know whether the server has a LastFM API key configured. If the key is missing, the agent receives an opaque error with no guidance.