Loading ToolBench
MCP server for Buildd platform providing task management, artifact handling, knowledge/memory operations, PR management, scheduling, and workspace coordination tools
Critical failures across all dimensions. Tool 1 (buildd) is a mega-tool with 70+ actions crammed into one interface, violating single-responsibility principle. Input schema shows empty enum for 'action' parameter, the core dispatch mechanism is broken. Tools 2 - 3 (check_path_claim, send_worker_message) have detailed schemas but lack descriptions entirely (0 chars). Tools 4 - 6 (buildd_memory, recall, learn) have minimal or missing descriptions. No output schemas documented anywhere. Error handling is absent, no recovery guidance, no categorization. The server conflates multiple concerns (task management, PR operations, artifact handling, scheduling, missions, skills, secrets) into a single tool, making it impossible for LLMs to reason about which action to invoke.
Primary action dispatcher for Buildd platform. Supports actions: list_tasks, get_task, create_task, claim_task, update_progress, complete_task, create_pr, close_pr, merge_pr, get_pr, request_pr_review, get_pr_review, record_pr_supersession, update_task, create_artifact, upload_artifact, list_artifacts, get_artifact, update_artifact, emit_event, query_events, get_error_traces, explain, list_artifact_templates, suggest_schedule_update, post_note, list_schedules, trace_schedule, get_task_messages, get_budget_forecast, get_usage_stats, list_connectors, list_releases, get_release, get_failure_analytics, manage_experiments, spec_compare, list_discrepancies, get_discrepancy, create_schedule, update_schedule, delete_schedule, pause_schedules, register_skill, list_skills, get_skill, update_skill, delete_skill, manage_secrets, approve_plan, reject_plan, adjudicate_discrepancy, promote_discrepancy, list_missions, get_mission, create_mission, update_mission, cancel_mission, get_mission_run, list_mission_runs, get_mission_run_events, get_mission_run_summary, get_mission_run_timeline, get_mission_run_artifacts, get_mission_run_notes, get_mission_run_errors, get_mission_run_gates, get_mission_run_workers, get_mission_run_worker_messages, get_mission_run_worker_events, get_mission_run_worker_artifacts, get_mission_run_worker_notes, get_mission_run_worker_errors, get_mission_run_worker_gates, get_mission_run_worker_timeline, get_mission_run_worker_summary, get_mission_run_worker_messages_summary, get_mission_run_worker_events_summary, get_mission_run_worker_artifacts_summary, get_mission_run_worker_notes_summary, get_mission_run_worker_errors_summary, get_mission_run_worker_gates_summary, get_mission_run_worker_timeline_summary
Legacy knowledge tool; recall (query) and learn (write) are the current interface — use those in new sessions. Kept callable for compatibility. Actions: recall, learn, list_memories, delete_memory, update_memory
Tool 'buildd' is a mega-tool with 70+ actions (list_tasks, create_task, create_pr, manage_experiments, manage_secrets, etc.) crammed into one interface. Violates single-responsibility principle. LLMs cannot reason about which action to invoke when the tool does everything.
Input schema for 'buildd' shows 'enum: []' for the 'action' parameter, the enum is empty. This is a broken dispatch mechanism. LLMs have no valid actions to choose from.
Tools 'check_path_claim' and 'send_worker_message' have detailed input schemas but NO descriptions (0 characters). LLMs cannot determine when or why to select these tools.
No output schemas documented for any tool. LLMs cannot plan downstream calls or extract required fields. Responses are unstructured.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | F | 41 | 2026-07-28+ | v2 |
Mid-task path-claim check. Call this when you discover you need to touch a file outside your declared pathManifest. If the path is unclaimed by any active sibling task, your task's pathManifest is atomically extended and you can proceed. If the path is already claimed by a sibling task, you receive blockingTaskId and must report blocked so a dependsOn edge can be added. If a deadlock cycle is detected (the blocking task is transitively waiting on you), deadlock=true is returned with a cycle array and actionable guidance on how to break it: cancel and retry, escalate to the blocking task's owner, or use mission-level maxConcurrentTasks=1. Requires a worker context (?worker=<workerId> in the MCP URL).
Write and store knowledge/memories to the knowledge store
Query and retrieve knowledge/memories from the knowledge store
Send a structured message to another active task worker in the same workspace. Use when you discover a path conflict (path_blocked_on_you), need to ask a clarifying question about a sibling's changes (question), or are answering another worker's question (answer). Messages are delivered on the recipient's next update_progress check-in as pendingMessages[]. Sender is resolved automatically from your ?worker= context — do not pass it as a parameter. Cross-workspace targeting is rejected (data isolation rule, not a nicety). Recipient terminal → returns { delivered: false, reason: "recipient_terminal" }. Rate limit: 5 messages per sender per minute per recipient task (retryAfter in error). Body size limit: 2 KB. Hop cap: 5 (prevents ping-pong loops — messages with hopCount >= 5 are dropped). Requires a worker context (?worker=<workerId> in the MCP URL).
No error handling guidance. Tools do not categorize errors as retryable, user-fixable, or fatal. No recovery suggestions. LLMs receive raw errors with no actionable next steps.