The server defines 6 tools with basic naming and descriptions, but has significant gaps in schema completeness, parameter documentation, and error handling. Tool names follow verb conventions (list_, get_, create_), but descriptions lack specificity about prerequisites, return types, and when to use each tool. Parameter schemas are present but minimally described. No output schemas documented. Error messages lack recovery guidance. This is a typical community server with functional definitions but insufficient LLM-optimization.
list_agents and get_tasks lack pagination parameters (limit, offset/cursor). No documentation of how many results are returned or whether they can exceed context limits.
Tool descriptions are under 100 chars and lack critical metadata: prerequisites (e.g., must call server_status first?), return value summary, and when to use vs similar tools.
Document the output schema for each tool. For list_agents, specify: {agents: string[], total: number, filtered_by_tag?: string}. For create_automation_task, return: {task_id: string, status: 'queued'|'running', created_at: ISO8601, agents: string[]}. For get_tasks, return: {tasks: Task[], total: number, returned: number}.
Add pagination to list_agents and get_tasks: accept 'limit' (1-100, default 20) and 'cursor' or 'offset' parameters. Return 'next_cursor' or 'has_more' so the LLM knows when to fetch more.
Expand tool descriptions to 100-200 characters each. For create_automation_task: 'Create an automation task to process content through specified agents (e.g., post, generate-video). Returns task_id for polling. All agents in the array will run sequentially. Images optional; supported formats: jpg, png, webp.'
Add constraints to create_automation_task parameters: describe 'agents' as 'Array of agent names (e.g., ["post", "generate-video"]). Must be valid agent names from list_agents.' For images: 'Path to file (relative or absolute). File must exist before calling this tool. Supported: jpg, png, webp. Max 10MB.'
For create_automation_task, document the side effect clearly: 'WARNING: This creates and immediately queues the task for execution. To preview before execution, use a dry_run parameter (not yet implemented) or call get_agent_config on each agent first.'
Update error handling in runAutomationTask, getTask, etc. to include recovery hints. Example: 'Failed to create task: Docker container for image aideas-mcp is not running. Ensure Docker daemon is running and retry.' Return error as {error: string, recoverable: boolean, suggestion: string}.
Score history
Overall score trend
↑ 24 points across a rubric change (v1 → v2)
46/100
Scored
Grade
Overall
Spec posture
Rubric
2026-09-21
F
46
2026-07-28+
v2
2026-03-09
F
22
-
v1
create_automation_task parameter descriptions do not document mutual exclusivity (can both image_file_landscape and image_file_square be omitted? required?), format constraints (what formats for image paths?), or side effects (what exactly is created? immediate execution or queued?).
Error handling throughout the codebase returns generic errors ('Server is not available', 'Failed to run container') without recovery guidance. LLM receives no hint of whether to retry, ask user, or abandon the task.
get_tasks accepts no parameters for filtering, sorting, or pagination. Returning all tasks unbounded can exhaust context window and violates the enforce-result-limits pattern.
create_automation_task is a WRITE operation but lacks confirmation/dry-run capability or idempotency documentation. Agents making mistakes will create duplicate tasks with no way to preview or cancel.
Parameter 'agents' in create_automation_task is an array of strings but has no validation: are agent names case-sensitive? Must they exist (validated before execution)? Should the tool call list_agents first?
image_file_landscape and image_file_square expect file paths but have no validation rules: relative vs absolute? Must file exist before calling create_automation_task? What formats accepted (jpg, png, webp)?
create_automation_task
Add a 'dry_run' boolean parameter to create_automation_task (default false). When true, return what would execute without actually running it. This prevents accidental duplicate executions and lets agents preview impact.
Add a get_task_result or poll_task tool to retrieve task output (not just status). Currently get_task returns TaskStatus but not the actual generated content (posts, videos, etc.). Agents need this to provide results to users.
Validate image paths and agent names before executing. For image_file_landscape/square, check file existence and format. For agents array, validate against list from list_agents(). Return clear errors: 'Agent "invalid-agent" not found. Valid agents: post, generate-video, test.'
Document the relationship between agents in create_automation_task: run sequentially or parallel? Can one agent fail without stopping others? Does output of agent N feed into agent N+1? This is critical for LLM planning.