Loading ToolBench
Skills-based LangGraph agent with ReAct tool loop for n8n workflow automation and skill-based reasoning
Aria provides two well-implemented tools with clear purposes and reasonable descriptions. Both tools have explicit input schemas with typed parameters and descriptions. The tools follow a sensible read-only pattern for skill discovery and file access. However, there are gaps in error handling guidance, output schema documentation, and parameter constraint clarity. Descriptions are adequate but could be more detailed about when to use each tool vs. alternatives and what the response structure contains.
Load expert knowledge for a skill. Returns JSON with the skill's instructions and a list of available supporting files. Currently available skills: (dynamic list at runtime) Note: If this list seems outdated, the load_skill tool will return the current list of available skills in its error response if an invalid skill name is provided. Args: skill_name: Exact name of the skill to load.
Read a supporting file from a skill folder. Returns JSON with the file content. Use this to access reference documents listed in the 'available_files' field of a loaded skill. Available skills: (dynamic list at runtime) Args: skill_name: Name of the skill that owns the file. filename: Name of the file to read (from the skill's available_files).
Output schemas are not formally documented. While code comments describe what load_skill returns (skill_name, description, instructions, available_files), this structure is not exposed to the MCP client or LLM in a machine-readable schema. LLMs cannot reason about what fields to expect without documented return types.
Error handling is JSON-structured but lacks recovery guidance. When load_skill returns {"error": "Skill 'xyz' not found", "available_skills": "..."}, it tells the LLM the skill doesn't exist, but doesn't explicitly say 'retry with one of these valid names' or 'call load_skill with a different name'. Error messages should guide the LLM's next action.
Parameter 'filename' in read_skill_file lacks format constraints. The description says 'Name of the file to read (from the skill's available_files)', but doesn't specify whether it should include extensions, whether it's case-sensitive, or what happens if a user requests a file outside the skill folder (path traversal concern).
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 0 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 47 | - | v1 |
Skill name parameter in both tools lacks bounds or validation hints. Description says 'Exact name of the skill', but doesn't specify case sensitivity, allowed characters, or max length. This invites LLM guessing on trivial details like whether to capitalize or strip whitespace.
Tool descriptions are brief (60-90 chars) and lack discovery context. They don't explain WHEN an LLM should call load_skill vs read_skill_file, or what the typical workflow is. E.g. 'First load a skill to see available supporting files, then use read_skill_file to access specific documents.' This forces the LLM to infer the multi-step pattern.