Loading ToolBench
Collection of MCP servers for agentic pipeline platform providing blackboard operations, knowledge management, git integration, and Telegram notifications
Trellis defines 16 tools with explicit schemas and descriptions. Most tools have clear verb-noun naming (read_blackboard, write_blackboard, get_idea_status) and non-empty descriptions. However, several critical gaps reduce quality: (1) Many parameter descriptions are minimal or missing type constraints (e.g., 'filename' in read_blackboard lacks format/length guidance). (2) Output schemas are not documented, callers don't know what fields to expect from read_blackboard or list_blackboard_files. (3) Error handling is absent, no guidance on what happens if a file doesn't exist or write fails. (4) Some tools conflate concerns (declare_artifacts combines registration + metadata, register_feedback mixes review + notification). (5) Tool descriptions lack WHEN/WHY context, agents don't know when to call write_knowledge vs declare_artifacts. Baseline: 549 production tools average 194 chars in description; Trellis tools range 50 - 300 chars, with several under 100 chars lacking actionable detail.
Append content to a file on the idea's blackboard
Ask the human a question via Telegram and wait for their response. Use this for critical decisions that require human input.
Commit current blackboard changes to git with a descriptive message
Register the artifacts you created and why. Call this BEFORE set_phase_recommendation. This creates a structured manifest that helps downstream agents understand your outputs.
Remove a knowledge entry that is stale, wrong, or superseded. Provide the entry id (shown in [brackets] by read_knowledge).
Get the current status of this idea including phase and metadata
Output schemas undocumented for 8 tools (get_idea_status, list_blackboard_files, read_blackboard, read_knowledge, commit_blackboard, send_telegram, notify_phase_complete, append_blackboard). LLMs cannot plan downstream calls or extract required fields without knowing return structure.
Parameter descriptions lack format/constraint guidance. 'filename' in read_blackboard, write_blackboard, append_blackboard does not specify: must be .html? max length? allowed characters? LLMs will guess and pass invalid values.
No error handling guidance. Tools do not document what happens on failure (file not found, write permission denied, git commit fails). Agents have no recovery path, they cannot distinguish retryable from fatal errors.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 50 | 2026-07-28+ | v2 |
List all files in this idea's blackboard directory
Notify the human that an agent phase has completed
Read a file from the idea's blackboard directory
Read all accumulated knowledge entries with their [id] prefixes. Call this BEFORE write_knowledge to check for duplicates or entries to merge.
Register feedback on an artifact. Use this to report issues found during review. Do NOT use write_blackboard for feedback.
Search for knowledge entries with overlapping predicates. Use this to find related knowledge before writing a new entry.
Send a notification message to the human via Telegram
Set a recommendation for the next phase transition
Write content to a file on the idea's blackboard. All artifacts MUST be .html files — gorgeous, self-contained HTML with inline CSS/JS and SVG visualizations. You choose which artifacts to create based on what's most valuable for this specific idea.
Record a reusable insight for future runs. ONLY record knowledge that: - Prevents repeating a mistake that cost significant time - Reveals a non-obvious pattern applicable across ideas - Corrects a common assumption agents make Do NOT record: per-run reports, status summaries, idea-specific findings (those belong on the blackboard), or observations unlikely to change behavior. You MUST provide predicates (subject-relation-object triples) that capture the core claim. You MUST provide a justification explaining what time this saves or what mistake it prevents. Call read_knowledge first to check for duplicates.
Tool descriptions lack WHEN/WHY context. 'Write content to a file' does not explain when to call write_blackboard vs append_blackboard vs declare_artifacts. Agents cannot distinguish overlapping tools without trial-and-error.
Destructive operations (delete_knowledge, commit_blackboard) lack confirmation/dry-run support. Agents can permanently delete knowledge or commit unreviewed changes without safeguards. No idempotency guarantees documented.