Loading ToolBench
MCP server for the MOSA asset management system, providing tools to create, list, retrieve, update, and manage generated images and their metadata in a library with version history and generation lineage tracking.
MOSA provides 14 tools with complete JSON Schema definitions and descriptions. Naming follows verb_noun patterns (asset_create, asset_list, generation_record). Descriptions are substantive (100-300 chars), explaining WHAT and WHEN. However, many parameter descriptions are missing or minimal. Complex nested schemas (references array with conditional object properties) lack clarity on when to use string vs object forms. Output schemas are not documented, LLMs cannot predict response structure. Error handling is absent from tool definitions. No tool annotations (readOnlyHint, destructiveHint, idempotentHint) despite clear risk levels (WRITE, READ_ONLY, REVERSIBLE). Parameter relationships (e.g., allowed_uses vs forbidden_uses) are documented inline but could be clearer.
Soft-delete an asset from active MOSA results while preserving its provenance and original file.
Attach a generation record to an existing asset, linking them together.
Copy a generated image into the MOSA library and save prompt recipe metadata. Codex's <CODEX_HOME>/generated_images task folders are supported and recorded as the source; CODEX_HOME defaults to the user's .codex directory.
Create an independent editable copy that starts a new version root while retaining duplicate provenance.
Get one saved asset and its full prompt recipe.
List saved MOSA assets for a project, optionally filtered by search text.
Output schemas not documented. LLMs cannot predict response structure (fields, types, pagination). Tools like asset_list and generation_list accept limit/cursor but response format is invisible.
No tool annotations (readOnlyHint, destructiveHint, idempotentHint). Risk levels are declared (READ_ONLY, WRITE, REVERSIBLE) but not exposed in schema. LLMs cannot distinguish safe from destructive operations.
Complex nested schema (references array with conditional string|object items) lacks clarity. When should LLM pass string vs object? No guidance on when to use allowed_uses vs forbidden_uses.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | C | 63 | 2026-07-28+ | v2 |
Read immutable generation recipe snapshots for one asset and identify the currently active snapshot.
Update metadata fields for an existing asset without changing its recipe or image.
Save a new recipe version as a child of an existing asset without overwriting the parent.
Read the complete root-to-descendant recipe version tree for an asset, including archived versions.
Read the complete lineage tree for a generation record, showing all ancestors and descendants.
List generation records for a project, optionally filtered by search text.
Record a generation event with its prompt recipe and optional external verification level.
Record a relationship between two generation records, such as a refinement or variation.
Parameter descriptions missing or minimal for several fields. E.g., 'sourceType' has no description; 'source' object is described generically. LLMs cannot infer valid values or when to use them.
No error handling guidance in tool definitions. What happens if imagePath does not exist? If assetId is not found? LLMs have no recovery path.