Loading ToolBench
MCP server for portfolio integration that fetches GitHub profile data, repositories, and statistics
Portfolio MCP Server has 4 GitHub-focused tools with partial schema definitions but significant quality gaps. Only 2 of 4 tools have visible input schemas; 1 tool (get_user_profile) has no schema at all. Descriptions are present but generic and lack LLM-optimization guidance. No parameter descriptions are visible in the provided code snippet. Tool naming follows verb_noun pattern (get_*, positive). No error handling, output schema documentation, or composition guidance is evident. The incomplete code snippet ('No Gi...' truncation in the source) suggests the full implementation may not be in the provided material.
Get recent GitHub activity including push events, create events, fork events, watch events, issue events, and pull request events
Get user repositories
Get GitHub user profile information
Get user statistics including public repos, followers, following, total stars, total forks, most used language, and languages distribution
get_user_profile has no visible input schema; cannot validate whether parameters are defined or constrained.
get_user_stats has no visible input schema despite likely needing a username or user_id parameter.
No parameter descriptions visible for any tool. LLMs cannot infer the purpose of 'limit' or 'sort' parameters without explicit docstrings (rubric baseline: 100% of A+ tool params have descriptions).
No documented output schemas for any tool. LLMs cannot plan downstream calls or extract relevant fields without knowing response structure.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 49 | 2026-07-28+ | v2 |
Tool descriptions are generic (55 - 65 chars) and lack WHEN/WHY guidance. E.g. 'Get GitHub user profile information' does not explain when to call this vs get_user_stats, or what fields the response contains.
No error handling or recovery guidance visible. If a user is not found or API rate limits are hit, the LLM receives no guidance on what to do next.
get_repositories 'sort' parameter is free-form string with no enum constraint. GitHub API accepts 'updated', 'pushed', 'created', 'name', these must be declared as an enum to prevent LLM hallucination.
No composition hints. If get_user_profile returns a user_id, but other tools require username, the response must include both so the agent can chain calls without extra lookups.
Tool descriptions do not state modification behavior. These are all READ_ONLY (correctly), but descriptions should explicitly say 'This does not modify any data' to confirm to LLM that retries are safe.