Loading ToolBench
MCP Server for creating, listing, inspecting, editing, deleting, and triggering macOS Alfred 5 Workflows.
The server defines 3 tools with visible schemas and descriptions in server.py. However, multiple critical gaps significantly limit quality: (1) parameter descriptions are present but often lack constraint details (format, ranges, enum values); (2) output schemas are implicit (JSON dumps) rather than formally documented in function signatures; (3) error handling is minimal, many operations return generic JSON error objects without recovery guidance; (4) no tool annotations (readOnlyHint, destructiveHint) despite clear risk differentiation; (5) the alfred_create_workflow tool has 8 required parameters with minimal constraint documentation, inviting invalid input from LLMs. Naming follows verb_noun convention (good), but descriptions lack depth on when/why to call each tool and what downstream tools expect. Overall competent but below production baseline for agent tooling.
Create a new Alfred 5 workflow with proper info.plist formatting, objects, and connections.
Get comprehensive details of an Alfred workflow including metadata, object nodes, script code, connections, and files.
List all installed Alfred workflows with options to search by name, bundle ID, or keyword.
Output schemas are implicit (JSON string returns) rather than formally documented. LLMs cannot infer the structure of returned objects, breaking downstream tool composition and forcing parsing errors.
alfred_create_workflow has 8 required parameters with insufficient constraint documentation. 'template' should be an enum; 'bundleid' should document reverse-domain format; 'script_type' should enumerate valid interpreters (/bin/zsh, /bin/bash, python3, applescript). LLMs will hallucinate invalid values.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint) provided. alfred_list_workflows and alfred_get_workflow are read-only; alfred_create_workflow is destructive (modifies filesystem). Agents need this metadata to reason about safety and retry logic.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 53 | 2026-07-28+ | v2 |
Error handling is minimal. alfred_get_workflow returns {'error': '...'} on not found, but does not suggest alternatives ('Available workflows: ...') or guide recovery (e.g., 'Call alfred_list_workflows to discover valid identifiers'). alfred_create_workflow will fail silently or with generic OS exceptions if bundle ID conflicts or script_type is invalid.
alfred_list_workflows returns unbounded results. Code extracts all workflows from glob and filters in memory. If a user has 100+ workflows, the JSON response balloons, wasting tokens. No pagination (limit/offset) or cursor support documented.
alfred_get_workflow parameter 'identifier' accepts three types (folder name, bundle ID, workflow name) with no documented precedence. Matching logic is implicit in resolve_workflow_path(): exact folder match, then bundle ID, then name, then partial name. This ambiguity will confuse LLMs and cause incorrect tool selection on partial matches.
alfred_create_workflow does not document idempotency. Creating a workflow with the same bundle ID twice will likely fail or create duplicates. No guidance on how to handle conflicts or verify successful creation.