Loading ToolBench
A Spring Boot-based agent for technical article generation with web search, using MCP tool groups for web search, scraping, academic search, memory/knowledge, and reasoning.
This server presents a critical problem: NO INPUT SCHEMAS are visible in the provided source code. The pom.xml and CustomToolGroupsConfiguration.java show Spring/Embabel framework configuration, but the actual MinimalArticleAgent.java file (where tools are defined per the file list) is truncated ('src/main/java/es/omarall/agents/App' with no content shown). Tool definitions are referenced but not displayed, making schema evaluation impossible. Per HARD SCORING RULES, if tool definitions cannot be verified in source, schemas MUST score 0, capping overall per-tool scores at 50 maximum. The 6 tools (extractTopics, searchReferences, determineDocOutline, injectKnowledge, draftArticle, generateArticle) have descriptions visible in the tool index provided, but without seeing explicit input schema definitions in Java code, no parameter-level assessment is possible. No output schemas documented. No error handling visible. Tool naming follows verb_noun pattern (extractTopics, searchReferences, determineDocOutline), which is good, but the composite tools (determineDocOutline, injectKnowledge, draftArticle, generateArticle) accept multiple complex input types (UserInput, Topics, References, DocOutline, KnowledgePack) that should be formally constrained via JSON Schema, not visible. The framework appears to be Embabel Agent (custom Spring-based), not official MCP, which raises protocol compatibility questions.
Given the user intent, topics, and references, propose a structured outline (list of sections) for a technical article. Use the references as inspiration for the structure and content.
Draft a technical article in markdown format based on the user intent. Detect the language from the user intent and write the article in that language. Structure the article according to the outline. Integrate knowledge facts where relevant. Use references for inspiration and citation.
Extract up to 4 main topics from the following text
Minimal technical article generation with web search and code examples. Achieves goal: generate final article with metadata including slug, summary, keywords, and FAQs.
For each section in the outline and each topic, search for concise facts or definitions (max 50 words each) from real, verifiable sources. For each fact, include the topic, the statement, and a list of source URLs. Do not invent information.
Search for up to 5 real internet references relevant to the topics. For each, return the URL, the title and a summary.
NO INPUT SCHEMAS VISIBLE in source code. Tool definitions are referenced but actual schema definitions (Java code, JSON Schema) are not provided. Per HARD SCORING RULES, schema score MUST be 0 when not visible. This caps per-tool overall scores at 50 maximum due to inferred definitions.
Tool descriptions are too brief and lack LLM-optimized context. Descriptions like 'Extract up to 4 main topics from the following text' (40 chars) do not explain WHEN to use this tool vs alternatives, or what structure is returned. Rubric baseline: 194 chars average, target 50-200 chars. All 6 tools fall below 100 chars.
| Scored | Grade | Overall | Spec posture | Rubric |
|---|---|---|---|---|
| 2026-09-22 | F | 24 | 2026-07-28+ | v2 |
| 2026-03-09 | F | 14 | - | v1 |
No output schema documentation visible. Tools accept complex custom types (UserInput, Topics, DocOutline, References, KnowledgePack) but return structures are not described. LLMs cannot plan downstream tool chaining without knowing what fields are returned.
Composite/multi-step tools (determineDocOutline, injectKnowledge, draftArticle, generateArticle) accept 3-4 parameters each with complex types. No parameter-level descriptions visible, LLMs cannot infer what each parameter controls or constraints (e.g. max topics, required fields, format expectations).
No error handling guidance visible. Tools may fail (e.g., searchReferences finds no results, draftArticle fails to generate outline), but no recovery instructions, error classification, or fallback options documented.
Framework mismatch: This is Embabel Agent (Spring Boot custom framework), not official MCP (Model Context Protocol). Embabel appears to be a wrapper that can bridge to MCP via McpSyncClient instances, but the tool definitions are NOT explicitly MCP-compliant. MCP transport type cannot be confirmed from source.