Loading ToolBench
MCP server for validating and working with automotive image builder manifests
AIB server has 5 tools, all read-only with basic descriptions and schemas. Tool names follow verb_noun convention (validate_, get_, read_). Descriptions exist but are verbose (200-400 chars) and contain embedded instructions/examples in docstrings rather than clean descriptions. Schemas are present for most tools but lack granularity in some cases. Error handling in validate_yaml is detailed but inconsistently applied. No tool annotations (readOnlyHint, etc.). The server embeds complex instructions in tool descriptions (e.g., get_schema includes <IMPORTANT> tags with directives to the LLM) which should be separated from the core description. No support for pagination despite read-heavy workload.
Returns a list of available targets that can be used in AIB manifests. Returns: A dictionary containing: - targets: list of available target names - details: dictionary with target descriptions and metadata
Returns a tree representation of the automotive-image-builder directory. Returns: A string containing the directory tree structure.
Returns the AIB manifest schema as a string. <IMPORTANT> Unless the user explicitly asks for it, make you example simple and succinct. Do not include default empty sections. For instance: ``` name: simple content: rpms: - vim auth: # "password" root_password: $6$xoLqEUz0cGGJRx01$H3H/bFm0myJPULNMtbSsOFd/2BnHqHkMD92Sfxd.EKM9hXTWSmELG8cf205l6dktomuTcgKGGtGDgtvHVXSWU. ``` Under no circumstance should you make things up. You MUST always consult with all available examples and the source code using the get_directory_tree and read_file tools. Look for important condition in simple.py to improve your output. </IMPORTANT> Returns: The schema YAML content as a string
Reads a file from the automotive-image-builder directory. <IMPORTANT> Be sure to read these files. ["examples/", "targets/", "aib/simple.py", "README.md", "aib/main.py"] When suggesting CLI command to use, you MUST verify what you read in the README.md against automotive-image-builder/aib/main.py in case README is outdated. </IMPORTANT> Args: file_path: The path to the file, relative to the automotive-image-builder directory. Example: "aib/simple.py" or "files/manifest_schema.yml" Returns: The content of the file as a string, or an error message if the file cannot be read.
Tool descriptions contain embedded prompt instructions and directives (get_schema, read_file include <IMPORTANT> XML tags). These should be removed from descriptions; LLM-facing guidance belongs in agent config, not tool docstrings.
read_file description is verbose (300+ chars) and mixes multiple concerns: path format examples, file discovery hints, and validation instructions. Should be split into a concise description + parameter docs.
get_schema and read_file lack error guidance. When schema_path or file_path fails, they return plain error strings instead of actionable recovery hints (e.g., 'Schema not found. Try get_directory_tree() to explore available files.').
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). All 5 tools are read-only and safe to retry, but this is not formally declared in the schema.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | C | 65 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 0 | - | v1 |
Validates a YAML manifest against the AIB schema. Args: yml: The YAML content to validate as a string Returns: A dictionary containing validation results including: - valid: boolean indicating if the YAML is valid - message: a summary message - errors: detailed error information if invalid
validate_yaml and get_available_targets lack output schema documentation. The description states what the output contains ('valid, message, errors' for validate_yaml; 'targets, details' for get_available_targets) but not in a formal schema structure.
read_file accepts 'file_path' as a free-form string. No validation against path traversal (../../ escape sequences). Input should be sanitized or constrained to a whitelist of allowed paths.
get_directory_tree and read_file return verbose, unstructured text responses. For a discovery/navigation use case, structured JSON (flat list of paths + metadata) would be cheaper and more machine-parseable.