A modern framework for orchestrating AI agents with MCP integration, REST API, and team management capabilities
MAO presents 27 tools with basic structure but significant quality gaps. Tool naming is action-verb-based and generally clear (create_, list_, get_, update_, delete_, assign_, remove_), which is a strength. However, descriptions are perfunctory (averaging ~40-60 chars, well below the 194-char baseline for A+ tools), parameter annotations lack depth, and output schemas are entirely undocumented. Most parameters have types but minimal guidance on constraints, ranges, or interdependencies. Error handling is absent from all tool definitions, no recovery guidance, no categorization of retryable vs. fatal errors, no actionable error messages. The tool set exhibits poor composition: many tools operate on the same resource types (agents, servers, tools) with overlapping semantics, and critical chaining fields (e.g., agent_id needed by downstream calls) are assumed but not explicitly documented in outputs. Security and audit concerns are present but not surface-level (no visible permission gates, secret injection, or audit trail annotations). The server is an HTTP orchestration platform that exposes agent/server/tool configuration and execution operations, but the MCP interface lacks the semantic richness and error recovery patterns seen in production-grade tools.
Assigns a tool to an agent
Sends a message to a running agent
Creates a new agent
Creates a new MCP server
Creates a new tool
Deletes an agent
Deletes a server
Deletes a tool
Output schemas completely undocumented. No tool definition includes return type documentation. LLMs cannot predict what fields downstream tools will receive, forcing guesswork or failed chaining.
Descriptions are generic and undescriptive (averaging 30-40 chars, well below the 194-char baseline). E.g. 'Lists all configured agents' lacks context on when to call it, what structure it returns, or how to use results. Descriptions should answer: What does it do? When to use it instead of similar tools? What does it return?
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 54 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Exports all server configurations to a .mcp.json-compatible file
Gets an agent by its ID
Returns basic API information and available endpoints
Returns the MCP configuration as JSON directly for use with MCPClient
Exports MCP configuration as a downloadable file
Gets a server by its ID
Gets a tool by its ID
Simple health check endpoint
Lists all tools assigned to an agent
Lists all configured agents
Lists all configured servers
Lists all configured tools, optionally filtered by server
Lists all running agents
Removes a tool assignment from an agent
Starts an agent
Stops a running agent
Updates an agent
Updates a server
Updates a tool
Parameter descriptions are minimal or missing semantic guidance. E.g., 'limit' lacks min/max bounds (should be 1-1000); 'enabled_only' is boolean but doesn't explain the difference in returned data; 'response_schema' in chat_with_agent lacks format/constraint examples. LLMs cannot infer valid ranges or formats.
No error handling or recovery guidance in any tool definition. Tools that delete resources (delete_agent_by_id, delete_server_by_id, delete_tool_by_id) provide no confirmation step, dry-run option, or actionable error messages. Agents cannot know whether to retry, fix input, or escalate.
Tool composition issues: overlapping semantics across agent/server/tool CRUD operations invite duplicate tool selection. list_agents vs list_running_agents, get_agent_by_id vs list_agents with filter would benefit from clearer semantic boundaries and consolidated discovery patterns.
Pagination parameters (limit, offset) appear on some tools but not all. No documentation of default page size, max results cap, or next_cursor/total_count field naming. LLMs may assume missing pagination hints mean unbounded results, risking context window exhaustion.
Missing natural-language identifier fallbacks. Tools like get_agent_by_id accept only agent_id, but users say 'Check my agent Supervisor'. No agent_name parameter forces an extra lookup call. Same issue affects get_server_by_id, get_tool_by_id.
No visible security controls, permission gates, or audit trail annotations. Tools that create/delete agents and servers lack scope declarations (e.g. 'admin:agents:write'). No visible secret injection for LLM provider credentials. No audit logging hints in descriptions.