Loading ToolBench
MCP sidecar for the local OpenFusion engine: deep_consensus tool + budget guard + engine launcher
Two tools with detailed descriptions and clear use cases, but schemas are inferred from code rather than explicitly visible in tool registration. deep_consensus has a well-written description (180+ chars) explaining when to use it and what it returns. fusion_status is simpler but adequate. Both tools have input parameters documented in descriptions, but formal JSON Schema definitions with type constraints are not visible in the provided code excerpt. The server implements budget guards and honest error reporting, which is good practice, but parameter validation rules and error recovery guidance are embedded in implementation rather than surfaced in tool definitions.
Ask the local OpenFusion council: several AI models (different families) answer the question in parallel with web access, a judge compares their answers (consensus, contradictions, blind spots), and a synthesizer writes one final grounded answer. Use for hard one-shot questions where being wrong is costly: architecture reviews, research questions, plan critiques, tricky comparisons. NOT for quick lookups or trivial questions (it is slow — 1-5 minutes — and spends panel resources). Returns the synthesized answer plus honest metadata (which models ran, whether any failed, real cost).
Check the local OpenFusion council: engine health, which models are wired as panel/judge/synthesizer, and budget/spend status. Free — makes no model calls.
Input schemas not explicitly visible in tool registration. Code shows parameter descriptions in docstrings but no formal JSON Schema with type constraints, minLength, or enum declarations. Cannot verify schema completeness.
deep_consensus accepts 'context' as optional but no guidance on format, length limits, or what constitutes valid context. Parameter description lacks constraints (e.g., max length, expected structure).
fusion_status returns budget/spend data but output schema not documented. LLM cannot predict response structure (e.g., field names, types, presence of optional fields). Code shows spendSummary() returns object with runs_total, hosted_spent_today_usd, etc., but this is not in tool definition.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-23 | D | 59 | 2026-07-28+ | v2 |
deep_consensus error handling returns cost/degradation metadata but no guidance for LLM on recovery actions. If a panel fails, should the LLM retry, ask user, or proceed with degraded result? Not documented.
Tool names 'deep_consensus' and 'fusion_status' lack action verbs. Should be 'ask_consensus' or 'run_consensus' and 'check_status' or 'get_status' to match verb_noun convention and improve LLM intent parsing.