Loading ToolBench
Model Context Protocol server for authenticating with and publishing posts to Threads via OAuth and the Threads API
This server has fundamental definition quality issues. Only 2 tools are defined, both with severely inadequate documentation. LoginToThreads has an empty input schema and minimal description (90 chars). CreateAndPublishPost has only one parameter with a bare description. Neither tool has documented output schemas. Parameter descriptions are generic and lack context. No error handling guidance, no idempotency hints, no permission gating documentation. Tool names are somewhat clear (verb-noun pattern) but descriptions fail to explain when to use each tool, what they return, or error conditions. The server also exposes authentication tokens via tool parameters (red flag for security), and there is no indication of input validation or error recovery patterns.
Create and publish the post to Threads via API
Oauth login to Threads. User must complete authentication in browser before any other tools can be used.
LoginToThreads has no documented input schema (empty {}) and no output schema. LLM cannot know what this tool returns or how to use its output in downstream calls.
CreateAndPublishPost accepts only 'content' parameter with generic description ('The content of the social media post'). Missing: output schema, error conditions, character limits, format constraints, idempotency guarantees, return value documentation.
Authentication credentials (OAuth tokens) appear to be managed server-side via Redis, but code shows tokens are stored and retrieved without clear secret injection documentation. AuthService exchanges codes for tokens but tool definitions do not explain the OAuth flow or token lifecycle to the LLM.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 33 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 16 | - | v1 |
No error handling guidance in tool descriptions. LLM does not know: What happens if OAuth fails? What if token expires? What if Threads API rate-limits? What if post creation fails mid-transaction (text container created but publish fails)?
CreateAndPublishPost modifies state (publishes to Threads) but description lacks destructive operation warning. No confirmation step, dry-run mode, or undo capability documented. Agents cannot safely explore, every call is permanent.
LoginToThreads description mentions 'User must complete authentication in browser' but tool definition provides no mechanism to communicate the login URL back to the user or agent. The URL is generated in AuthService.BuildLoginUrl() but not surfaced through the tool interface.
Tool composition is poor. Two separate steps (CreateTextContainer then PublishContainer in ApiService) are hidden inside CreateAndPublishPost, but LLM cannot understand the multi-step nature or recover if the publish step fails after text container creation.