Loading ToolBench
MCP server for social media source listening and profile management. Supports adding sources from multiple platforms (RSS, YouTube, X/Twitter, Facebook, Reddit, GitHub, websites) and managing contributor profiles with social URLs and member types.
This server has 6 tools with mixed quality. All tools have descriptions and input schemas are present, but descriptions are often generic and lack actionable detail. Parameter descriptions vary in quality, some are clear, others are minimal. The tool names follow verb_noun convention which is good, but the descriptions do not consistently explain WHEN to use each tool, WHAT happens as a result, or dependencies between tools. Output schemas are not documented. No tool annotations (readOnlyHint/destructiveHint) are present despite clear WRITE vs READ_ONLY semantics. Error handling is not visible in tool definitions. The largest concern is that this is a data manipulation server with significant write operations (add_new_source, add_new_profile, update_profile_social_urls, clean_github_profiles, add_member_type_for_profiles) but no confirmation patterns, dry-run modes, or recovery guidance are documented.
Adds a member type for profiles in the Parquet file.
Adds a new profile to the Parquet file.
Add a new resource to the social listening system.
Cleans up GitHub profiles in the Parquet file.
Lists all usernames from the profiles Parquet file.
Updates social URLs for a profile in the Parquet file.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences. 5 of 6 tools are WRITE operations that mutate state, but LLMs cannot detect this from the definition. Tools should declare whether they are read-only or destructive to guide agent decision-making.
Output schemas not documented. Tools like list_usernames_from_profiles and add_new_profile do not declare what fields they return. Without output schema documentation, LLMs cannot plan downstream tool calls or extract required data fields.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 52 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 48 | - | v1 |
Descriptions lack WHEN/WHY context and dependencies. For example, 'Adds a new profile to the Parquet file' does not explain: when should an LLM call this vs update_profile_social_urls? What are prerequisites (does the username need to exist first)? What does 'type' (dwarves/alumni/community) control?
No error handling guidance in tool definitions. No documentation of what happens on invalid input (e.g., adding a profile with an invalid URL format, or a username that doesn't exist in clean_github_profiles). LLMs need recovery paths.
Destructive operations (clean_github_profiles, update_profile_social_urls) lack confirmation patterns. LLMs may inadvertently clean all profiles or bulk-update URLs without user approval. add_member_type_for_profiles is also bulk and irreversible.
Parameter descriptions are minimal or missing context. 'type' enum values (dwarves, alumni, community) are undocumented, what do they mean? When does an LLM choose one over another? Similar issue with 'category' and 'region' in add_new_source_to_social_listening, no explanation of what these control.
add_new_source_to_social_listening has optional 'type', 'category', and 'region' but the description says 'Only use this if the category is specifically mentioned.' This is confusing, is 'category' required or optional? The enum + optional flag does not align with the description text.
Tool composition gaps: add_new_profile and add_member_type_for_profiles both operate on profiles but it's unclear if a new profile must have a type set immediately (add_new_profile) or if type is added later (add_member_type_for_profiles). Dependency flow is undocumented.