API for executing AI agents with support for MCP servers, custom tools, and multiple AI model integrations
Evo AI's tool definitions have moderate structural quality but significant descriptive and validation gaps. All 5 tools are present with basic schemas and descriptions, but descriptions are generic and lack LLM-optimized clarity. Parameter descriptions are minimal. No input validation rules, enums, or constraints are visible. Error handling is absent from the source. The tools follow a CRUD pattern but lack composition guidance and fail to address cross-tool chaining. This is a typical C-tier community server with foundational structure but insufficient detail for robust agent reasoning.
Create a new tool
Delete a tool
Get details for a specific tool
List all tools with pagination
Update an existing tool
Generic parameter descriptions lack constraints and validation rules. 'Tool configuration including name, description, config_json, and environments' does not specify format, length, enum values, required fields, or data types. LLMs cannot validate input without explicit constraints.
Tool descriptions are too brief and lack WHEN/WHY guidance. 'Create a new tool' (19 chars) does not explain what constitutes a valid tool, what happens on success/failure, or how this tool chains with others. LLMs struggle with tool selection when descriptions are this terse.
No error handling or recovery guidance visible. Tools declare no error responses, status codes, or what an LLM should do if a tool_id doesn't exist or creation fails. Agents cannot distinguish retryable vs. fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 49 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 30 | - | v1 |
Destructive operations (delete_tool) lack confirmation or dry-run patterns. Agents cannot preview the consequence before executing an irreversible delete. This violates confirmation-request pattern.
Parameter 'tool' in create_tool and update_tool is overloaded. It accepts an object but has no nested schema visible, no required-fields list, no field descriptions. LLMs cannot reason about what fields are mandatory (name? description? config_json?).
Output schemas are not documented. read_tools and read_tool do not describe their return structure (fields, types, nesting). LLMs cannot plan downstream operations (e.g., which field contains the tool_id to pass to update_tool?).
Pagination in read_tools lacks essential fields. 'skip' and 'limit' are present, but no 'total', 'next_cursor', or return count visible. Large result sets could exceed context windows without clear pagination boundaries.
Tool chaining is not designed. create_tool doesn't document what ID field to use in subsequent read_tool calls. Are tool_ids globally unique? Can they be human-readable names or only UUIDs? Missing chaining guidance.