Loading ToolBench
The server defines 3 tools with explicit schemas and descriptions. Tool names follow verb_noun convention (create_draft, get_scheduled_drafts, get_published_drafts), which is correct. Schemas are present and properly typed for all tools. However, there are significant gaps: (1) output schemas are completely undocumented, the call_tool handler returns TextContent with formatted strings, but no schema tells the LLM what structure to expect; (2) parameter descriptions lack actionable constraints, 'schedule_date' accepts ISO datetime or 'next-free-slot' but doesn't explain the behavior difference; (3) error handling is absent, the try/except block catches all exceptions and presumably returns a generic error without guiding the LLM on recovery; (4) no parameter validation constraints (min/max for numeric, regex patterns, length limits); (5) response formatting embeds markdown and emoji rather than returning structured objects, making downstream chaining difficult. The tool definitions are visible and explicit (not inferred), and schemas use proper JSON Schema syntax with types, so they clear the floor. But execution quality is mediocre, descriptions average ~80 chars (below the 194-char baseline for A tools), and the gap between schema definition and actual error/output documentation is wide.
Create a new draft in Typefully with optional scheduling
Get recently published drafts from Typefully
Get recently scheduled drafts from Typefully with full thread viewing links
Output schemas completely undocumented. All three tools return TextContent with formatted markdown strings, but the LLM has no schema defining what fields/structure to expect. This breaks tool chaining, agents cannot reliably extract draft_id, scheduled_date, or other fields from the formatted text. Downstream tools that consume these outputs (e.g., a hypothetical update_draft or delete_draft) would require the agent to parse unstructured text.
No error handling guidance. The try/except block catches all exceptions but provides no recovery hints. If the API returns 401 (auth failed), 429 (rate limited), or 404 (resource not found), the LLM receives no structured error with actionable next steps. Agents will likely retry the same call without understanding what to fix.
Inferred effective spec: <=2025-11-25.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-21 | D | 57 | <=2025-11-25 | v2 |
| 2026-03-09 | D | 55 | - | v1 |
Parameter descriptions lack actionable constraints. 'schedule_date' accepts 'ISO formatted date' OR 'next-free-slot', but the description doesn't explain: (1) the behavioral difference (when to use each?), (2) whether both can be passed simultaneously, (3) what happens if the scheduled time is in the past. Similarly, 'threadify' doesn't explain its relationship to the 4-newline splitting mentioned in 'content', are they mutually exclusive? Does threadify override the newline splitting?
No pagination support. get_scheduled_drafts and get_published_drafts offer no limit, offset, page_size, or cursor parameters. If a user has 200 scheduled drafts, the server will attempt to return all 200 in one response, bloating the context window and degrading LLM reasoning. The descriptions don't state the limit or offer pagination.
Descriptions are too short and lack context. 'Get recently published drafts from Typefully' (58 chars) doesn't explain what 'recently' means, whether the tool is the canonical way to fetch published content, or how it differs from get_scheduled_drafts. Average description length across the three tools is ~68 chars, well below the 194-char baseline for A tools. Short descriptions leave the LLM without critical context for selection.
No input validation or range constraints. Parameters like 'content' have no max length, 'share' and 'threadify' have no explanation of default behavior, and 'auto_retweet_enabled' and 'auto_plug_enabled' lack documentation of what happens if the account doesn't support these features. Unbounded text fields invite the LLM to pass excessively long content that the API might reject.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). create_draft is destructive (modifies state) but carries no destructiveHint annotation. get_scheduled_drafts and get_published_drafts are read-only but carry no readOnlyHint. Tool annotations help the LLM reason about retry safety and side effects.