Loading ToolBench
MCP server for OpenQuok scheduling API — designed for automation and AI agents to automate social media posting, manage scheduled content, and upload media via the OpenQuok API across connected social platforms
OpenQuok MCP server exposes 2 tools with complex, domain-specific functionality for social media scheduling. Both tools have descriptions and structured schemas, but suffer from critical gaps in schema completeness, parameter documentation, and error handling guidance. Tool names follow verb-first convention (schedulePostTool, triggerTool), but are not idiomatic MCP naming (prefer snake_case: schedule_post, trigger_integration). Schemas use object properties but lack critical type information for nested fields and lack explicit parameter type declarations in several cases. Descriptions are verbose (500+ chars for schedulePostTool) and bury actionable constraints under implementation details. Neither tool documents error cases, recovery paths, or validation rules. Output schemas are entirely undocumented, LLMs cannot predict what these tools return, making downstream composition impossible.
Create or schedule social posts across connected channels (draft, schedule, publish-now). Per socialPost entry: publishing channel UUID, postsAndComments (first string is the main body; additional strings are same-account reply chains only), optional settings (REST providerSettingsByIntegrationId), optional attachments (public HTTPS URLs). Put cross-account comments/reposts in settings on the publisher — threads.crossAccountPlugs, threads.internalEngagementPlug, x.crossAccountPlugs, linkedin.crossAccountPlugs — with acting channel UUIDs from integrationList, not extra postsAndComments strings.
Invoke an allow-listed provider method on a connected channel (same as POST /public/integration-trigger/:id).
Tool names use camelCase (schedulePostTool, triggerTool) instead of MCP convention (snake_case: schedule_post, trigger). LLMs parse verb-first names more reliably; camelCase is unpredictable across implementations.
Output schemas completely undocumented. LLMs cannot predict what schedulePostTool or triggerTool return. No fields, no types, no success/error structure. This breaks downstream tool composition and forces the LLM to guess at return formats.
Parameter type definitions incomplete or missing. schedulePostTool.socialPost is typed as 'array' but items have 'type: object' with properties that lack explicit 'type' fields (integration should be 'type: string'). triggerTool.data is 'type: object' with no property schema at all, completely opaque to LLMs.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 46 | 2025-06-18+ | v2 |
schedulePostTool description (500+ chars) buries the main action under implementation minutiae about channels, settings, and provider-specific plugs. Should lead with 'Create or schedule social media posts' in 1 - 2 sentences, then detail settings. Current description conflates what the tool does with how integrations work internally.
No error handling or recovery guidance. What does schedulePostTool return on network failure, invalid integration, or too-long post body? How should the LLM retry? What are the HTTP codes? This forces agents to guess and retry blindly.
No idempotency or confirmation for destructive operations. schedulePostTool with type='now' immediately publishes to social media, irreversible. No dry-run, no confirmation step, no warning. An LLM error publishes spam to real accounts.
triggerTool allows arbitrary provider methods via methodName parameter with NO validation examples. What methods are allowed? Are some dangerous (e.g. delete_account)? No enum, no allowlist documentation, no permission gates. An LLM could call any provider method.
schedulePostTool parameter 'date' is optional but only used when type='schedule'. Mutual dependency not documented. If type='now' and date is provided, what happens? LLM must guess.
Parameter 'integration' in schedulePostTool (and 'integrationId' in triggerTool with alias 'integration'), inconsistent naming and dual naming without clear guidance on which to use. Both are optional in triggerTool; unclear what happens if neither is provided.
No input validation rules documented. schedulePostTool.postsAndComments is an array with no minItems (could be empty). attachments are 'public HTTPS URLs', should validate format, but no pattern or constraint stated. LLMs pass invalid URLs without guidance.