Loading ToolBench
A registry server for managing AI agents, skills, and MCP servers with artifact lifecycle management, evaluation tracking, and dependency resolution
This MCP server exposes 13 tools for artifact lifecycle management across agents, skills, and MCP servers. Tool definitions have names starting with action verbs (Search, List, Create, Delete, Promote, etc.) and descriptions present. However, the server is NOT an MCP server, it is a standalone HTTP REST API with no MCP protocol implementation. The tool definitions, parameter schemas, and descriptions are inferred from HTTP route handlers and are not formally registered via MCP's tool registry mechanism. Input schemas are visible in the code comments but lack formal JSON Schema structure for compound types (e.g., 'artifact' parameter in CreateArtifact is just 'object' with no field definitions). Most parameter descriptions are adequate but brief. Output schemas are not documented. Error handling in the source is minimal, no recovery guidance in responses.
Create a new artifact (agent, skill, or mcp-server) in draft status
Delete an artifact (only available for draft status)
Export artifact in standard document format (A2A AgentCard, MCP server.json, or SKILL.md)
Retrieve a specific artifact by kind, name, and version
Get the dependency graph for an artifact including all transitive dependencies and resolution status
Show comprehensive artifact details including evaluation summary and promotion history
List artifacts of a specific kind with optional filtering by status and category
List evaluation records for an artifact with optional category filter
NOT an MCP server, this is a standalone HTTP REST API with no MCP protocol implementation. Tools are HTTP endpoints, not MCP tools. No tool registry, no MCP schema format, no capabilities negotiation, no prompt/resource/tool handler structure.
CreateArtifact and SubmitEval accept 'object' type parameters (artifact, eval) with no field definitions. Schema constraint is effectively absent, leaving LLM guessing about required/optional fields, types, and structure.
No output schemas documented for any tool. LLMs cannot predict response structure, making chaining difficult and forcing exploratory calls to understand what fields are returned.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 40 | 2026-07-28+ | v2 |
List all versions of an artifact
Health check endpoint that returns server status
Promote an artifact to a new lifecycle status with optional promotion gates validation
Search for artifacts by query string with optional kind filter and pagination
Submit an evaluation record for an artifact
DeleteArtifact and PromoteArtifact are destructive/state-changing but descriptions do not explicitly state so. Descriptions lack guidance on idempotency, side effects, and recovery paths.
No error handling documentation. Handler code likely returns HTTP status codes and error messages, but descriptions do not guide LLM on retry logic, user-fixable errors, or recovery actions.
Pagination parameters (limit, offset) lack numeric constraints. No min/max bounds stated in descriptions. Search/ListArtifacts state default/max in description text, but no formal JSON Schema constraint.
Enum parameters (kind, status, category, targetStatus, format) are not declared as JSON Schema enums. Descriptions mention valid values in prose, but LLMs cannot parse constraints from text reliably.