Loading ToolBench
The server provides 8 tools with consistent naming (verb_noun pattern starting with 'threads_get', 'threads_create', 'threads_reply_to'). However, there are critical gaps in parameter descriptions, output schema documentation, and error handling guidance. All tools have descriptions of reasonable length (60-200 chars), but many parameters lack descriptions or type clarity. No evidence of output schemas being documented for downstream tool chaining. Error handling is absent, no guidance on retries, user-fixable errors, or recovery paths. The tools are well-named and distinct, but fall short of production-grade quality due to incomplete parameter documentation and missing response structure guidance.
Create a new thread (post) with text, image, or video. Can also be used to reply to another thread.
Get the full conversation thread including the original post and all replies
Get insights (analytics) for a specific thread or for the user account
Get the authenticated user's Threads profile including username, name, bio, and profile picture
Get replies to a specific thread
Get a specific thread by its ID
Missing parameter descriptions for 'fields' arrays across 5 tools (threads_get_profile, threads_get_threads, threads_get_thread, threads_get_replies, threads_get_conversation). The description 'Optional fields to retrieve' is too generic and doesn't explain valid field names, expected values, or use cases. LLMs cannot determine which fields to request without explicit enumeration or examples.
No documented output schemas for any tool. The rubric requires documenting return types so LLMs know what fields to expect for downstream tool chaining (e.g., which fields are returned by threads_get_thread so threads_reply_to_thread can reference threadId). Without this, agents cannot reliably compose tools.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 57 | 2026-07-28+ | v2 |
Get the authenticated user's threads (posts) with pagination support
Reply to an existing thread
No error handling or recovery guidance. For example, if threads_create_thread fails due to invalid content, there is no documentation of error types, retryability, or user-fixable conditions. Error messages will not guide agents on next steps. Pattern recovery-guide requires actionable error responses.
threads_create_thread accepts optional 'text', 'imageUrl', 'videoUrl' but does not document that at least one content field is required. Parameter dependencies are undocumented, violating the pattern requirement that 'If parameters are mutually exclusive or have dependencies, state this in descriptions.'
threads_get_insights requires 'metrics' array but does not enumerate valid metric names (e.g., 'views', 'likes', 'replies', 'reposts', 'quotes'). The description mentions examples in parentheses but these should be formalized as an enum or documented constraint. Without this, LLMs will hallucinate invalid metric names.
threads_get_threads accepts 'limit' (1-100, default 25) with proper constraints, but there is no pagination return mechanism documented. No 'next_cursor', 'total_count', or 'has_more' field is mentioned. Agents cannot page through large result sets reliably without documented pagination structure.
No confirmation or dry-run pattern for destructive operations. threads_create_thread and threads_reply_to_thread modify state (WRITE risk), but there is no mention of confirmation steps, dry-run mode, or undo capabilities. This violates the pattern requirement for irreversible operations.
threads_reply_to_thread description says 'Reply to an existing thread' (58 chars), too terse. It should explain WHEN to use this vs threads_create_thread, whether it returns a thread ID for further composition, and any side effects (notifications, visibility rules).