Loading ToolBench
Backstage backend plugin providing MCP server for managing AI assets (instructions, agents, skills, workflows) with asset discovery, installation, and proactive suggestions
This MCP server provides 8 tools with reasonable descriptions and clear semantic intent, but has significant gaps in schema completeness, parameter documentation, and error handling guidance. The tools cover a coherent domain (asset search, installation, and management), but the input schemas lack proper type definitions for all parameters, and many parameters are missing detailed constraints. The risk classification (READ_ONLY vs WRITE) is present and helpful, but the server lacks pagination metadata, error recovery guidance, and confirmation patterns for destructive operations. Tool naming is generally clear (verb_noun convention followed), but parameter constraints are under-specified.
Retrieve full details for a specific asset including description, content, tags, installation count, and related assets.
Install a single asset (instruction, agent, skill, or workflow) to the specified path. Returns the asset content and installation command.
Install multiple assets at once. Each asset is installed to its recommended path relative to a base directory.
Install all assets in a bundle (a curated collection) to the specified base directory.
List all configured asset providers and their current status (idle, syncing, error).
Scan the local filesystem for already-installed assets matching a specific AI tool's conventions. Returns discovered asset names and paths.
Input schemas lack proper JSON Schema type definitions. Parameters show 'type' fields inline (e.g., {"context":{"type":"string"}}) but are missing critical constraints: enum values for 'type' parameter in search_assets (instruction|agent|skill|workflow|prompt|bundle not enumerated), no minLength/maxLength for string parameters, no minimum/maximum for numeric parameters (limit, page), no pattern validation. This allows LLMs to pass invalid values like type='invalid' or limit=-5.
install_asset and install_assets tools perform destructive/irreversible operations (WRITE risk) but lack error handling guidance for failure scenarios. No documentation of what happens on partial failure (e.g., if one of multiple assets fails to install). No confirmation/dry-run pattern. No guidance on rollback or cleanup if installation fails mid-operation.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | D | 51 | 2026-07-28+ | v2 |
| 2026-03-09 | D | 54 | - | v1 |
Search for assets by name, description, or tags. Returns paginated results in markdown table format.
Proactively suggests relevant assets based on project context (language, framework, task). Use this at the start of a session or when the user describes what they are building. Always present the results to the user as a markdown table — never as a bullet list. Prefer this over search_assets for proactive recommendations.
Search and list tools (search_assets, list_providers, get_asset_details) provide no pagination metadata in documented output schema. No 'total_count' or 'next_cursor' returned; no guidance on what happens if results exceed the limit. search_assets accepts 'page' parameter but output structure is undocumented, does it return offset metadata? Current approach risks context window exhaustion with large result sets.
Parameter 'path' in install_asset accepts filesystem paths and environment variable references (e.g., $SKILLS_DIR) but constraint is underdocumented. No guidance on path validation, symlink handling, or permission errors. No description of what constitutes a valid 'path'. LLM may pass invalid paths like '../../../etc/passwd' without clear rejection path.
scan_installed_assets tool accepts 'tool' parameter (claude-code, github-copilot, google-gemini, cursor) but does not enumerate these as an enum constraint. Description lists examples but does not formally restrict valid values. LLM may pass 'chatgpt' or 'claude' without clear error.
Output schemas are not documented in visible source. Tool descriptions mention 'returns X' (e.g., suggest_assets 'Always present the results to the user as a markdown table') but formal output schema with field types is absent from inline code. LLM cannot reliably extract structured data from returned markdown tables without explicit schema definition.
Error handling strategy is not documented. No guidance provided on retryable vs non-retryable errors, recovery paths for common failures (e.g., 'Asset not found, try search_assets to discover available assets'), or actionable error messages. Tools provide no indication of when to ask user for input vs. fail silently.
list_providers tool returns 'current status (idle, syncing, error)' but enum constraint is not formalized in schema. No description of what to do if provider status is 'error', should LLM retry? Ask user? This is critical for understanding system health.