Loading ToolBench
MCP server + scraper for analyzing replies on Threads posts
ThreadsDatabase has 4 tools with basic descriptions and input schemas, but significant gaps in parameter documentation and output structure. Tool names follow verb_noun convention (scrape_thread, get_all_replies, search_replies, get_reply_stats), which is good. However, parameter descriptions are minimal or missing entirely. For example, scrape_thread's 'url' parameter has a description, but 'max_scrolls' lacks guidance on what happens at the boundary (what if max_scrolls=0?). Output schemas are not documented, tools return plain strings rather than structured JSON, forcing LLMs to parse unstructured text. Error handling exists but is generic ('Scraping failed: {exc}') without recovery guidance. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear semantic differences (scrape_thread is destructive/write, others are read-only). The server lacks pagination support, result limits, and field-level output documentation.
Get all scraped Threads replies. Returns a formatted list of all replies with username, timestamp and text. Call scrape_thread first if no data exists yet.
Get statistics about the scraped replies. Returns reply count, unique users, most active commenters, and time range of replies.
Scrape replies from a public Threads post URL. Opens a browser, navigates to the post, intercepts GraphQL API responses to extract replies, and saves them locally. This must be called before using get_all_replies or search_replies.
Search Threads replies for a keyword (case-insensitive). Args: keyword: The search term to filter replies by. Returns matching replies with username and text.
No output schemas documented. All tools return plain strings instead of structured JSON. LLMs cannot parse results reliably or chain tools without manual text parsing.
Parameter descriptions are incomplete or missing. 'max_scrolls' has no guidance on valid range, boundary behavior, or performance impact. 'keyword' in search_replies lacks case-sensitivity clarification (though code shows case-insensitive).
No tool annotations. scrape_thread is destructive (writes CSV, opens browser) but lacks destructiveHint. get_all_replies, search_replies, get_reply_stats are read-only but lack readOnlyHint. Agents cannot infer safety properties.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 52 | <=2025-11-25 | v2 |
Error messages lack recovery guidance. 'Scraping failed: {exc}' and 'Error reading replies: {exc}' tell the LLM nothing about what to do next. Should suggest 'Try a different URL' or 'Call scrape_thread first'.
No result limits or pagination. get_all_replies and get_reply_stats return all data as a single string. A thread with 10,000 replies would blow the context window. No limit parameter, no pagination cursor, no total count in structured form.